linux-ext4 - Inode ENOSPC due to recently

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-next>] [day] [month] [year] [list]

Date:   Thu, 5 Mar 2020 18:14:31 +0100
From:   Jan Kara <jack@...e.cz>
To:     Ted Tso <tytso@....edu>
Cc:     linux-ext4@...r.kernel.org
Subject: Inode ENOSPC due to recently_deleted()

Hello!

Recently, I've got a bug report about ext4 driver regressing compared to
the old ext2 driver. The problem is that the filesystem is small and they
fill the fs (use all inodes), then delete some files, and then want to use
the inodes for other files but recently_deleted() logic makes the freed
inodes unusable and thus inode allocation fails with ENOSPC.

AFAIU the logic implemented by recently_deleted() is more of a preference
than a hard rule and we should rather reuse recently deleted inodes than
return ENOSPC. Am I right?

Also I'd note that the detection whether the inode was written out in
recently_deleted() is very inaccurate - one of the problems is that if
several inodes in the same inode table block are deleted, then after
writing out that block we'll be able to reuse only one of these inodes
because by doing that, we certainly cache and dirty the inode block and
thus the recently_deleted() logic for other deleted inodes will start to
apply. But I think we can just live with that if we stop making
recently_deleted() a hard rule...

What do people think?

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR