[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJD7tkbC5drsA2s+=sxXGGm+2RAFXbqs_21KrGaWav_LKjA68w@mail.gmail.com>
Date: Mon, 17 Apr 2023 04:31:11 -0700
From: Yosry Ahmed <yosryahmed@...gle.com>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: Yu Zhao <yuzhao@...gle.com>, Minchan Kim <minchan@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCHv4 0/4] zsmalloc: fine-grained fullness and new compaction algorithm
On Mon, Apr 17, 2023 at 4:24 AM Sergey Senozhatsky
<senozhatsky@...omium.org> wrote:
>
> On (23/04/17 04:16), Yosry Ahmed wrote:
> > > That's a good question to which I don't have an answer. We can list_add()
> > > the same zspage twice, unlocking the pool after first list_add() so that
> > > another process (including another zs_compact()) can do something to that
> > > zspage. The answer is somewhere between these lines, I guess.
> >
> > But the first list_add() is (in this case) the correct add, so we
> > expect other processes to be able to access the zspage after the first
> > list_add() anyway, right?
>
> Correct. Compaction also can unlock pool->lock and schedule() so that
> another process can access the source zspage, when compaction gets
> scheduled it can attempt putback/unlock the same zspage one more time
> (the zspage may not even exist at this point, I assume).
Good point, that could very well be where the corruption is coming
from. Thanks for pointing this out.
Powered by blists - more mailing lists