linux-kernel - Re: [PATCH] mm: zswap: fix zswap_never_enabled() for CONFIG

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

Message-Id: <20240702190224.99d97227a02bbbe4f140f845@linux-foundation.org>
Date: Tue, 2 Jul 2024 19:02:24 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Yosry Ahmed <yosryahmed@...gle.com>
Cc: Barry Song <21cnbao@...il.com>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, Barry Song <v-songbaohua@...o.com>, Nhat Pham
 <nphamcs@...il.com>, Chengming Zhou <chengming.zhou@...ux.dev>, Chris Li
 <chrisl@...nel.org>, David Hildenbrand <david@...hat.com>, Johannes Weiner
 <hannes@...xchg.org>, Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH] mm: zswap: fix zswap_never_enabled() for
 CONFIG_ZSWAP==N

On Tue, 2 Jul 2024 04:58:05 -0700 Yosry Ahmed <yosryahmed@...gle.com> wrote:

> > > --- a/include/linux/zswap.h
> > > +++ b/include/linux/zswap.h
> > > @@ -68,7 +68,7 @@ static inline bool zswap_is_enabled(void)
> > >
> > >  static inline bool zswap_never_enabled(void)
> > >  {
> > > -     return false;
> > > +     return true;
> > >  }
> >
> > Well, that code was as wrong as it's possible to get.
> >
> > But what effect does this have?  Seems "not much"?  Perhaps we'll
> > attempt a zswap_load() which later fails for other reasons?
> 
> Actually zswap_load() is a noop with !CONFIG_ZSWAP, so it doesn't have
> an effect there. The only effect is that with Barry's latest large
> folio swapin patches for zram, we will always fallback to order-0
> swapin, even mistakenly when !CONFIG_ZSWAP.
> 
> Basically the bug just makes Barry's in progress patches not work at all.

OK, thanks, I added this to the changelog:

The only effect of this issue is that with Barry's latest large folio
swapin patches for zram ("mm: support mTHP swap-in for zRAM-like
swapfile"), we will always fallback to order-0 swapin, even mistakenly
when !CONFIG_ZSWAP.

Basically this bug makes Barry's in progress patches not work at all.