Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:)

2015-11-20 Thread Rainer Weikusat
Jason Baron writes: > On 11/19/2015 06:52 PM, Rainer Weikusat wrote: > > [...] > >> @@ -1590,21 +1718,35 @@ restart: >> goto out_unlock; >> } >> >> -if (unix_peer(other) != sk && unix_recvq_full(other)) { >> -if (!timeo) { >> +if (unlikely(unix_peer(

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:)

2015-11-20 Thread Jason Baron
On 11/19/2015 06:52 PM, Rainer Weikusat wrote: [...] > @@ -1590,21 +1718,35 @@ restart: > goto out_unlock; > } > > - if (unix_peer(other) != sk && unix_recvq_full(other)) { > - if (!timeo) { > + if (unlikely(unix_peer(other) != sk && unix_recvq_fu

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:)

2015-11-19 Thread Rainer Weikusat
An AF_UNIX datagram socket being the client in an n:1 association with some server socket is only allowed to send messages to the server if the receive queue of this socket contains at most sk_max_ack_backlog datagrams. This implies that prospective writers might be forced to go to sleep despite no

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:)

2015-11-19 Thread Rainer Weikusat
Rainer Weikusat writes: > Rainer Weikusat writes: > > [...] > >> The basic options would be >> >> - return EAGAIN even if sending became possible (Jason's most >> recent suggestions) >> >> - retry sending a limited number of times, eg, once, before >> returning EAGAI

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:)

2015-11-18 Thread Rainer Weikusat
David Miller writes: > From: Rainer Weikusat > Date: Mon, 16 Nov 2015 22:28:40 + > >> An AF_UNIX datagram socket being the client in an n:1 [...] > So because of a corner case of epoll handling and sender socket release, > every single datagram sendmsg has to do a double lock now? > > I do

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:)

2015-11-17 Thread Rainer Weikusat
Rainer Weikusat writes: [...] > This leaves only the option of a somewhat incorrect solution and what is > or isn't acceptable in this respect is somewhat difficult to decide. The > basic options would be [...] > - retry sending a limited number of times, eg, once, before > retu

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:)

2015-11-17 Thread Rainer Weikusat
Rainer Weikusat writes: [...] > The basic options would be > > - return EAGAIN even if sending became possible (Jason's most > recent suggestions) > > - retry sending a limited number of times, eg, once, before > returning EAGAIN, on the grounds that this is nicer

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:)

2015-11-17 Thread Rainer Weikusat
David Miller writes: > From: Rainer Weikusat > Date: Mon, 16 Nov 2015 22:28:40 + > >> An AF_UNIX datagram socket being the client in an n:1 association with >> some server socket is only allowed to send messages to the server if the >> receive queue of this socket contains at most sk_max_ack_

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:)

2015-11-17 Thread David Miller
From: Rainer Weikusat Date: Mon, 16 Nov 2015 22:28:40 + > An AF_UNIX datagram socket being the client in an n:1 association with > some server socket is only allowed to send messages to the server if the > receive queue of this socket contains at most sk_max_ack_backlog > datagrams. This impl

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:)

2015-11-17 Thread Jason Baron
On 11/16/2015 05:28 PM, Rainer Weikusat wrote: > An AF_UNIX datagram socket being the client in an n:1 association with > some server socket is only allowed to send messages to the server if the > receive queue of this socket contains at most sk_max_ack_backlog > datagrams. This implies that pros

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue (w/ Fixes:)

2015-11-16 Thread Rainer Weikusat
An AF_UNIX datagram socket being the client in an n:1 association with some server socket is only allowed to send messages to the server if the receive queue of this socket contains at most sk_max_ack_backlog datagrams. This implies that prospective writers might be forced to go to sleep despite no