linux-kernel - Re: [RFC PATCH] mm/filemap: make release_folio mandatory and add block_release

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

Message-ID: <qtbn5tijoatgo4kkaeseloqhjg4krfet4zfmpcqqu6phy7s2tl@2v7dt3amy5pl>
Date: Mon, 22 Dec 2025 16:48:03 +0100
From: Jan Kara <jack@...e.cz>
To: Matthew Wilcox <willy@...radead.org>
Cc: Jan Kara <jack@...e.cz>, Deepakkumar Karn <dkarn@...hat.com>, 
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] mm/filemap: make release_folio mandatory and add
 block_release_folio

On Mon 22-12-25 15:13:26, Matthew Wilcox wrote:
> On Mon, Dec 22, 2025 at 01:38:51PM +0100, Jan Kara wrote:
> > > Filesystems updated: adfs, affs, bfs, exfat, ext2, fat, hpfs, isofs,
> > > jfs, minix, nilfs2, ntfs3, omfs, udf, ufs, plus block/fops.c
> > 
> > I think affs_aops_ofs need .release_folio as well...
> > 
> > Also befs_aops, ecryptfs_aops, efs_aops, vxfs_aops, hfs_aops, hfsplus_aops,
> > nilfs_buffer_cache_aops, qnx4_aops, qnx6_aops definitely need .release_folio. ntfs_aops_cmpr
> > might need it as well - not sure.
> 
> If we were using a real programming language, we'd have a class for
> BH-based filesystems, inherit from it and override each method.  But since
> we aren't, let's see what we can do in C ...
> 
> #define BH_DEFAULT_AOPS						\
> 	.dirty_folio		= block_dirty_folio,		\
> 	.invalidate_folio	= block_invalidate_folio,	\
> 	.migrate_folio		= buffer_migrate_folio,		\
> 	.is_partially_uptodate  = block_is_partially_uptodate,	\
> 	.error_remove_folio     = generic_error_remove_folio,
> 
> As I understand C, later initialisers override earlier ones [1].

Frankly, I'm not 100% convinced this will be a win and there is definitely
a potential for surprises because filesystems tend to do weird things so
this will need to carefully go filesystem by filesystem... So I wouldn't
complicate this patch with a change like this. Let's clean up
.release_folio first and we can look into cutting boilerplate
initializations later.

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