Re: [PATCH 3.2 08/67] af_unix: fix struct pid memory leak

Ben Hutchings writes: > 3.2.78-rc1 review patch. If anyone has any objections, please let me know. > > -- > > From: Eric Dumazet > > commit fa0dc04df259ba2df3ce1920e9690c7842f8fa4b upstream. [...] > Fixes: b3ca9b02b007 ("net: fix

Re: [PATCH 3.2 08/67] af_unix: fix struct pid memory leak

Ben Hutchings writes: > 3.2.78-rc1 review patch. If anyone has any objections, please let me know. > > -- > > From: Eric Dumazet > > commit fa0dc04df259ba2df3ce1920e9690c7842f8fa4b upstream. [...] > Fixes: b3ca9b02b007 ("net: fix multithreaded signal handling in unix recv >

[PATCH net] af_unix: Don't use continue to re-execute unix_stream_read_generic loop

are returned either way. Signed-off-by: Rainer Weikusat <rweiku...@mobileactivedefense.com> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- I'm resending this as the original patch seems to have been classified as superseded without anything actually superseding it. I

[PATCH net] af_unix: Don't use continue to re-execute unix_stream_read_generic loop

are returned either way. Signed-off-by: Rainer Weikusat Acked-by: Hannes Frederic Sowa --- I'm resending this as the original patch seems to have been classified as superseded without anything actually superseding it. I hope the net is appropriate. I consider this a bugfix. diff --git a/net/unix

https://patchwork.ozlabs.org/patch/579654?

https://patchwork.ozlabs.org/patch/579654 lists this as 'superseded', among with the older versions of the patch which changed the error handling. But at least, I couldn't find anything superseding it. This was supposed to address the different-but-related problem demonstrated by the following

https://patchwork.ozlabs.org/patch/579654?

https://patchwork.ozlabs.org/patch/579654 lists this as 'superseded', among with the older versions of the patch which changed the error handling. But at least, I couldn't find anything superseding it. This was supposed to address the different-but-related problem demonstrated by the following

Re: [PATCH net] af_unix: Guard against other == sk in unix_dgram_sendmsg

Ben Hutchings writes: > On Fri, 2016-02-12 at 20:17 +0000, Rainer Weikusat wrote: [...] >>>> I don't think this should apply when >>>> receiving and sending sockets are identical. But that's just my >>>> opinion. The other option would be to avoid the unix

Re: [PATCH net] af_unix: Guard against other == sk in unix_dgram_sendmsg

Ben Hutchings writes: > On Fri, 2016-02-12 at 13:25 +0000, Rainer Weikusat wrote: >> Philipp Hahn writes: >> > Hello Rainer, >> > >> > Am 11.02.2016 um 20:37 schrieb Rainer Weikusat: >> > > The unix_dgram_sendmsg routine use the following test &g

Re: [PATCH] af_unix: Don't set err in unix_stream_read_generic unless there was an error

Joseph Salisbury writes: > On 02/05/2016 05:30 PM, Rainer Weikusat wrote: >> The present unix_stream_read_generic contains various code sequences of >> the form >> >> err = -EDISASTER; >> if () >> goto out; [...] >> Change it such that err i

Re: [PATCH net] af_unix: Guard against other == sk in unix_dgram_sendmsg

Philipp Hahn writes: > Hello Rainer, > > Am 11.02.2016 um 20:37 schrieb Rainer Weikusat: >> The unix_dgram_sendmsg routine use the following test >> >> if (unlikely(unix_peer(other) != sk && unix_recvq_full(other))) { [...] >> This isn't correct as the

Re: [PATCH net] af_unix: Guard against other == sk in unix_dgram_sendmsg

Philipp Hahn <pmh...@pmhahn.de> writes: > Hello Rainer, > > Am 11.02.2016 um 20:37 schrieb Rainer Weikusat: >> The unix_dgram_sendmsg routine use the following test >> >> if (unlikely(unix_peer(other) != sk && unix_recvq_full(other))) { [...] >&g

Re: [PATCH] af_unix: Don't set err in unix_stream_read_generic unless there was an error

Joseph Salisbury <joseph.salisb...@canonical.com> writes: > On 02/05/2016 05:30 PM, Rainer Weikusat wrote: >> The present unix_stream_read_generic contains various code sequences of >> the form >> >> err = -EDISASTER; >> if () >> goto out;

Re: [PATCH net] af_unix: Guard against other == sk in unix_dgram_sendmsg

Ben Hutchings <b...@decadent.org.uk> writes: > On Fri, 2016-02-12 at 13:25 +0000, Rainer Weikusat wrote: >> Philipp Hahn <pmh...@pmhahn.de> writes: >> > Hello Rainer, >> > >> > Am 11.02.2016 um 20:37 schrieb Rainer Weikusat: >> >

Re: [PATCH net] af_unix: Guard against other == sk in unix_dgram_sendmsg

Ben Hutchings <b...@decadent.org.uk> writes: > On Fri, 2016-02-12 at 20:17 +0000, Rainer Weikusat wrote: [...] >>>> I don't think this should apply when >>>> receiving and sending sockets are identical. But that's just my >>>>

[PATCH net] af_unix: Guard against other == sk in unix_dgram_sendmsg

er == sk which might either block the sender unintentionally or lead to trying to unlock the same spin lock twice for a non-blocking send. Add a other != sk check to guard against this. Fixes: 7d267278a9ec ("unix: avoid use-after-free in ep_remove_wait_queue") Reported-By: Philipp Hahn Sig

Re: Bug 4.1.16: self-detected stall in net/unix/?

Rainer Weikusat writes: > Ben Hutchings writes: [...] >> unix: Fix potential double-unlock in unix_dgram_sendmsg() >> >> A datagram socket may be peered with itself, so that sk == other.  We >> use unix_state_double_lock() to lock sk and other in the right order, &

Re: Bug 4.1.16: self-detected stall in net/unix/?

Rainer Weikusat writes: [...] > This means it only gets locked if unix_peer(other) != sk and this cannot > happen if other == sk and unix_peer(sk) == other, however, the 2nd > condition isn't guaranteed: other might indeed be == sk and not the peer > of it because someone co

Re: Bug 4.1.16: self-detected stall in net/unix/?

Ben Hutchings writes: > On Thu, 2016-02-11 at 15:55 +0000, Rainer Weikusat wrote: >> Philipp Hahn writes: >> >> [...] >> >> > Probably the same bug was also reported to samba-technical by Karolin >> > Seeger; she filed the bug for 3.19-ckt with Ubu

Re: Bug 4.1.16: self-detected stall in net/unix/?

Philipp Hahn writes: [...] > Probably the same bug was also reported to samba-technical by Karolin > Seeger; she filed the bug for 3.19-ckt with Ubuntu: > > > > Running the Samba test suite reproduces the problem; see bug

[PATCH net] af_unix: Guard against other == sk in unix_dgram_sendmsg

<pmh...@pmhahn.de> Signed-off-by: Rainer Weikusat <rweiku...@mobileactivedefense.com> --- diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c index 29be035..f1ca279 100644 --- a/net/unix/af_unix.c +++ b/net/unix/af_unix.c @@ -1781,7 +1781,12 @@ restart_locked:

Re: Bug 4.1.16: self-detected stall in net/unix/?

Philipp Hahn writes: [...] > Probably the same bug was also reported to samba-technical by Karolin > Seeger; she filed the bug for 3.19-ckt with Ubuntu: > > > > Running the Samba test suite reproduces

Re: Bug 4.1.16: self-detected stall in net/unix/?

Rainer Weikusat <r...@doppelsaurus.mobileactivedefense.com> writes: [...] > This means it only gets locked if unix_peer(other) != sk and this cannot > happen if other == sk and unix_peer(sk) == other, however, the 2nd > condition isn't guaranteed: other might indeed be == sk a

Re: Bug 4.1.16: self-detected stall in net/unix/?

Ben Hutchings <b...@decadent.org.uk> writes: > On Thu, 2016-02-11 at 15:55 +0000, Rainer Weikusat wrote: >> Philipp Hahn <pmh...@pmhahn.de> writes: >> >> [...] >> >> > Probably the same bug was also reported to samba-technical by Karolin >>

Re: Bug 4.1.16: self-detected stall in net/unix/?

Rainer Weikusat <r...@doppelsaurus.mobileactivedefense.com> writes: > Ben Hutchings <b...@decadent.org.uk> writes: [...] >> unix: Fix potential double-unlock in unix_dgram_sendmsg() >> >> A datagram socket may be peered with itself, so that sk == other. 

[PATCH] af_unix: Don't set err in unix_stream_read_generic unless there was an error

code") Reported-by: Joseph Salisbury Signed-off-by: Rainer Weikusat --- And the subject again fixed and, since another correction was necessary, anyway, a Reported-by added. diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c index 49d5093..c1e4dd7 100644 --- a/net/unix/af_unix.c +++ b/net/unix

Re: [PATCH] af_unix: Don't set err in unix_stream_read_generic unless there was an error

code") Signed-off-by: Rainer Weikusat --- With Fixes: fixed. diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c index 49d5093..c1e4dd7 100644 --- a/net/unix/af_unix.c +++ b/net/unix/af_unix.c @@ -2277,13 +2277,15 @@ static int unix_stream_read_generic(struct unix_stream_read_state *state)

[PATCH] af_unix: Don't set err in unix_stream_read_generic unless there was an error

if no data was copied because the caller didn't supply a data buffer, as demonstrated by the program available at http://pad.lv/1540731 Change it such that err is only set if an error condition was detected. Fixes: 3822b5c2fc62 Signed-off-by: Rainer Weikusat --- diff --git a/net/unix/af_unix.c b

[PATCH] af_unix: Don't set err in unix_stream_read_generic unless there was an error

if no data was copied because the caller didn't supply a data buffer, as demonstrated by the program available at http://pad.lv/1540731 Change it such that err is only set if an error condition was detected. Fixes: 3822b5c2fc62 Signed-off-by: Rainer Weikusat <rweiku...@mobileactivedefense.

Re: [PATCH] af_unix: Don't set err in unix_stream_read_generic unless there was an error

code") Signed-off-by: Rainer Weikusat <rweiku...@mobileactivedefense.com> --- With Fixes: fixed. diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c index 49d5093..c1e4dd7 100644 --- a/net/unix/af_unix.c +++ b/net/unix/af_unix.c @@ -2277,13 +2277,15 @@ static int unix_stream_rea

[PATCH] af_unix: Don't set err in unix_stream_read_generic unless there was an error

code") Reported-by: Joseph Salisbury <joseph.salisb...@canonical.com> Signed-off-by: Rainer Weikusat <rweiku...@mobileactivedefense.com> --- And the subject again fixed and, since another correction was necessary, anyway, a Reported-by added. diff --git a/net/unix/af_unix.c b/net/unix/a

Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code

Rainer Weikusat writes: [...] > The start uses that to record an error which might need to be > reported, the return statement uses it to indicate that an error has > occurred. Hence, some kind of in-between translation must occur. The > mutex_lock_interruptible ha

Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code

Rainer Weikusat writes: [...] > the real problem is that the function disagrees with itself on how to > use the err variable: The start uses that to record an error which > might need to be reported, the return statement uses it to indicate > that an error has occurred. This shou

Re: [PATCH] af_unix: Don't set err in unix_stream_read_generic unless there was an error

if no data was copied because the caller didn't supply a data buffer, as demonstrated by the program available at http://pad.lv/1540731 Change it such that err is only set if an error condition was detected. Signed-off-by: Rainer Weikusat --- With unlikely() added to the two leading error checks

Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code

Eric Dumazet writes: > On Fri, 2016-02-05 at 21:44 +0000, Rainer Weikusat wrote: >> The present unix_stream_read_generic contains various code sequences of >> the form >> >> err = -EDISASTER; >> if () >> goto out; >> >> This has the un

Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code

Rainer Weikusat <r...@doppelsaurus.mobileactivedefense.com> writes: [...] > the real problem is that the function disagrees with itself on how to > use the err variable: The start uses that to record an error which > might need to be reported, the return statement uses

Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code

Rainer Weikusat <r...@doppelsaurus.mobileactivedefense.com> writes: [...] > The start uses that to record an error which might need to be > reported, the return statement uses it to indicate that an error has > occurred. Hence, some kind of in-between transla

Re: [PATCH] af_unix: Don't set err in unix_stream_read_generic unless there was an error

if no data was copied because the caller didn't supply a data buffer, as demonstrated by the program available at http://pad.lv/1540731 Change it such that err is only set if an error condition was detected. Signed-off-by: Rainer Weikusat <rweiku...@mobileactivedefense.com> --- With un

Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code

Eric Dumazet <eric.duma...@gmail.com> writes: > On Fri, 2016-02-05 at 21:44 +0000, Rainer Weikusat wrote: >> The present unix_stream_read_generic contains various code sequences of >> the form >> >> err = -EDISASTER; >> if () >> goto out

[PATCH] af_unix: Don't use continue to re-execute unix_stream_read_generic loop

are returned either way. Signed-off-by: Rainer Weikusat --- diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c index 49d5093..3b73bd7 100644 --- a/net/unix/af_unix.c +++ b/net/unix/af_unix.c @@ -2305,6 +2305,7 @@ static int unix_stream_read_generic(struct unix_stream_read_state *state

[PATCH] af_unix: Don't set err in unix_stream_read_generic unless there was an error

if no data was copied because the caller didn't supply a data buffer, as demonstrated by the program available at http://pad.lv/1540731 Change it such that err is only set if an error condition was detected. Signed-off-by: Rainer Weikusat --- With proper subject this time (at least I hope so

Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code

Rainer Weikusat writes: > Joseph Salisbury writes: >> On 02/05/2016 02:59 PM, Rainer Weikusat wrote: > > [recvmsg w/o iovecs returning ENOTSUP for CMSG requests] [...] > There are more problems wrt handling control-message only reads in this > code. [...] > it will

Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code

if no data was copied because the caller didn't supply a data buffer, as demonstrated by the program available at http://pad.lv/1540731 Change it such that err is only set if an error condition was detected. Signed-off-by: Rainer Weikusat --- diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c

Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code

Joseph Salisbury writes: > On 02/05/2016 02:59 PM, Rainer Weikusat wrote: [recvmsg w/o iovecs returning ENOTSUP for CMSG requests] >> Funny little problem :-). The code using the interruptible lock cleared >> err as side effect hence the >> >> out: &g

Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code

Joseph Salisbury writes: > Hi Rainer, > > A kernel bug report was opened against Ubuntu [0]. After a kernel > bisect, it was found that reverting the following commit resolved this bug: > > commit 3822b5c2fc62e3de8a0f33806ff279fb7df92432 > Author: Rainer Weikusat > Dat

Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code

Joseph Salisbury <joseph.salisb...@canonical.com> writes: > Hi Rainer, > > A kernel bug report was opened against Ubuntu [0]. After a kernel > bisect, it was found that reverting the following commit resolved this bug: > > commit 3822b5c2fc62e3de8a0f33806ff279fb7df92432 &

[PATCH] af_unix: Don't set err in unix_stream_read_generic unless there was an error

if no data was copied because the caller didn't supply a data buffer, as demonstrated by the program available at http://pad.lv/1540731 Change it such that err is only set if an error condition was detected. Signed-off-by: Rainer Weikusat <rweiku...@mobileactivedefense.com> --- With

[PATCH] af_unix: Don't use continue to re-execute unix_stream_read_generic loop

are returned either way. Signed-off-by: Rainer Weikusat <rweiku...@mobileactivedefense.com> --- diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c index 49d5093..3b73bd7 100644 --- a/net/unix/af_unix.c +++ b/net/unix/af_unix.c @@ -2305,6 +2305,7 @@ static int unix_stream_read_generic(

Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code

if no data was copied because the caller didn't supply a data buffer, as demonstrated by the program available at http://pad.lv/1540731 Change it such that err is only set if an error condition was detected. Signed-off-by: Rainer Weikusat <rweiku...@mobileactivedefense.com> --- diff --git

Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code

Rainer Weikusat <r...@doppelsaurus.mobileactivedefense.com> writes: > Joseph Salisbury <joseph.salisb...@canonical.com> writes: >> On 02/05/2016 02:59 PM, Rainer Weikusat wrote: > > [recvmsg w/o iovecs returning ENOTSUP for CMSG requests] [...] > There are more

Re: [V4.4-rc6 Regression] af_unix: Revert 'lock_interruptible' in stream receive code

Joseph Salisbury <joseph.salisb...@canonical.com> writes: > On 02/05/2016 02:59 PM, Rainer Weikusat wrote: [recvmsg w/o iovecs returning ENOTSUP for CMSG requests] >> Funny little problem :-). The code using the interruptible lock cleared >> err as side effect hence the >

Re: [PATCH] af_unix: Fix splice-bind deadlock

Hannes Frederic Sowa writes: > On Sun, Jan 3, 2016, at 19:03, Rainer Weikusat wrote: [reorder i_mutex and readlock locking] > I was concerned because of the comment in skb_socket_splice: > > /* Drop the socket lock, otherwise we have reverse > * locking depen

Re: [PATCH] af_unix: Fix splice-bind deadlock

Hannes Frederic Sowa <han...@stressinduktion.org> writes: > On Sun, Jan 3, 2016, at 19:03, Rainer Weikusat wrote: [reorder i_mutex and readlock locking] > I was concerned because of the comment in skb_socket_splice: > > /* Drop the socket lock, otherwi

Re: [PATCH] net: Fix potential NULL pointer dereference in __skb_try_recv_datagram

Eric Dumazet writes: > On Mon, 2016-01-04 at 10:10 +0100, Jacob Siverskog wrote: [...] >> I believe the crash occurred between these two actions. I just saw >> that there are some interesting events in the log prior to the crash: >> kernel: Bluetooth: Unable to push skb to HCI core(-6) >>

Re: [lkp] [af_unix] 039b21aaee: otc_kernel_qa-ts_ltp_ddt.bind01.fail

kernel test robot writes: > FYI, we noticed the below changes on > > https://github.com/0day-ci/linux > Rainer-Weikusat/af_unix-Fix-splice-bind-deadlock/20151228-041437 > commit 039b21aaee6515d0197e26321204f319b4ea6e9e ("af_unix: Fix splice-bind > deadlock") > >

Re: [lkp] [af_unix] 039b21aaee: otc_kernel_qa-ts_ltp_ddt.bind01.fail

kernel test robot <ying.hu...@linux.intel.com> writes: > FYI, we noticed the below changes on > > https://github.com/0day-ci/linux > Rainer-Weikusat/af_unix-Fix-splice-bind-deadlock/20151228-041437 > commit 039b21aaee6515d0197e26321204f319b4ea6e9e ("af_unix: F

Re: [PATCH] net: Fix potential NULL pointer dereference in __skb_try_recv_datagram

Eric Dumazet writes: > On Mon, 2016-01-04 at 10:10 +0100, Jacob Siverskog wrote: [...] >> I believe the crash occurred between these two actions. I just saw >> that there are some interesting events in the log prior to the crash: >> kernel: Bluetooth: Unable to push skb

Re: [PATCH] af_unix: Fix splice-bind deadlock

described above). Dmitry Vyukov() tested the original patch. Signed-off-by: Rainer Weikusat --- This fixes two 'wrong' error returns, namely, return -EADDRINUSE if kern_path_create returned -EEXIST but delay returning an error from kern_path_create until after the u->addr check as the -EINVAL should

Re: [PATCH] af_unix: Fix splice-bind deadlock

Rainer Weikusat writes: [...] > + dentry = NULL; > + if (sun_path[0]) { > + /* Get the parent directory, calculate the hash for last > + * component. > + */ > + dentry = kern_path_create(AT_FDCWD, sun_path, , 0); >

Re: [PATCH] af_unix: Fix splice-bind deadlock

Rainer Weikusat writes: > Hannes Frederic Sowa writes: >> On 27.12.2015 21:13, Rainer Weikusat wrote: >>> -static int unix_mknod(const char *sun_path, umode_t mode, struct path *res) >>> +static int unix_mknod(struct dentry *dentry, struct pa

Re: [PATCH] af_unix: Fix splice-bind deadlock

Rainer Weikusat <r...@doppelsaurus.mobileactivedefense.com> writes: > Hannes Frederic Sowa <han...@stressinduktion.org> writes: >> On 27.12.2015 21:13, Rainer Weikusat wrote: >>> -static int unix_mknod(const char *sun_path, umode_t mode, struct path *res) >>&g

Re: [PATCH] af_unix: Fix splice-bind deadlock

Rainer Weikusat <r...@doppelsaurus.mobileactivedefense.com> writes: [...] > + dentry = NULL; > + if (sun_path[0]) { > + /* Get the parent directory, calculate the hash for last > + * component. > + */ > + d

Re: [PATCH] af_unix: Fix splice-bind deadlock

described above). Dmitry Vyukov(<dvyu...@google.com>) tested the original patch. Signed-off-by: Rainer Weikusat <rweiku...@mobileactivedefense.com> --- This fixes two 'wrong' error returns, namely, return -EADDRINUSE if kern_path_create returned -EEXIST but delay returning an error from kern

Re: [PATCH] af_unix: Fix splice-bind deadlock

Hannes Frederic Sowa writes: > On 27.12.2015 21:13, Rainer Weikusat wrote: >> -static int unix_mknod(const char *sun_path, umode_t mode, struct path *res) >> +static int unix_mknod(struct dentry *dentry, struct path *path, umode_t >> mode, >> +

Re: [PATCH] af_unix: Fix splice-bind deadlock

Hannes Frederic Sowa <han...@stressinduktion.org> writes: > On 27.12.2015 21:13, Rainer Weikusat wrote: >> -static int unix_mknod(const char *sun_path, umode_t mode, struct path *res) >> +static int unix_mknod(struct dentry *dentry, struct path *path, umode_t >> mode, &

Re: [PATCH] net: Fix potential NULL pointer dereference in __skb_try_recv_datagram

Jacob Siverskog writes: > On Tue, Dec 29, 2015 at 9:08 PM, David Miller wrote: >> From: Rainer Weikusat >> Date: Tue, 29 Dec 2015 19:42:36 + >> >>> Jacob Siverskog writes: >>>> This should fix a NULL pointer dereference I encountered (dump >&

Re: [PATCH] net: Fix potential NULL pointer dereference in __skb_try_recv_datagram

Jacob Siverskog <jacob@teenage.engineering> writes: > On Tue, Dec 29, 2015 at 9:08 PM, David Miller <da...@davemloft.net> wrote: >> From: Rainer Weikusat <rweiku...@mobileactivedefense.com> >> Date: Tue, 29 Dec 2015 19:42:36 + >> >>> Ja

Re: [PATCH] net: Fix potential NULL pointer dereference in __skb_try_recv_datagram

Jacob Siverskog writes: > This should fix a NULL pointer dereference I encountered (dump > below). Since __skb_unlink is called while walking, > skb_queue_walk_safe should be used. The code in question is: skb_queue_walk(queue, skb) { *last = skb; *peeked = skb->peeked;

Re: [PATCH] net: Fix potential NULL pointer dereference in __skb_try_recv_datagram

Jacob Siverskog writes: > This should fix a NULL pointer dereference I encountered (dump > below). Since __skb_unlink is called while walking, > skb_queue_walk_safe should be used. The code in question is: skb_queue_walk(queue, skb) { *last = skb;

[PATCH] af_unix: Fix splice-bind deadlock

described above). Signed-off-by: Rainer Weikusat Tested-by: Dmitry Vyukov --- I also think this is a better (or at least more correct) solution than the pretty obvious idea to record that the socket is in the process of being bound and performing the mknod without the lock. Assuming the first bind fails

[PATCH] af_unix: Fix splice-bind deadlock

described above). Signed-off-by: Rainer Weikusat <rweiku...@mobileactivedefense.com> Tested-by: Dmitry Vyukov <dvyu...@google.com> --- I also think this is a better (or at least more correct) solution than the pretty obvious idea to record that the socket is in the process of being bound an

splice-bind deadlock (was: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive code)

Rainer Weikusat writes: > Hannes Frederic Sowa writes: > > [...] > >> There is still a deadlock lingering around > > [...] > >> http://lists.openwall.net/netdev/2015/11/10/4 [...] > (a while ago) A: socketpair() > > B:

splice-bind deadlock (was: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive code)

Rainer Weikusat <r...@doppelsaurus.mobileactivedefense.com> writes: > Hannes Frederic Sowa <han...@stressinduktion.org> writes: > > [...] > >> There is still a deadlock lingering around > > [...] > >> http://lists.openwall.net/netdev/2015/11/10/

Re: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive code

Hannes Frederic Sowa writes: [...] > There is still a deadlock lingering around [...] > http://lists.openwall.net/netdev/2015/11/10/4 Interesting problem. Assuming the description (a while ago) A: socketpair() B: splice() from a pipe to /mnt/regular_file

Re: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive code

Hannes Frederic Sowa writes: > On 16.12.2015 21:09, Rainer Weikusat wrote: >> With b3ca9b02b00704053a38bfe4c31dbbb9c13595d0, the AF_UNIX SOCK_STREAM >> receive code was changed from using mutex_lock(>readlock) to >> mutex_lock_interruptible(>readlock) to prevent si

Re: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive code

Hannes Frederic Sowa <han...@stressinduktion.org> writes: > On 16.12.2015 21:09, Rainer Weikusat wrote: >> With b3ca9b02b00704053a38bfe4c31dbbb9c13595d0, the AF_UNIX SOCK_STREAM >> receive code was changed from using mutex_lock(>readlock) to >> mutex_lock_inter

Re: [PATCH] af_unix: Revert 'lock_interruptible' in stream receive code

Hannes Frederic Sowa writes: [...] > There is still a deadlock lingering around [...] > http://lists.openwall.net/netdev/2015/11/10/4 Interesting problem. Assuming the description (a while ago) A: socketpair() B: splice() from a pipe to

[PATCH RFC] AF_UNIX SOCK_STREAM SO_PEEK_OFS oddity

issue) described above, it will actually print TWOTIMES twices followed by 12345678 while the NOTATALL remains invisible. If this is not the intended behaviour, I propose the patch below to fix it. It changes the code to reload the peek offset after the sleep. Signed-off-by: Rainer Weikusat --

[PATCH] af_unix: Revert 'lock_interruptible' in stream receive code

reader. As the interruptible locking makes the code more complicated in exchange for no benefit, change it back to using mutex_lock. Signed-off-by: Rainer Weikusat --- Considering that the datagram receive routine also doesn't go the sleep with the mutex held anymore, the 37ab4fa7844a044dc21fde45e2a0fc2f3c

[PATCH] af_unix: Revert 'lock_interruptible' in stream receive code

reader. As the interruptible locking makes the code more complicated in exchange for no benefit, change it back to using mutex_lock. Signed-off-by: Rainer Weikusat <rweiku...@mobileactivedefense.com> --- Considering that the datagram receive routine also doesn't go the sleep with the mutex

[PATCH RFC] AF_UNIX SOCK_STREAM SO_PEEK_OFS oddity

issue) described above, it will actually print TWOTIMES twices followed by 12345678 while the NOTATALL remains invisible. If this is not the intended behaviour, I propose the patch below to fix it. It changes the code to reload the peek offset after the sleep. Signed-off-by: Rainer Weikusat <rweiku.

Re: [PATCH] fix inverted test in __skb_recv_datagram

David Miller writes: [...] > Please, in the future, place proper subsystem prefixes in your > Subject lines. In this case, "net: " would have been appropriate > and it wouldn't be the end of the world if you capitalized > your commit header line too. > > I fixed both of these things while

Re: [PATCH] fix inverted test in __skb_recv_datagram

As the kernel generally uses negated error numbers, *err needs to be compared with -EAGAIN (d'oh). Signed-off-by: Rainer Weikusat Fixes: ea3793ee29d3 ("core: enable more fine-grained datagram reception control") --- diff --git a/net/core/datagram.c b/net/core/datagram.c index 7daff6

Re: [PATCH] fix inverted test in __skb_recv_datagram

David Miller writes: > From: Rainer Weikusat > Date: Mon, 07 Dec 2015 23:30:58 + > >> As the kernel generally uses negated error numbers, *err needs to be >> compared with -EAGAIN (d'oh). >> >> Signed-off-by: Rainer Weikusat >> Fixes: ea3793ee29d3 &

Re: [PATCH] fix inverted test in __skb_recv_datagram

As the kernel generally uses negated error numbers, *err needs to be compared with -EAGAIN (d'oh). Signed-off-by: Rainer Weikusat <rweiku...@mobileactivedefense.com> Fixes: ea3793ee29d3 ("core: enable more fine-grained datagram reception control") --- diff --git a/net/core/datag

Re: [PATCH] fix inverted test in __skb_recv_datagram

David Miller <da...@davemloft.net> writes: > From: Rainer Weikusat <rweiku...@mobileactivedefense.com> > Date: Mon, 07 Dec 2015 23:30:58 + > >> As the kernel generally uses negated error numbers, *err needs to be >> compared with -EAGAIN (d'oh). >> &g

Re: [PATCH] fix inverted test in __skb_recv_datagram

David Miller writes: [...] > Please, in the future, place proper subsystem prefixes in your > Subject lines. In this case, "net: " would have been appropriate > and it wouldn't be the end of the world if you capitalized > your commit header line too. > > I fixed both of

[PATCH] fix inverted test in __skb_recv_datagram

As the kernel generally uses negated error numbers, *err needs to be compared with -EAGAIN (d'oh). Signed-off-by: Rainer Weikusat Fixes: ea3793ee29d3 --- diff --git a/net/core/datagram.c b/net/core/datagram.c index 7daff66..fa9dc64 100644 --- a/net/core/datagram.c +++ b/net/core/datagram.c

breaks blocking receive for other users (was: [PATCH 01/02] core: enable more fine-grained datagram reception control)

David Miller writes: > From: Rainer Weikusat > Date: Sun, 06 Dec 2015 21:11:34 + > >> The __skb_recv_datagram routine in core/ datagram.c provides a general >> skb reception factility supposed to be utilized by protocol modules >> providing datagram sockets. It

breaks blocking receive for other users (was: [PATCH 01/02] core: enable more fine-grained datagram reception control)

David Miller <da...@davemloft.net> writes: > From: Rainer Weikusat <rweiku...@mobileactivedefense.com> > Date: Sun, 06 Dec 2015 21:11:34 + > >> The __skb_recv_datagram routine in core/ datagram.c provides a general >> skb reception factility supposed t

[PATCH] fix inverted test in __skb_recv_datagram

As the kernel generally uses negated error numbers, *err needs to be compared with -EAGAIN (d'oh). Signed-off-by: Rainer Weikusat <rweiku...@mobileactivedefense.com> Fixes: ea3793ee29d3 --- diff --git a/net/core/datagram.c b/net/core/datagram.c index 7daff66..fa9dc64 100644 --- a/ne

[PATCH 01/02] core: enable more fine-grained datagram reception control

wait_for_more_packets to __skb_wait_for_more_packets, both routines being exported interfaces. The original __skb_recv_datagram routine is reimplemented on top of these two functions such that its user-visible behaviour remains unchanged. Signed-Off-By: Rainer Weikusat --- diff --git a/include/linux/skbuff.h b

[PATH 02/02] af_unix: fix unix_dgram_recvmsg entry locking

ilable regardless of any concurrent blocking readers and all blocking readers will end up sleeping via schedule_timeout, thus honouring the configured socket receive timeout. Signed-Off-By: Rainer Weikusat --- diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c index 45aebd9..47dfa97 100644 --- a/ne

[PATH 02/02] af_unix: fix unix_dgram_recvmsg entry locking

ilable regardless of any concurrent blocking readers and all blocking readers will end up sleeping via schedule_timeout, thus honouring the configured socket receive timeout. Signed-Off-By: Rainer Weikusat <rweiku...@mobileactivedefense.com> --- diff --git a/net/unix/af_unix.c b/net/unix/af_

[PATCH 01/02] core: enable more fine-grained datagram reception control

wait_for_more_packets to __skb_wait_for_more_packets, both routines being exported interfaces. The original __skb_recv_datagram routine is reimplemented on top of these two functions such that its user-visible behaviour remains unchanged. Signed-Off-By: Rainer Weikusat <rweiku...@mobileactivedefense.com> --

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

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 &

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

David Miller <da...@davemloft.net> writes: > From: Rainer Weikusat <rweiku...@mobileactivedefense.com> >> Rainer Weikusat <r...@doppelsaurus.mobileactivedefense.com> writes: >> >> [...] >> >>> Insofar I understand the comment in this code b

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

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

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

Rainer Weikusat <r...@doppelsaurus.mobileactivedefense.com> writes: [...] > Insofar I understand the comment in this code block correctly, > > err = mutex_lock_interruptible(>readlock); > if (unlikely(err)) { > /* recvmsg() in non b

[RFC PATCH] af_unix: fix entry locking in unix_dgram_recvmsg

help other future protocols which also need to use locks for protecting access to some per-socket state information the core/datagram.c code is unaware of. Signed-Off-By: Rainer Weikusat --- Patch is against 4.4.0-rc1-net. diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index 43

[RFC PATCH] af_unix: fix entry locking in unix_dgram_recvmsg

help other future protocols which also need to use locks for protecting access to some per-socket state information the core/datagram.c code is unaware of. Signed-Off-By: Rainer Weikusat <rweiku...@mobileactivedefense.com> --- Patch is against 4.4.0-rc1-net. diff --git a/include/linux/s

  1   2   3   >