[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a54778fd-576e-4344-b2c9-88625ee29919@amd.com>
Date: Mon, 14 Apr 2025 18:40:45 +0530
From: Shivank Garg <shivankg@....com>
To: Matthew Wilcox <willy@...radead.org>, shaggy@...nel.org
Cc: jfs-discussion@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
syzbot+8bb6fd945af4e0ad9299@...kaller.appspotmail.com, linux-mm@...ck.org
Subject: Re: [PATCH] jfs: implement migrate_folio for jfs_metapage_aops
On 4/14/2025 2:11 AM, Matthew Wilcox wrote:
> On Sun, Apr 13, 2025 at 05:23:57PM +0000, Shivank Garg wrote:
>> +++ b/fs/jfs/jfs_metapage.c
>> @@ -570,6 +570,7 @@ const struct address_space_operations jfs_metapage_aops = {
>> .release_folio = metapage_release_folio,
>> .invalidate_folio = metapage_invalidate_folio,
>> .dirty_folio = filemap_dirty_folio,
>> + .migrate_folio = filemap_migrate_folio,
>> };
>
> Ooh, damn, I think we're going to need more than this ;-(
>
> static inline struct metapage *folio_to_mp(struct folio *folio, int offset)
> {
> return folio->private;
> }
>
> struct metapage {
> ...
> void *data; /* Data pointer */
>
> So we're going to need something like buffer_migrate_folio(), but
> specialised to jfs metadata. And when we come up with it, that'll
> be Fixes: 35474d52c605
I'm able to come up with a revised patch but testing seem tricky.
I'm not sure how to trigger the metapage migration.
View attachment "0001-jfs-implement-migrate_folio-for-jfs_metapage_aops.patch" of type "text/plain" (6141 bytes)
Powered by blists - more mailing lists