mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Jan Kara <jack@suse.cz>
Cc: Deepakkumar Karn <dkarn@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] mm/filemap: make release_folio mandatory and add block_release_folio
Date: Mon, 22 Dec 2025 15:13:26 +0000	[thread overview]
Message-ID: <aUlgFi2KKyxKMrtG@casper.infradead.org> (raw)
In-Reply-To: <g6godudsfgxzjfv74ffsgn2ad655g5quouct4uwqyor2hz3kz2@tqebhniyncw7>

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].

GCC does have an optional warning (-Woverride-init) which is included in
-W but not -Wall.  Some parts of the kernel explicitly turn this off, either
like this:

arch/arm64/kvm/Makefile:CFLAGS_sys_regs.o += -Wno-override-init

or like this:

drivers/gpu/drm/i915/display/intel_display_device.c:__diag_ignore_all("-Woverride-init", "Allow field initialization overrides for display info");

I'd be happy to do either of those for filesystems.


[1] Test program:

struct ops { void (*frob)(void); };

static void my_frob(void) { return; }
void generic_frob(void);

struct ops my_ops = {
        .frob = generic_frob,
        .frob = my_frob,
};

int main(void)
{
        return 0;
}

$ gcc -Wall -o test2 test2.c

links without any missing symbols

  reply	other threads:[~2025-12-22 15:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-19 19:37 Deepakkumar Karn
2025-12-22 12:38 ` Jan Kara
2025-12-22 15:13   ` Matthew Wilcox [this message]
2025-12-22 15:48     ` Jan Kara
2025-12-23 18:19       ` Deepak Karn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aUlgFi2KKyxKMrtG@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=dkarn@redhat.com \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®