Re: [RFC PATCH] af_unix: fix entry locking in unix_dgram_recvmsg

2015-12-03 Thread David Miller
From: Rainer Weikusat Date: Thu, 03 Dec 2015 21:24:17 + > David Miller writes: >> So with your patch, the "N * timeout" behavior, where N is the number >> of queues reading threads, no longer occurs? Do they all now properly >> get released at the appropriate timeout? > > As far as I can

Re: [RFC PATCH] af_unix: fix entry locking in unix_dgram_recvmsg

2015-12-03 Thread Eric Dumazet
On Thu, 2015-12-03 at 21:24 +, Rainer Weikusat wrote: > As far as I can tell, yes. With the change, unix_dgram_recvmsg has a > read loop looking like this: > > last = NULL; /* not really necessary */ I am not sure SO_RCVTIMEO is really used for af_unix, given its poor reaction to

Re: [RFC PATCH] af_unix: fix entry locking in unix_dgram_recvmsg

2015-12-03 Thread Rainer Weikusat
David Miller writes: > From: Rainer Weikusat >> Rainer Weikusat writes: >> >> [...] >> >>> Insofar I understand the comment in this code block correctly, [...] >>> /* recvmsg() in non blocking mode is supposed to return >>> -EAGAIN >>> * sk_rcvtimeo is not

Re: [RFC PATCH] af_unix: fix entry locking in unix_dgram_recvmsg

2015-12-03 Thread David Miller
From: Rainer Weikusat Date: Thu, 03 Dec 2015 21:24:17 + > David Miller writes: >> So with your patch, the "N * timeout" behavior, where N is the number >> of queues reading threads, no longer occurs? Do they all now properly >> get

Re: [RFC PATCH] af_unix: fix entry locking in unix_dgram_recvmsg

2015-12-03 Thread Rainer Weikusat
David Miller writes: > From: Rainer Weikusat >> Rainer Weikusat writes: >> >> [...] >> >>> Insofar I understand the comment in this code block correctly, [...] >>> /* recvmsg()

Re: [RFC PATCH] af_unix: fix entry locking in unix_dgram_recvmsg

2015-12-03 Thread Eric Dumazet
On Thu, 2015-12-03 at 21:24 +, Rainer Weikusat wrote: > As far as I can tell, yes. With the change, unix_dgram_recvmsg has a > read loop looking like this: > > last = NULL; /* not really necessary */ I am not sure SO_RCVTIMEO is really used for af_unix, given its poor reaction to

Re: [RFC PATCH] af_unix: fix entry locking in unix_dgram_recvmsg

2015-12-02 Thread David Miller
From: Rainer Weikusat Date: Tue, 01 Dec 2015 17:02:33 + > Rainer Weikusat writes: > > [...] > >> Insofar I understand the comment in this code block correctly, >> >> err = mutex_lock_interruptible(>readlock); >> if (unlikely(err)) { >> /* recvmsg() in non

Re: [RFC PATCH] af_unix: fix entry locking in unix_dgram_recvmsg

2015-12-02 Thread David Miller
From: Rainer Weikusat Date: Tue, 01 Dec 2015 17:02:33 + > Rainer Weikusat writes: > > [...] > >> Insofar I understand the comment in this code block correctly, >> >> err =

Re: [RFC PATCH] af_unix: fix entry locking in unix_dgram_recvmsg

2015-12-01 Thread Rainer Weikusat
Rainer Weikusat writes: [...] > Insofar I understand the comment in this code block correctly, > > err = mutex_lock_interruptible(>readlock); > if (unlikely(err)) { > /* recvmsg() in non blocking mode is supposed to return > -EAGAIN > *

Re: [RFC PATCH] af_unix: fix entry locking in unix_dgram_recvmsg

2015-12-01 Thread Rainer Weikusat
Rainer Weikusat writes: [...] > Insofar I understand the comment in this code block correctly, > > err = mutex_lock_interruptible(>readlock); > if (unlikely(err)) { > /* recvmsg() in non blocking mode is supposed to

[RFC PATCH] af_unix: fix entry locking in unix_dgram_recvmsg

2015-11-29 Thread Rainer Weikusat
This will probably earn me a reputation as the most single-minded monomaniac on this planet (insofar there's still anything to earn in this respect) but this issue has been irking me "ever since". NB: This is somewhat loser formatted than a proper patch submission in order to explain the

[RFC PATCH] af_unix: fix entry locking in unix_dgram_recvmsg

2015-11-29 Thread Rainer Weikusat
This will probably earn me a reputation as the most single-minded monomaniac on this planet (insofar there's still anything to earn in this respect) but this issue has been irking me "ever since". NB: This is somewhat loser formatted than a proper patch submission in order to explain the