lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d45a3acc1003030338m3102a95p1b06b7db1b24e58e@mail.gmail.com>
Date:	Wed, 3 Mar 2010 22:38:21 +1100
From:	andrew hendry <andrew.hendry@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Zhu Yi <yi.zhu@...el.com>, netdev@...r.kernel.org
Subject: Re: [PATCH 8/8] x25: use limited socket backlog

Will wait for the next spin and in the meantime think if there is way
to test it.
x25 with no loopback and being so slow probably cant generate the same
as your UDP case.

Andrew.

On Wed, Mar 3, 2010 at 6:08 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> Le mercredi 03 mars 2010 à 14:35 +0800, Zhu Yi a écrit :
>> Make x25 adapt to the limited socket backlog change.
>>
>> Cc: Andrew Hendry <andrew.hendry@...il.com>
>> Signed-off-by: Zhu Yi <yi.zhu@...el.com>
>> ---
>>  net/x25/x25_dev.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/x25/x25_dev.c b/net/x25/x25_dev.c
>> index 3e1efe5..5688123 100644
>> --- a/net/x25/x25_dev.c
>> +++ b/net/x25/x25_dev.c
>> @@ -53,7 +53,7 @@ static int x25_receive_data(struct sk_buff *skb, struct x25_neigh *nb)
>>               if (!sock_owned_by_user(sk)) {
>>                       queued = x25_process_rx_frame(sk, skb);
>>               } else {
>> -                     sk_add_backlog(sk, skb);
>> +                     __sk_add_backlog(sk, skb);
>>               }
>>               bh_unlock_sock(sk);
>>               sock_put(sk);
>
> Please respin your patch the other way
>
> Ie: let sk_add_backlog(sk, skb) do its previous job (not leaking skbs,
> and returning a void status)
>
> Add a new function able to no limit backlog, and returns an error code,
> so that caller can free skb and increment SNMP counters accordingly.
>
> Callers MUST test return value, or use another helper that can free the
> skb for them.
>
> Name it sk_move_backlog() for example
>
> This will permit you to split the work as you tried.
>
> sk_add_backlog() could be redefined as the helper :
>
> void sk_add_backlog(sk, skb)
> {
>        if (sk_move_backlog(sk, skb)) {
>                kfree_skb(skb);
>                atomic_inc(&sk->sk_drops);
>        }
>
> }
>
> Thanks
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ