[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aD4boBrdZXtz_5kL@casper.infradead.org>
Date: Mon, 2 Jun 2025 22:46:08 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
Hugh Dickins <hughd@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] mm: Fix compile error when CONFIG_SHMEM is not set
On Mon, Jun 02, 2025 at 05:14:58PM -0400, Steven Rostedt wrote:
> On Mon, 2 Jun 2025 17:05:00 -0400
> Steven Rostedt <rostedt@...dmis.org> wrote:
>
> > From: Steven Rostedt <rostedt@...dmis.org>
> >
> > When CONFIG_SHMEM is not set, the following compiler error occurs:
> >
> > ld: vmlinux.o: in function `ttm_backup_backup_page':
>
> I'm not sure this is the right fix or not.
> > +int shmem_writeout(struct folio *folio, struct writeback_control *wbc)
> > +{
> > + return 0;
>
> Perhaps this should return:
>
> return swap_writeout(folio, wbc);
I don't think so. ttm_backup_backup_page() gets its page from:
to_folio = shmem_read_folio_gfp(mapping, idx, alloc_gfp);
...
ret = shmem_writeout(to_folio, &wbc);
and if you look at the implementation of shmem_read_folio_gfp() does:
#else
/*
* The tiny !SHMEM case uses ramfs without swap
*/
return mapping_read_folio_gfp(mapping, index, gfp);
#endif
so I would say that if anybody is actually using it this way (and 99%
chance they're not), they literally cannot write back the folio. So
I think your initial patch is fine.
Powered by blists - more mailing lists