Colin Percival wrote:
>On 01/18/17 02:36, Konstantin Belousov wrote:
>> On Wed, Jan 18, 2017 at 04:37:40AM +0000, Colin Percival wrote:
>>> Thanks, looks like that was exactly it -- if the TCP send buffer was full
>>> we would call sbwait, and if a signal arrived it would return ERESTART.
>>> It looks like setting the SB_NOINTR flag will prevent this; I'm testing a
>>> patch right now.
>>
>> Note that passing SB_NOINTR unconditionally or even only for mounts
>> with nointr (default) option is wrong. You make the socket operation
>> uninterruptible, process terminate-ability becomes depended on the
>> external factor, the behaviour of the remote system.
>
>I'm not sure what you're getting at here. The fact that "NFS mounted without
>the intr flag" + "unresponsive NFS server" = "unkillable processes" has been
>a (mis)feature of NFS for decades.
The case I would like to see work is the forced dismount. I need to go look at
what it does and see if SB_NOINTR would break it worse than it is broken now.
(It is currently broken when something like "umount" without -f is done, which
locks up the mounted on vnode so "umount -f" never gets to the umount(2)
syscall.
I do plan on a "straight ot NFS" option for umount(8) to avoid this problem,
but
haven't gotten around to it.)
The alternative to SB_NOINTR is looping and doing the sosend() again for the
case where it returns ERESTART and "intr" wasn't set on the mount.
--> For this to be ok, we must be sure that when sosend() returns ERESTART,
it has not queued the data for sending so it is safe to send it all again.
I think this is true for this case?
rick
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
