Rainer Weikusat writes:
> Jason Baron writes:
>> On 10/18/2015 04:58 PM, Rainer Weikusat wrote:
[...]
>> 1)
>>
>> In unix_peer_wake_relay() function, 'sk_wq' is an __rcu pointer and thus
>> it requires proper dereferencing. Something like:
>>
>> struct unix_sock *u;
>> struct socket_wq *wq;
>>
Jason Baron writes:
> On 10/18/2015 04:58 PM, Rainer Weikusat wrote:
>
> [...]
>
>>
>> The idea behind 'the wait queue' (insofar I'm aware of it) is that it
>> will be used as list of threads who need to be notified when the
>> associated event occurs. Since you seem to argue that the run-of-the-
On 10/18/2015 04:58 PM, Rainer Weikusat wrote:
[...]
>
> The idea behind 'the wait queue' (insofar I'm aware of it) is that it
> will be used as list of threads who need to be notified when the
> associated event occurs. Since you seem to argue that the run-of-the-mill
> algorithm is too slow fo
Jason Baron writes:
>
>>
>> X-Signed-Off-By: Rainer Weikusat
>>
Sorry for the delayed reply but I had to do some catching up on what the
people who pay me consider 'useful work' :-).
> So the patches I've posted and yours both use the idea of a relaying
> the remote peer wakeup via callb
>
> X-Signed-Off-By: Rainer Weikusat
>
Hi,
So the patches I've posted and yours both use the idea of a relaying
the remote peer wakeup via callbacks that are internal to the net/unix,
such that we avoid exposing the remote peer wakeup to the external
poll()/select()/epoll(). They differ i
Jason Baron writes:
> On 10/12/2015 04:41 PM, Rainer Weikusat wrote:
>> Jason Baron writes:
>>> On 10/05/2015 12:31 PM, Rainer Weikusat wrote:
[...]
>> OTOH, something I seriously dislike about your relaying implementation
>> is the unconditional add_wait_queue upon connect as this builds up a
On 10/12/2015 04:41 PM, Rainer Weikusat wrote:
> Jason Baron writes:
>> On 10/05/2015 12:31 PM, Rainer Weikusat wrote:
>
> [...]
>
>>> Here's a more simple idea which _might_ work. The underlying problem
>>> seems to be that the second sock_poll_wait introduces a covert reference
>>> to the peer
Jason Baron writes:
> On 10/05/2015 12:31 PM, Rainer Weikusat wrote:
[...]
>> Here's a more simple idea which _might_ work. The underlying problem
>> seems to be that the second sock_poll_wait introduces a covert reference
>> to the peer socket which isn't accounted for. The basic idea behind th
On 10/05/2015 12:31 PM, Rainer Weikusat wrote:
> Jason Baron writes:
>> The unix_dgram_poll() routine calls sock_poll_wait() not only for the wait
>> queue associated with the socket s that we are poll'ing against, but also
>> calls
>> sock_poll_wait() for a remote peer socket p, if it is connect
Eric Dumazet writes:
> On Mon, 2015-10-05 at 17:31 +0100, Rainer Weikusat wrote:
>
>> atomic_long_set(&u->inflight, 0);
>> INIT_LIST_HEAD(&u->link);
>> @@ -2135,8 +2139,16 @@ static unsigned int unix_poll(struct fil
>> static unsigned int unix_dgram_poll(struct file *file, struct socket
On Mon, 2015-10-05 at 17:31 +0100, Rainer Weikusat wrote:
> atomic_long_set(&u->inflight, 0);
> INIT_LIST_HEAD(&u->link);
> @@ -2135,8 +2139,16 @@ static unsigned int unix_poll(struct fil
> static unsigned int unix_dgram_poll(struct file *file, struct socket *sock,
>
Jason Baron writes:
> The unix_dgram_poll() routine calls sock_poll_wait() not only for the wait
> queue associated with the socket s that we are poll'ing against, but also
> calls
> sock_poll_wait() for a remote peer socket p, if it is connected. Thus,
> if we call poll()/select()/epoll() for th
Rainer Weikusat writes:
> Mathias Krause writes:
>> On 2 October 2015 at 22:43, Jason Baron wrote:
>>> The unix_dgram_poll() routine calls sock_poll_wait() not only for the wait
>>> queue associated with the socket s that we are poll'ing against, but also
>>> calls
>
> [useless full-quote remo
Mathias Krause writes:
> On 2 October 2015 at 22:43, Jason Baron wrote:
>> The unix_dgram_poll() routine calls sock_poll_wait() not only for the wait
>> queue associated with the socket s that we are poll'ing against, but also
>> calls
[useless full-quote removed]
> My reproducer runs on this
On 2 October 2015 at 22:43, Jason Baron wrote:
> The unix_dgram_poll() routine calls sock_poll_wait() not only for the wait
> queue associated with the socket s that we are poll'ing against, but also
> calls
> sock_poll_wait() for a remote peer socket p, if it is connected. Thus,
> if we call pol
The unix_dgram_poll() routine calls sock_poll_wait() not only for the wait
queue associated with the socket s that we are poll'ing against, but also calls
sock_poll_wait() for a remote peer socket p, if it is connected. Thus,
if we call poll()/select()/epoll() for the socket s, there are then
a cou
16 matches
Mail list logo
