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: <20220304024843.GK3927073@dread.disaster.area>
Date:   Fri, 4 Mar 2022 13:48:43 +1100
From:   Dave Chinner <david@...morbit.com>
To:     Jaegeuk Kim <jaegeuk@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] vfs: do not try to evict inode when super is frozen

On Thu, Mar 03, 2022 at 06:21:04PM -0800, Jaegeuk Kim wrote:
> Otherwise, we will get a deadlock.

NACK.

We have to be able to evict clean inodes from memory on frozen
inodes because we can still instantiate inodes while the filesytem
is frozen. e.g. there's a find running when the filesystem is
frozen. What happens if we can't evict clean cached inodes from
memory when we run out of memory trying to instantiate new inodes?

> 
> [freeze test]                         shrinkder
> freeze_super
>  - pwercpu_down_write(SB_FREEZE_FS)
>                                        - super_cache_scan
>                                          - down_read(&sb->s_umount)
>                                            - prune_icache_sb
>                                             - dispose_list
>                                              - evict
>                                               - f2fs_evict_inode
> thaw_super
>  - down_write(&sb->s_umount);
>                                               - __percpu_down_read(SB_FREEZE_FS)

That seems like a f2fs bug, not a generic problem.

Filesystems already have to handle stuff like this if an unlinked
file is closed while the fs is frozen - we have to handle inode
eviction needing to modify the file, and different filesystems
handle this differently. Most filesystems simply block in
->evict_inode in this case, but this never occurs from the shrinker
context.

IOWs, the shrinker should never be evicting inodes that require the
filesystem to immediately block on frozen filesystems. If you have
such inodes in cache at the time the filesystem is frozen, then they
should be purged from the cache as part of the freeze process so the
shrinker won't ever find inodes that it could deadlock on.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ