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  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:   Thu, 17 Sep 2020 12:00:06 -0700
From:   Linus Torvalds <>
To:     Matthew Wilcox <>
Cc:     Michael Larabel <>,
        Matthieu Baerts <>,
        Amir Goldstein <>,
        "Ted Ts'o" <>,
        Andreas Dilger <>,
        Ext4 Developers List <>,
        Jan Kara <>,
        linux-fsdevel <>
Subject: Re: Kernel Benchmarking

On Thu, Sep 17, 2020 at 11:50 AM Matthew Wilcox <> wrote:
> Ahh.  Here's a race this doesn't close:
> int truncate_inode_page(struct address_space *mapping, struct page *page)

I think this one currently depends on the page lock, doesn't it?

And I think the point would be to get rid of that dependency, and just
make the rule be that it's done with the i_mmap_rwsem held for

But it might be one of those cases where taking it for writing might
add way too much serialization and might not be acceptable.

Again, I do get the feeling that a spinlock would be much better here.
Generally the areas we want to protect are truly just the trivial
"check that mapping is valid". That's a spinlock kind of thing, not a
semaphore kind of thing.

Doing a blocking semaphore that might need to serialize IO with page
faulting for the whole mapping is horrible and completely
unacceptable. Truncation events might be rare, but they aren't unheard

But doing a spinlock that does the same is likely a complete non-issue.


Powered by blists - more mailing lists