[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o74cryhu.fsf@yhuang6-desk2.ccr.corp.intel.com>
Date: Wed, 25 Sep 2024 15:19:57 +0800
From: "Huang, Ying" <ying.huang@...el.com>
To: Nhat Pham <nphamcs@...il.com>
Cc: Yosry Ahmed <yosryahmed@...gle.com>, Baolin Wang
<baolin.wang@...ux.alibaba.com>, akpm@...ux-foundation.org,
hannes@...xchg.org, hughd@...gle.com, shakeel.butt@...ux.dev,
ryan.roberts@....com, chrisl@...nel.org, david@...hat.com,
kasong@...cent.com, willy@...radead.org, viro@...iv.linux.org.uk,
baohua@...nel.org, chengming.zhou@...ux.dev, linux-mm@...ck.org,
kernel-team@...a.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] remove SWAP_MAP_SHMEM
Nhat Pham <nphamcs@...il.com> writes:
[snip]
>
> My understanding now is that there are two for loops. One for loop
> that checks the entry's states, and one for loop that does the actual
> incrementing work (or state modification).
>
> We can check in the first for loop, if it is safe to proceed:
>
> if (!count && !has_cache) {
> err = -ENOENT;
> } else if (usage == SWAP_HAS_CACHE) {
> if (has_cache)
> err = -EEXIST;
> } else if ((count & ~COUNT_CONTINUED) > SWAP_MAP_MAX) {
> err = -EINVAL;
> } else if (usage == 1 && nr > 1 && (count & ~COUNT_CONTINUED) >=
> SWAP_MAP_MAX)) {
> /* the batched variants currently do not support rollback */
> err = -ENOMEM;
> }
>
> At this point, IIUC, we have not done any incrementing, so no rollback
> needed? :)
I think that it's better to add a VM_WARN_ONCE() here. If someone
enabled 'nr > 1' for __swap_duplicate(), the issue will be more
explicit.
[snip]
--
Best Regards,
Huang, Ying
Powered by blists - more mailing lists