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 moving the test for this condition
> in front of all the others
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 this 13th hour request/ suggestion but while thinking
about a reply to Dmitry, it occurred to m
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 server if the
> receive queue of this socket contains at most sk_max_ack_bac
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 at most sk_max_ack_backlog
> datagr
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 server
> actually did catch up, IOW, the
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 prospective writers might be forced
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(
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
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
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
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 resulted
> in the
> following throughput statis
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
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
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
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_
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
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 the results of the
>>
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
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 be
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
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
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;
>> -}
>> +if (unix_pee
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 && !unix_dg
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 association with
>> >> some server socket is only allowed t
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
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;
>> +
>> +connected = unix_dgra
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 send messages to the server i
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 = unix_dgram_peer_wake_conn
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 contains at most sk_max_ack_ba
Hello,
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 contains at most sk_max_ack_backlog
> datagrams. This imp
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
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;
>> -goto out_u
David Miller writes:
> From: Rainer Weikusat
> Date: Mon, 09 Nov 2015 14:40:48 +
>
>> +__remove_wait_queue(&unix_sk(u->peer_wake.private)->peer_wait,
>> +&u->peer_wake);
>
> This is more simply:
>
> __remove_wait_queue(&unix_sk(u->peer_wake.private)->peer_wai
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 prospe
From: Rainer Weikusat
Date: Mon, 09 Nov 2015 14:40:48 +
> + __remove_wait_queue(&unix_sk(u->peer_wake.private)->peer_wait,
> + &u->peer_wake);
This is more simply:
__remove_wait_queue(&unix_sk(u->peer_wake.private)->peer_wait, q);
> +static inline int un
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
Jason Baron writes:
> On 11/06/2015 08:06 AM, Dmitry Vyukov wrote:
>> On Mon, Oct 12, 2015 at 2:17 PM, Dmitry Vyukov wrote:
>>> On Mon, Oct 12, 2015 at 2:14 PM, Eric Dumazet
>>> wrote:
On Mon, 2015-10-12 at 14:02 +0200, Michal Kubecek wrote:
> Probably the issue discussed in
>
On 11/06/2015 08:06 AM, Dmitry Vyukov wrote:
> On Mon, Oct 12, 2015 at 2:17 PM, Dmitry Vyukov wrote:
>> On Mon, Oct 12, 2015 at 2:14 PM, Eric Dumazet wrote:
>>> On Mon, 2015-10-12 at 14:02 +0200, Michal Kubecek wrote:
>>>
Probably the issue discussed in
http://thread.gmane.org/gm
On Mon, Oct 12, 2015 at 2:17 PM, Dmitry Vyukov wrote:
> On Mon, Oct 12, 2015 at 2:14 PM, Eric Dumazet wrote:
>> On Mon, 2015-10-12 at 14:02 +0200, Michal Kubecek wrote:
>>
>>> Probably the issue discussed in
>>>
>>> http://thread.gmane.org/gmane.linux.kernel/2057497/
>>>
>>> and previous relate
On Mon, Oct 12, 2015 at 2:14 PM, Eric Dumazet wrote:
> On Mon, 2015-10-12 at 14:02 +0200, Michal Kubecek wrote:
>
>> Probably the issue discussed in
>>
>> http://thread.gmane.org/gmane.linux.kernel/2057497/
>>
>> and previous related threads.
>>
>
> Same issue, but Dmitry apparently did not trus
On Mon, 2015-10-12 at 14:02 +0200, Michal Kubecek wrote:
> Probably the issue discussed in
>
> http://thread.gmane.org/gmane.linux.kernel/2057497/
>
> and previous related threads.
>
Same issue, but Dmitry apparently did not trust me.
--
To unsubscribe from this list: send the line "unsubs
On Mon, Oct 12, 2015 at 01:07:55PM +0200, Dmitry Vyukov wrote:
> Hello,
>
> The following program causes use-after-in kernel:
>
...
> long r0 = syscall(SYS_mmap, 0x20001000ul, 0x1000ul, 0x3ul,
> 0x32ul, 0xul, 0x0ul);
> long r1 = syscall(SYS_mmap, 0x2000ul, 0x10
Hello,
The following program causes use-after-in kernel:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
int main()
{
long r0 = syscall(SYS_mmap, 0x20001000ul, 0x1000ul, 0x3ul,
0x32ul, 0xul, 0x0ul);
long r1 = syscal
43 matches
Mail list logo
