[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <93766ae3-30d9-4dd3-ba01-870cc6387df4@leemhuis.info>
Date: Thu, 18 Apr 2024 16:25:26 +0200
From: "Linux regression tracking (Thorsten Leemhuis)"
<regressions@...mhuis.info>
To: Johannes Weiner <hannes@...xchg.org>,
Christian Heusel <christian@...sel.eu>
Cc: Chengming Zhou <chengming.zhou@...ux.dev>, Nhat Pham <nphamcs@...il.com>,
Seth Jennings <sjenning@...hat.com>, Dan Streetman <ddstreet@...e.org>,
Vitaly Wool <vitaly.wool@...sulko.com>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, David Runge <dave@...epmap.de>,
"Richard W.M. Jones" <rjones@...hat.com>, Mark W <instruform@...il.com>,
regressions@...ts.linux.dev, Yosry Ahmed <yosryahmed@...gle.com>
Subject: Re: [REGRESSION] Null pointer dereference while shrinking zswap
On 18.04.24 14:40, Johannes Weiner wrote:
> On Wed, Apr 17, 2024 at 07:18:14PM +0200, Christian Heusel wrote:
>> On 24/04/17 10:33AM, Johannes Weiner wrote:
> Christian reports a NULL deref in zswap that he bisected down to the
> zswap shrinker. The issue also cropped up in the bug trackers of
> libguestfs [1] and the Red Hat bugzilla [2].
>
> The problem is that when memcg is disabled with the boot time flag,
> the zswap shrinker might get called with sc->memcg == NULL. This is
> okay in many places, like the lruvec operations. But it crashes in
> memcg_page_state() - which is only used due to the non-node accounting
> of cgroup's the zswap memory to begin with.
>
> Nhat spotted that the memcg can be NULL in the memcg-disabled case,
> and I was then able to reproduce the crash locally as well.
Thx for the fix. Nitpicking:
> [1] https://github.com/libguestfs/libguestfs/issues/139
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=2275252
FWIW, those should ideally look like this:
Link: https://github.com/libguestfs/libguestfs/issues/139 [1]
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2275252 [2]
> Fixes: b5ba474f3f51 ("zswap: shrink zswap pool based on memory pressure")
> Cc: stable@...r.kernel.org [v6.8]
> Link: https://lkml.kernel.org/r/20240417143324.GA1055428@cmpxchg.org
> Reported-by: Christian Heusel <christian@...sel.eu>
And here checkpatch.pl should have complained that the above line should
ideally be followed by a Link or Closes tag to the report, e.g.:
Closes:
https://lore.kernel.org/all/3iccc6vjl5gminut3lvpl4va2lbnsgku5ei2d7ylftoofy3n2v@gcfdvtsq6dx2/
Which in this case would be nice, as I'm tracking this regression, hence
regzbot will then track the patch and consider the regression resolved
once the fix lands in mainline.
Ciao, Thorsten
Powered by blists - more mailing lists