linux-kernel - Re: Circular lock dep in btrfs triggered by shrinker

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]

Message-ID: <20181023075330.GP18839@dhcp22.suse.cz>
Date:   Tue, 23 Oct 2018 09:53:30 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     David Sterba <dsterba@...e.cz>
Cc:     Olof Johansson <olof@...om.net>, dsterba@...e.de,
        linux-btrfs@...r.kernel.org, clm@...com,
        linux-kernel@...r.kernel.org
Subject: Re: Circular lock dep in btrfs triggered by shrinker

On Mon 22-10-18 20:22:43, David Sterba wrote:
> On Mon, Oct 22, 2018 at 03:07:26AM -0700, Olof Johansson wrote:
> > I hit the below circular locking dependency. Seems like the assumption made in
> > 712e36c5f2a7fa56 ("btrfs: use GFP_KERNEL in btrfs_alloc_inode") either isn't
> > true, or has since changed?
> 
> I think it must have been there from the beginning. There were reports
> of this lockdep warning like the below and IIRC a few more
> (https://lkml.kernel.org/r/20180627120523.GA2287@suse.cz), but without a
> resolution.
> 
> Incidentally, there was a fix that's now in the 4.20 pull and only after
> I had seen your report I realized that it was the fix for the warning:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git/commit/?h=for-4.20-part1&id=84de76a2fb217dc1b6bc2965cc397d1648aa1404
> 
> It disables the filesystem allocations using the memalloc_nofs mechanism
> around free space inode allocation, while my original patch expected
> only regular inodes created by VFS.

Wouldn't it be better/possible to take the mark the scope at the higher
level where you take the trans handle?
-- 
Michal Hocko
SUSE Labs