From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Pedro Falcato <pfalcato@suse.de>, Breno Leitao <leitao@debian.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>,
Kemeng Shi <shikemeng@huaweicloud.com>,
Nhat Pham <nphamcs@gmail.com>, Baoquan He <baoquan.he@linux.dev>,
Barry Song <baohua@kernel.org>,
Youngjun Park <youngjun.park@lge.com>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Jann Horn <jannh@google.com>,
Hugh Dickins <hughd@google.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Peter Xu <peterx@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Yosry Ahmed <yosry@kernel.org>,
Chengming Zhou <chengming.zhou@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com
Subject: Re: [PATCH 3/3] mm: fail the fault on a malformed swap entry instead of retrying it
Date: Wed, 12 Aug 2026 13:03:41 +0200 [thread overview]
Message-ID: <b7238caa-cc47-4811-a395-4784350ba599@kernel.org> (raw)
In-Reply-To: <anxRBd_LJaHmtzDS@pedro-suse>
On 8/12/26 12:59, Pedro Falcato wrote:
> On Mon, Aug 10, 2026 at 09:26:51AM -0700, Breno Leitao wrote:
>> do_swap_page() returns 0 when get_swap_device() fails, which the fault
>> handler reads as "handled". For an entry that can never become valid
>> the retry takes the same fault again, so the thread spins until it is
>> killed.
>>
>> Return VM_FAULT_SIGBUS for a malformed entry, as the sibling arm
>> already does for an unrecognised non-swap entry. A NULL return still
>> means swapoff, which is still worth retrying.
>
> What kind of SIGBUS do you get from this? as in the si_code. Out of all
> the options
>
> #define BUS_ADRALN 1 /* invalid address alignment */
> #define BUS_ADRERR 2 /* non-existent physical address */
> #define BUS_OBJERR 3 /* object specific hardware error */
> /* hardware memory error consumed on a machine check: action required */
> #define BUS_MCEERR_AR 4
> /* hardware memory error detected in process but not consumed: action optional*/
> #define BUS_MCEERR_AO 5
>
> I would say this would fit none of them. The default (AFAICT) would be
> BUS_ADRERR, and I think that one is quite overloaded with meaning (namely,
> with regards to memory-mapped IO past EOF, or EIO on file IO). I wouldn't
> love to also use it for this, IMO.
Note that what is discussed here that should usually happen unless kernel bug.
So I don't think we have to worry about the details here, really.
It's similar to the VM_FAULT_SIGBUS handling earlier in the function after the
print_bad_pte().
--
Cheers,
David
next prev parent reply other threads:[~2026-08-12 11:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 16:26 [PATCH 0/3] mm, swap: don't spin or flood the console on a bad swap entry Breno Leitao
2026-08-10 16:26 ` [PATCH 1/3] mm, swap: ratelimit bad swap entry reports in get_swap_device() Breno Leitao
2026-08-11 15:33 ` David Hildenbrand (Arm)
2026-08-11 16:48 ` Pedro Falcato
2026-08-12 10:37 ` Breno Leitao
2026-08-12 10:58 ` David Hildenbrand (Arm)
2026-08-10 16:26 ` [PATCH 2/3] mm, swap: distinguish a malformed swap entry from a dying device Breno Leitao
2026-08-11 15:36 ` David Hildenbrand (Arm)
2026-08-12 10:48 ` Breno Leitao
2026-08-12 11:00 ` David Hildenbrand (Arm)
2026-08-12 11:02 ` Pedro Falcato
2026-08-12 11:06 ` David Hildenbrand (Arm)
2026-08-10 16:26 ` [PATCH 3/3] mm: fail the fault on a malformed swap entry instead of retrying it Breno Leitao
2026-08-11 15:38 ` David Hildenbrand (Arm)
2026-08-12 10:50 ` Breno Leitao
2026-08-12 10:59 ` Pedro Falcato
2026-08-12 11:03 ` David Hildenbrand (Arm) [this message]
2026-08-10 17:20 ` [PATCH 0/3] mm, swap: don't spin or flood the console on a bad swap entry Andrew Morton
2026-08-12 11:05 ` Breno Leitao
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=b7238caa-cc47-4811-a395-4784350ba599@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=baoquan.he@linux.dev \
--cc=chengming.zhou@linux.dev \
--cc=chrisl@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=jannh@google.com \
--cc=kasong@tencent.com \
--cc=kernel-team@meta.com \
--cc=leitao@debian.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=nphamcs@gmail.com \
--cc=peterx@redhat.com \
--cc=pfalcato@suse.de \
--cc=rppt@kernel.org \
--cc=shikemeng@huaweicloud.com \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=yosry@kernel.org \
--cc=youngjun.park@lge.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.