linux-kernel - Re: [PATCH 2/2] vfs: grab the lock instead of blocking in __fd

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]

Date:   Wed, 4 Oct 2017 07:00:40 -0700
From:   Eric Dumazet <edumazet@...gle.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Mateusz Guzik <mguzik@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>, mszeredi@...hat.com,
        linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] vfs: grab the lock instead of blocking in
 __fd_install during resizing

On Wed, Oct 4, 2017 at 6:55 AM, Matthew Wilcox <willy@...radead.org> wrote:
> On Tue, Oct 03, 2017 at 07:41:11AM -0700, Eric Dumazet wrote:
>> On Tue, Oct 3, 2017 at 3:58 AM, Mateusz Guzik <mguzik@...hat.com> wrote:
>> > Explicit locking in the fallback case provides a safe state of the
>> > table. Getting rid of blocking semantics makes __fd_install usable
>> > again in non-sleepable contexts, which easies backporting efforts.
>> >
>> > There is a side effect of slightly nicer assembly for the common case
>> > as might_sleep can now be removed.
>> >
>> > Signed-off-by: Mateusz Guzik <mguzik@...hat.com>
>> > ---
>> >  Documentation/filesystems/porting |  4 ----
>> >  fs/file.c                         | 11 +++++++----
>> >  2 files changed, 7 insertions(+), 8 deletions(-)
>>
>> Nice change !
>>
>> Reviewed-by: Eric Dumazet <edumazet@...gle.com>
>
> Hey Eric,
>
> Any chance you could review the patches from Sandhya that make this entire
> codepath obsolete?
>
> https://lkml.org/lkml/2017/4/29/20
>

Hmm...

18 files changed, 578 insertions(+), 585 deletions(-)

Frankly I need to be convinced with solid performance numbers before I
am taking a look at this series.

I do not believe an IDR will be faster than current implementation, so
I am not quite convinced at this moment.

Thanks.