Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-23 Thread Rainer Weikusat
Rainer Weikusat writes: > David Miller writes: [...] > I'm sorry for this 13th hour request/ suggestion but while thinking > about a reply to Dmitry, it occurred to me that the restart_locked/ > sk_locked logic could be avoided by

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-23 Thread Jason Baron
On 11/20/2015 05:07 PM, Rainer Weikusat wrote: > Rainer Weikusat writes: > 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

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-23 Thread David Miller
From: Rainer Weikusat Date: Fri, 20 Nov 2015 22:07:23 + > Rainer Weikusat writes: > 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

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-23 Thread Rainer Weikusat
David Miller writes: > From: Rainer Weikusat >> Rainer Weikusat writes: >> An AF_UNIX datagram socket being the client in an n:1 association [...] > Applied and queued up for -stable, I'm sorry for

alternate queueing mechanism (was: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue)

2015-11-22 Thread Rainer Weikusat
Rainer Weikusat writes: [AF_UNIX SOCK_DGRAM throughput] > It may be possible to improve this by tuning/ changing the flow > control mechanism. Out of my head, I'd suggest making the queue longer > (the default value is 10) and delaying wake ups until the

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

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 &&

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-20 Thread Rainer Weikusat
Rainer Weikusat writes: 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

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

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

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

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

2015-11-18 Thread Rainer Weikusat
Rainer Weikusat writes: [...] > Some more information on this: Running the test program included below > on my 'work' system (otherwise idle, after logging in via VT with no GUI > running)/ quadcore AMD A10-5700, 3393.984 for 20 times/ patched 4.3

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

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-17 Thread Jason Baron
On 11/15/2015 01:32 PM, Rainer Weikusat wrote: > > That was my original idea. The problem with this is that the code > starting after the _lock and running until the main code path unlock has > to be executed in one go with the other lock held as the results of the > tests above this one may

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-17 Thread Rainer Weikusat
Jason Baron writes: > On 11/15/2015 01:32 PM, Rainer Weikusat wrote: > >> >> That was my original idea. The problem with this is that the code >> starting after the _lock and running until the main code path unlock has >> to be executed in one go with the other lock held as

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

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

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 >

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 >>

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

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

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

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-15 Thread Rainer Weikusat
Jason Baron writes: > On 11/13/2015 01:51 PM, Rainer Weikusat wrote: > > [...] > >> >> -if (unix_peer(other) != sk && unix_recvq_full(other)) { >> -if (!timeo) { >> -err = -EAGAIN; >> -goto out_unlock; >> -}

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-13 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

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-13 Thread Rainer Weikusat
Hannes Frederic Sowa writes: > On Wed, Nov 11, 2015, at 17:12, Rainer Weikusat wrote: >> Hannes Frederic Sowa writes: >> > On Tue, Nov 10, 2015, at 22:55, Rainer Weikusat wrote: >> >> An AF_UNIX datagram socket being the client in an n:1

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-13 Thread Jason Baron
On 11/13/2015 01:51 PM, Rainer Weikusat wrote: [...] > > - if (unix_peer(other) != sk && unix_recvq_full(other)) { > - if (!timeo) { > - err = -EAGAIN; > - goto out_unlock; > - } > + if (unix_peer(sk) == other &&

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-12 Thread Rainer Weikusat
Jason Baron writes: >> + >> +/* Needs sk unix state lock. After recv_ready indicated not ready, >> + * establish peer_wait connection if still needed. >> + */ >> +static int unix_dgram_peer_wake_me(struct sock *sk, struct sock *other) >> +{ >> +int connected; >> + >> +

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-11 Thread Jason Baron
Hi Rainer, > + > +/* Needs sk unix state lock. After recv_ready indicated not ready, > + * establish peer_wait connection if still needed. > + */ > +static int unix_dgram_peer_wake_me(struct sock *sk, struct sock *other) > +{ > + int connected; > + > + connected =

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-11 Thread Rainer Weikusat
Hannes Frederic Sowa writes: > On Tue, Nov 10, 2015, at 22:55, 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

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-11 Thread Hannes Frederic Sowa
Hi, On Wed, Nov 11, 2015, at 17:12, Rainer Weikusat wrote: > Hannes Frederic Sowa writes: > > On Tue, Nov 10, 2015, at 22:55, Rainer Weikusat wrote: > >> An AF_UNIX datagram socket being the client in an n:1 association with > >> some server socket is only allowed to

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-10 Thread Rainer Weikusat
Jason Baron writes: > On 11/09/2015 09:40 AM, Rainer Weikusat wrote: [...] >> -if (unix_peer(other) != sk && unix_recvq_full(other)) { >> +if (!unix_dgram_peer_recv_ready(sk, other)) { >> if (!timeo) { >> -err = -EAGAIN; >> -

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-10 Thread Rainer Weikusat
David Miller writes: > From: Rainer Weikusat > Date: Mon, 09 Nov 2015 14:40:48 + > >> +__remove_wait_queue(_sk(u->peer_wake.private)->peer_wait, >> +>peer_wake); > > This is more simply: > >

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-10 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

[PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-09 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

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-09 Thread David Miller
From: Rainer Weikusat Date: Mon, 09 Nov 2015 14:40:48 + > + __remove_wait_queue(_sk(u->peer_wake.private)->peer_wait, > + >peer_wake); This is more simply: __remove_wait_queue(_sk(u->peer_wake.private)->peer_wait, q);

Re: [PATCH] unix: avoid use-after-free in ep_remove_wait_queue

2015-11-09 Thread Jason Baron
On 11/09/2015 09:40 AM, 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