netdev - Re: [PATCH net 2/2] rxrpc: Fix the data

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] [day] [month] [year] [list]

Message-ID: <f423612c-db54-b59d-d2f1-9449bb997106@gmail.com>
Date:   Fri, 5 Oct 2018 10:44:36 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     David Howells <dhowells@...hat.com>,
        Eric Dumazet <eric.dumazet@...il.com>
Cc:     netdev@...r.kernel.org, linux-afs@...ts.infradead.org,
        linux-kernel@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net 2/2] rxrpc: Fix the data_ready handler



On 10/05/2018 09:33 AM, David Howells wrote:
> Eric Dumazet <eric.dumazet@...il.com> wrote:
> 
>> sk_data_ready is not meant to process packets, it is meant to signal
>> to another entity (preferably running in process context and thus with proper
>> schedule points, and not blocking BH) that there is data ready to be consumed.
> 
> The issue is that I need to route the packets to the appropriate call, and the
> BH appears to be the right place to do this, especially as I can quickly parse
> and discard certain types of packet right there.
> 
> If I move all of this to process context then that adds extra context switches
> between the routing process and the destination process.
> 
>> Under DOS, it is possible multiple cpus will sk_data_ready in parallel.
> 
> Ummm...  I've been led to believe that sk_data_ready will *not* be called in
> parallel and that the code it calls can assume non-reentrancy.  Is this not
> the case.

Certainly not for UDP.

TCP input processing uses the socket lock, but UDP is fully parallel.

> 
> What about the patch I attached, whereby I use the encap_rcv() hook.  Do you
> say that won't work?

I am kind of busy today, will look at it next week.