linux-kernel - Re: [External] Re: [PATCH] mm:zswap: fix zswap entry reclamation failure in two scenarios

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACSyD1Nav7+zppx3BZS8vU5uF3AaBin0XOKCdtdQ1d6sA4wu9w@mail.gmail.com>
Date:   Thu, 16 Nov 2023 11:33:03 +0800
From:   贺中坤 <hezhongkun.hzk@...edance.com>
To:     Yosry Ahmed <yosryahmed@...gle.com>
Cc:     akpm@...ux-foundation.org, hannes@...xchg.org, nphamcs@...il.com,
        sjenning@...hat.com, ddstreet@...e.org, vitaly.wool@...sulko.com,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Ying <ying.huang@...el.com>
Subject: Re: [External] Re: [PATCH] mm:zswap: fix zswap entry reclamation
 failure in two scenarios

On Thu, Nov 16, 2023 at 4:13 AM Yosry Ahmed <yosryahmed@...gle.com> wrote:
>
> I think we may need to try to lock the folio. Otherwise we may race
> with reclaim reading the dirty bit before we set it.
>
> Taking a step back, this seems like we are going behind exclusive
> loads. We "should" keep the page in zswap as exclusive loads are
> disabled and the page is not yet invalidated from zswap (the swap
> entry is still in use). What you are trying to do here is sneakily
> drop the page from zswap as if we wrote it back, but we didn't.

If  we want to reclaim the cached zswap_entry, Writing back might
be the easy way.

> We just know that it was already loaded from zswap. We are essentially
> making the previous load exclusive retroactively.
>
> Is there a reason why exclusive loads cannot be enabled to achieve the
> same result in the (arguably) correct way?
>

zswap_exclusive_loads is not enabled by default, so the shrink_worker
may fail if there are many cached zswap_entries on the zswap_pool->lru.

Is it possible to make zswap_exclusive_loads the only way in zswap_load?
It only makes sense when the page is read and no longer dirty.
If the page is read frequently, it should stay in cache rather than zswap.
The benefit of doing this is very small, two copies of the same page
in memory.

Thanks.