Mon, May 02, 2016 at 10:45:44PM CEST, j...@resnulli.us wrote: >Mon, May 02, 2016 at 10:23:27PM CEST, eric.duma...@gmail.com wrote: >>On Mon, 2016-05-02 at 21:12 +0200, Jiri Pirko wrote: >>> Mon, May 02, 2016 at 06:22:18PM CEST, eric.duma...@gmail.com wrote: >>> >On Mon, 2016-05-02 at 18:16 +0200, Jiri Pirko wrote: >>> >> Mon, Apr 25, 2016 at 07:39:32PM CEST, eduma...@google.com wrote: >>> >> >SOCKWQ_ASYNC_NOSPACE is tested in sock_wake_async() >>> >> >so that a SIGIO signal is sent when needed. >>> >> > >>> >> >tcp_sendmsg() clears the bit. >>> >> >tcp_poll() sets the bit when stream is not writeable. >>> >> > >>> >> >We can avoid two atomic operations by first checking if socket >>> >> >is actually interested in the FASYNC business (most sockets in >>> >> >real applications do not use AIO, but select()/poll()/epoll()) >>> >> > >>> >> >This also removes one cache line miss to access sk->sk_wq->flags >>> >> >in tcp_sendmsg() >>> >> > >>> >> >Signed-off-by: Eric Dumazet <eduma...@google.com> >>> >> >>> >> I just bisected down to this. This is causing a regression for me when >>> >> my nfs mount becomes stuck. I can easily reproduce this if you need to >>> >> test the fix. >>> > >>> >What do you mean by 'when nfs mount becomes stuck' ? >>> > >>> >Is this patch making nfs not functional , or does it make recovery from >>> >some nfs error bad ? >>> >>> I can mount nfs on the host. But when I do something (compile a kernel >>> module in my case), it gets stuck. Then I cannot even ssh to the machine. >>> No messages in dmesg. I didn't debug it any further. I just bisected and >>> verified that this patch caused this behaviour. >> >>Interesting. >> >>It looks like net/sunrpc/xprtsock.c should set SOCK_FASYNC >>even if it is not actually using fasync_list >> >>Could you try this quick hack to check if this is the right way ? > >Yep, works, I do not see the issue with this patch anymore. Thanks.
Eric, any news with this issue? Thanks.
