8409 Want MSG_NOSIGNAL to prevent SIGPIPE

Review Request #590 — Created June 18, 2017 and submitted

Information
wiedi
illumos-gate
Reviewers
general 
The MSG_NOSIGNAL flag prevents SIGPIPE being generated when an attempt

to send on a stream-oriented socket is made that is no longer connected.

It is part of POSIX.1-2008:

    http://pubs.opengroup.org/onlinepubs/9699919799/functions/send.html
This change includes a test-case. I booted a system with this patch and executed the os-test suite.
  • 0
  • 0
  • 2
  • 0
  • 2
Description From Last Updated
tsoome
tsoome 
  1. seems to be clear enough;)
  2. 
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    3. 




  

 
















 





 

  

   




yyang




   

   







  

 



 

  


   

   

    
 
yyang


    
   


  

  

  



    




  1. 
 
    
  
    
   
    Ship It!
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    2. 















  2. 
 
    
  
    
   
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    3. 




  

 
















 





 

  

   




danmcd




   

   







  

 



 

  


   

   

    
 
danmcd


    
   


  

  

  



    




  1. 
 
    
  
    
   
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    2. 

















  2. 
 
    
  
  
    
  
 

   
    
    
    



    
 
    
  
    
   
   
    
    
     
     
     
     
     
    
    Show all issues
   
  
    
 
    

    



    
    I suspect the answer is "no", but is there ever a case where MSG_NOSIGNAL would reach this path?
    

    If you hadn't thought of this case, you ought to think about whether or not the MSG_NOSIGNAL logic needs to be here too.  (Again, I suspect no, but knowing why no is the right answer is useful.)
    
  
    
 
    

 
    
  


    
 
    
 
      

  


    1. 
 
 
      
 
      
  
 
      
 
      
  
      This is the path for sendfile, which does not expose a "flags" parameter nor is it specified by POSIX.
      
Besides sendfile socket_sendmblk() is called from snf_direct_io(), snf_segmap zero() and snf_cache(): all calls pass an all-zeros msg.
      

      So the answer is indeed "no".
      

      While looking at this I noticed that the sendfile/sendfilev man pages do not mention the SIGPIPE signal for the EPIPE error case (as other man pages do).
      
There are also a few other small things to improve there, so I'll probably update the sendfile man pages in a follow-up.
      
 
      

      2. 


 
    


    

 
    

    3. 




  3. 
 
    
  
    
   
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    4. 




  

 
















 





 

  

   




rm




   

   







  

 



 

  


   

   

    
 
rm


    
   


  

  

  



    




  1. 
 
    
  
    
   
    Ship It!
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    2. 















  2. 
 
    
  
    
   
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    3. 




  

 
















 





 

  

   




gdamore




   

   







  

 



 

  


   

   

    
 
gdamore


    
   


  

  

  



    




  1. 
 
    
  
    
   
    Generally looks good, especially like the test for it.
    

    Would it make sense to also add a case to the symbols test suite to ensure that the symbol is defined under POSIX 2008?
    
  
    
 
    

 
    
  


    
 
    
 
      

  


    1. 
 
 
      
 
      
  
 
      
 
      
  
      I only briefly looked at doing that, but there was no symbols test case for sys/socket.h yet.
      
I don't think I know enough about these standards to create a full test for this file.
      
 
      

      2. 


 
    


    

 
    

    2. 

















  2. 
 
    
  
  
    
  
 
    
  
    
   
    
    
     
      usr/src/uts/common/sys/socket.h
      


       (Diff revision 1)


      
     
    
    
       
   
    
     
    

    
     
    

       
  
    
 
    

   
    
    
    



    
 
    
  
    
   
   
    
    
     
     
     
     
     
    
    Show all issues
   
  
    
 
    

    



    
    My one question here is about the exposure of this symbol.  I'd expect it to be exposed under POSIX 2008; it's unclear to me that its correct for us to expose it in other contexts -- but I do see that we are exposing the other symbols without any guards.
    

    Does POSIX reserve the MSG_xxx namespace entirely for implementation use?
    

    I think the XPGv2 section, and comments, are probably best removed btw.  XPGv2 compliance is not something we really care all that much about and I think the grouping is somewhat artificial and incorrect -- in fact some of the other symbols are covered under other standards, and we don't call those out.
    
  
    
 
    

 
    
  


    
 
    
 
      

  


    1. 
 
 
      
 
      
  
 
      
 
      
  
      

      

      

      Does POSIX reserve the MSG_xxx namespace entirely for implementation use?
      

      

      If my reading of table in 2.2.2 http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02_02 is correct I'd say yes it does. And since the other flags were not guarded I opted to also not add one.
      

      

      

      

      I think the XPGv2 section, and comments, are probably best removed btw.
      

      

      Just to be sure I understand, you'd like the comments regarding XPGv2 removed and the list reorderd, not the actual XPGv2 symbols removed, right?
      
If so I'll do that.
      
 
      

      2. 



    2. 
 
 
      
 
      
  
 
      
 
      
  
      Correct.  I'm satisfied with the other answers, though I'd really like to see symbols test suite coverage for this, I'm not prepared to block the RTI on that.
      
 
      

      3. 



    3. 
 
 
      
 
      
  
 
      
 
      
  
      I've made the change.
      

      There are also some other issues I'd like to work on that are related to standards, so maybe once I've learned enough I can add the symbol tests.
      
 
      

      4. 


 
    


    

 
    

    3. 




  3. 
 
    
  
    
   
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    4. 




  

 
















 





 

  

   




danmcd




   

   







  

 



 

  


   

   

    
 
danmcd


    
   


  

  

  



    




  1. 
 
    
  
    
   
    My question was answered satisfactorily.
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    2. 















  2. 
 
    
  
    
   
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    3. 




  

 
















 



 

  

   




wiedi




   

   

  

 



 















 



 

  

   




wiedi




   

   

  

 



 

  


   

   

    
 Review request changed

    
   


  

  

  






 

  Status:
  

  Closed (submitted)

  
 







 


 










  

 









     

    

   

  

  

   
   Loading...