mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Kemeng Shi <shikemeng@huaweicloud.com>
Cc: kasong@tencent.com, nphamcs@gmail.com, bhe@redhat.com,
	baohua@kernel.org, chrisl@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: swap: correctly use maxpages in swapon syscall to avoid potential deadloop
Date: Sat, 19 Jul 2025 17:34:55 -0700	[thread overview]
Message-ID: <20250719173455.35f8082916a76a416764d32d@linux-foundation.org> (raw)
In-Reply-To: <20250718065139.61989-1-shikemeng@huaweicloud.com>

On Fri, 18 Jul 2025 14:51:39 +0800 Kemeng Shi <shikemeng@huaweicloud.com> wrote:

> We use maxpages from read_swap_header() to initialize swap_info_struct,
> however the maxpages might be reduced in setup_swap_extents() and the
> si->max is assigned with the reduced maxpages from the
> setup_swap_extents().
> 
> Obviously, this could lead to memory waste as we allocated memory based on
> larger maxpages, besides, this could lead to a potential deadloop as
> following:
> 
> 1) When calling setup_clusters() with larger maxpages, unavailable
>    pages within range [si->max, larger maxpages) are not accounted with
>    inc_cluster_info_page().  As a result, these pages are assumed
>    available but can not be allocated.  The cluster contains these pages
>    can be moved to frag_clusters list after it's all available pages were
>    allocated.
> 
> 2) When the cluster mentioned in 1) is the only cluster in
>    frag_clusters list, cluster_alloc_swap_entry() assume order 0
>    allocation will never failed and will enter a deadloop by keep trying
>    to allocate page from the only cluster in frag_clusters which contains
>    no actually available page.
> 
> Call setup_swap_extents() to get the final maxpages before
> swap_info_struct initialization to fix the issue.
> 
> After this change, span will include badblocks and will become large
> value which I think is correct value:
> In summary, there are two kinds of swapfile_activate operations.
> 1. Filesystem style: Treat all blocks logical continuity and find
> usable physical extents in logical range. In this way, si->pages
> will be actual usable physical blocks and span will be "1 +
> highest_block - lowest_block".
> 2. Block device style: Treat all blocks physically continue and
> only one single extent is added. In this way, si->pages will be
> si->max and span will be "si->pages - 1".
> Actually, si->pages and si->max is only used in block device style
> and span value is set with si->pages. As a result, span value in
> block device style will become a larger value as you mentioned.
> 
> I think larger value is correct based on:
> 1. Span value in filesystem style is "1 + highest_block -
> lowest_block" which is the range cover all possible phisical blocks
> including the badblocks.
> 2. For block device style, si->pages is the actual usable block
> number and is already in pr_info. The original span value before
> this patch is also refer to usable block number which is redundant
> in pr_info.
>
> Link: https://lkml.kernel.org/r/20250522122554.12209-3-shikemeng@huaweicloud.com
> Fixes: 661383c6111a ("mm: swap: relaim the cached parts that got scanned")
> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
> Reviewed-by: Baoquan He <bhe@redhat.com>
> ---
> v1->v2:
> -Fix typo
> -Add description of behavior change of "span" in git log

I queued this change:

> -Ensure si->pages == si->max - 1 after setup_swap_extents()

as a -fix against the v1 patch and updated the base patch's changelog,
thanks.

--- a/mm/swapfile.c~mm-swap-correctly-use-maxpages-in-swapon-syscall-to-avoid-potensial-deadloop-fix
+++ a/mm/swapfile.c
@@ -3357,6 +3357,12 @@ SYSCALL_DEFINE2(swapon, const char __use
 		error = nr_extents;
 		goto bad_swap_unlock_inode;
 	}
+	if (si->pages != si->max - 1) {
+		pr_err("swap:%u != (max:%u - 1)\n", si->pages, si->max);
+		error = -EINVAL;
+		goto bad_swap_unlock_inode;
+	}
+
 	maxpages = si->max;
 
 	/* OK, set up the swap map and apply the bad block list */
_


      reply	other threads:[~2025-07-20  0:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-18  6:51 Kemeng Shi
2025-07-20  0:34 ` Andrew Morton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250719173455.35f8082916a76a416764d32d@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=bhe@redhat.com \
    --cc=chrisl@kernel.org \
    --cc=kasong@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nphamcs@gmail.com \
    --cc=shikemeng@huaweicloud.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®