netdev - Re: [RFC] please clarify local_irq_disable() in pcpu_freelist

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: <a4e7d2cb-de19-5449-fddd-8606d8ab6602@fb.com>
Date:   Sun, 29 Oct 2017 13:21:21 -0700
From:   Alexei Starovoitov <ast@...com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
CC:     <tglx@...utronix.de>, <peterz@...radead.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        <netdev@...r.kernel.org>
Subject: Re: [RFC] please clarify local_irq_disable() in
 pcpu_freelist_populate()

On 10/29/17 1:14 PM, Sebastian Andrzej Siewior wrote:
> On 2017-10-27 19:18:40 [-0700], Alexei Starovoitov wrote:
>> pcpu_freelist_push() is called by bpf programs from atomic context.
>
> so raw would still be correct because the content is locked.

it would be incorrect because this_* versions have good checks in them
and no need to avoid them.

>> lockdep thinks that __pcpu_freelist_push() can be called recursively
>> in the middle of pcpu_freelist_populate's loop and will deadlock
>> which is not the case here. That's why local_irq_save() is there.
>> Just to silence lockdep.
>
> do you mind giving me bunch of test-cases so I can test it myself?

samples/bpf/map_perf_test*

>> While developing pcpu_freelist I've benchmarked many different
>> approaches. Some of the numbers are in
>> commit 6c9059817432 ("bpf: pre-allocate hash map elements")
>> iirc I passed on llist, since llist_del_first still needs a lock,
>> so doesn't really help.
>
> Okay. I will look that up.
>
> Sebastian
>