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  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]
Date:   Wed, 25 Nov 2020 14:01:03 -0800
From:   Linus Torvalds <>
To:     Hugh Dickins <>
Cc:     Matthew Wilcox <>, Jan Kara <>,
        syzbot <>,
        Andreas Dilger <>,
        Ext4 Developers List <>,
        Linux Kernel Mailing List <>,
        syzkaller-bugs <>,
        "Theodore Ts'o" <>, Linux-MM <>,
        Oleg Nesterov <>,
        Andrew Morton <>,
        "Kirill A. Shutemov" <>,
        Nicholas Piggin <>,
        Alex Shi <>, Qian Cai <>,
        Christoph Hellwig <>,
        "Darrick J. Wong" <>,
        William Kucharski <>,
        Jens Axboe <>,
        linux-fsdevel <>,
        linux-xfs <>
Subject: Re: kernel BUG at fs/ext4/inode.c:LINE!

On Wed, Nov 25, 2020 at 1:30 PM Linus Torvalds
<> wrote:
> I'm not sure I'm willing to write and test the real patch, but it
> doesn't look _too_ nasty from just looking at the code. The bookmark
> thing makes it important to only actually clear the bit at the end (as
> does the handoff case anyway), but the way wake_up_page_bit() is
> written, that's actually very straightforward - just after the
> while-loop. That's when we've woken up everybody.

Actually, there's a problem. We don't know if we've done the hand-off
or not, so we don't know if we should clear the bit after waking
everybody up or not.

We set that WQ_FLAG_DONE bit for the hand-0off case, but only the
woken party sees that - the waker itself doesn't know about it (and we
have no good way to return it in that call chain: wake_up_page_bit ->
__wake_up_locked_key_bookmark -> __wake_up_common ->

We could easily hide the flag in the "bookmark" wait queue entry, but
that smells a bit hacky to me.

So I don't think it's worth it, unless somebody really wants to give it a try.

But if it turns out that the page ref change from Hugh causes some
unexpected problem, we do have this model as a backup.


Powered by blists - more mailing lists