linux-kernel - Re: [stable] ext4 fscrypt_get_encryption

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201211040807.GF1667627@google.com>
Date:   Fri, 11 Dec 2020 13:08:07 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        "Theodore Y. Ts'o" <tytso@....edu>,
        Suleiman Souhlal <suleiman@...gle.com>,
        linux-fscrypt@...r.kernel.org, stable@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [stable] ext4 fscrypt_get_encryption_info() circular locking
 dependency

On (20/12/10 19:48), Eric Biggers wrote:
> > 
> > [  133.454836] Chain exists of:
> >                  jbd2_handle --> fscrypt_init_mutex --> fs_reclaim
> > 
> > [  133.454840]  Possible unsafe locking scenario:
> > 
> > [  133.454841]        CPU0                    CPU1
> > [  133.454843]        ----                    ----
> > [  133.454844]   lock(fs_reclaim);
> > [  133.454846]                                lock(fscrypt_init_mutex);
> > [  133.454848]                                lock(fs_reclaim);
> > [  133.454850]   lock(jbd2_handle);
> > [  133.454851] 
> 
> This actually got fixed by the patch series
> https://lkml.kernel.org/linux-fscrypt/20200913083620.170627-1-ebiggers@kernel.org/
> which went into 5.10.  The more recent patch to remove ext4_dir_open() isn't
> related.
> 
> It's a hard patch series to backport.  Backporting it to 5.4 would be somewhat
> feasible, while 4.19 would be very difficult as there have been a lot of other
> fscrypt commits which would heavily conflict with cherry-picks.
> 
> How interested are you in having this fixed?  Did you encounter an actual
> deadlock or just the lockdep report?

Difficult to say. On one hand 'yes' I see lockups on my devices (4.19
kernel); I can't tell at the moment what's the root cause. So on the
other hand 'no' I can't say that it's because of ext4_dir_open().

What I saw so far involved ext4, kswapd, khugepaged and lots of other things.

[ 1598.655901] INFO: task khugepaged:66 blocked for more than 122 seconds.
[ 1598.655914] Call Trace:
[ 1598.655920]  __schedule+0x506/0x1240
[ 1598.655924]  ? kvm_zap_rmapp+0x52/0x69
[ 1598.655927]  schedule+0x3f/0x78
[ 1598.655929]  __rwsem_down_read_failed_common+0x186/0x201
[ 1598.655933]  call_rwsem_down_read_failed+0x14/0x30
[ 1598.655936]  down_read+0x2e/0x45
[ 1598.655939]  rmap_walk_file+0x73/0x1ce
[ 1598.655941]  page_referenced+0x10d/0x154
[ 1598.655948]  shrink_active_list+0x1d4/0x475

[..]

[ 1598.655986] INFO: task kswapd0:79 blocked for more than 122 seconds.
[ 1598.655993] Call Trace:
[ 1598.655995]  __schedule+0x506/0x1240
[ 1598.655998]  schedule+0x3f/0x78
[ 1598.656000]  __rwsem_down_read_failed_common+0x186/0x201
[ 1598.656003]  call_rwsem_down_read_failed+0x14/0x30
[ 1598.656006]  down_read+0x2e/0x45
[ 1598.656008]  rmap_walk_file+0x73/0x1ce
[ 1598.656010]  page_referenced+0x10d/0x154
[ 1598.656015]  shrink_active_list+0x1d4/0x475

[..]

[ 1598.658233]  __rwsem_down_read_failed_common+0x186/0x201
[ 1598.658235]  call_rwsem_down_read_failed+0x14/0x30
[ 1598.658238]  down_read+0x2e/0x45
[ 1598.658240]  rmap_walk_file+0x73/0x1ce
[ 1598.658242]  page_referenced+0x10d/0x154
[ 1598.658247]  shrink_active_list+0x1d4/0x475
[ 1598.658250]  shrink_node+0x27e/0x661
[ 1598.658254]  try_to_free_pages+0x425/0x7ec
[ 1598.658258]  __alloc_pages_nodemask+0x80b/0x1514
[ 1598.658279]  __do_page_cache_readahead+0xd4/0x1a9
[ 1598.658282]  filemap_fault+0x346/0x573
[ 1598.658287]  ext4_filemap_fault+0x31/0x44

	-ss