From: Greg KH <gregkh@linuxfoundation.org>
To: Kang Wenlin <wenlin.kang@windriver.com>
Cc: stable@vger.kernel.org, viro@zeniv.linux.org.uk,
brauner@kernel.org, ebiederm@xmission.com, keescook@chromium.org,
akpm@linux-foundation.org
Subject: Re: [PATCH 6.6.y 0/6] Backported patches to fix selftest tpdir2
Date: Tue, 8 Apr 2025 11:06:20 +0200 [thread overview]
Message-ID: <2025040819-unabashed-maximum-8fc8@gregkh> (raw)
In-Reply-To: <17b170ac-aa20-4c36-a045-25d2f82e66d0@windriver.com>
On Fri, Apr 04, 2025 at 03:58:36PM +0800, Kang Wenlin wrote:
> Hi Greg
>
> Thanks for your response.
>
>
> On 4/3/2025 22:52, Greg KH wrote:
> > CAUTION: This email comes from a non Wind River email account!
> > Do not click links or open attachments unless you recognize the sender and know the content is safe.
> >
> > On Wed, Apr 02, 2025 at 04:26:50PM +0800, Kang Wenlin wrote:
> > > From: Wenlin Kang <wenlin.kang@windriver.com>
> > >
> > > The selftest tpdir2 terminated with a 'Segmentation fault' during loading.
> > >
> > > root@localhost:~# cd linux-kenel/tools/testing/selftests/arm64/abi && make
> > > root@localhost:~/linux-kernel/tools/testing/selftests/arm64/abi# ./tpidr2
> > > Segmentation fault
> > >
> > > The cause of this is the __arch_clear_user() failure.
> > >
> > > load_elf_binary() [fs/binfmt_elf.c]
> > > -> if (likely(elf_bss != elf_brk) && unlikely(padzero(elf_bes)))
> > > -> padzero()
> > > -> clear_user() [arch/arm64/include/asm/uaccess.h]
> > > -> __arch_clear_user() [arch/arm64/lib/clear_user.S]
> > >
> > > For more details, please see:
> > > https://lore.kernel.org/lkml/1d0342f3-0474-482b-b6db-81ca7820a462@t-8ch.de/T/
> > This is just a userspace issue (i.e. don't do that, and if you do want
> > to do that, use a new kernel!)
> >
> > Why do these changes need to be backported, do you have real users that
> > are crashing in this way to require these changes?
>
>
> This issue was identified during our internal testing, and I found
> similar cases discussed in the link above. Upon reviewing the kernel
> code, I noticed that a patch series already accepted into mainline
> addresses this problem. Since these patches are already upstream
> and effectively resolve the issue, I decided to backport them.
> We believe this provides a more robust and maintainable solution
> compared to relying on users to avoid the triggering behavior.
Fixing something just to get the selftests to pass is fine, but do you
actually know of a real-world case where this is a problem that needs to
be resolved? That's what I'm asking here, do you have users that have
run into this issue? I ask as it's not a regression from what I can
determine, but rather a new "feature".
thanks,
greg k-h
next prev parent reply other threads:[~2025-04-08 9:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-02 8:26 [PATCH 6.6.y 0/6] Backported patches to fix selftest tpdir2 Kang Wenlin
2025-04-02 8:26 ` [PATCH 6.6.y 1/6] binfmt_elf: Support segments with 0 filesz and misaligned starts Kang Wenlin
2025-04-02 21:25 ` Sasha Levin
2025-04-02 8:26 ` [PATCH 6.6.y 2/6] binfmt_elf: elf_bss no longer used by load_elf_binary() Kang Wenlin
2025-04-02 21:25 ` Sasha Levin
2025-04-02 8:26 ` [PATCH 6.6.y 3/6] binfmt_elf: Use elf_load() for interpreter Kang Wenlin
2025-04-02 21:25 ` Sasha Levin
2025-04-02 8:26 ` [PATCH 6.6.y 4/6] binfmt_elf: Use elf_load() for library Kang Wenlin
2025-04-02 21:25 ` Sasha Levin
2025-04-02 8:26 ` [PATCH 6.6.y 5/6] binfmt_elf: Only report padzero() errors when PROT_WRITE Kang Wenlin
2025-04-02 21:25 ` Sasha Levin
2025-04-02 8:26 ` [PATCH 6.6.y 6/6] mm: Remove unused vm_brk() Kang Wenlin
2025-04-02 21:25 ` Sasha Levin
2025-04-03 14:52 ` [PATCH 6.6.y 0/6] Backported patches to fix selftest tpdir2 Greg KH
2025-04-04 7:58 ` Kang Wenlin
2025-04-08 9:06 ` Greg KH [this message]
2025-04-08 9:50 ` Wenlin Kang
2025-04-08 9:55 ` Greg KH
2025-04-08 14:39 ` Kang Wenlin
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=2025040819-unabashed-maximum-8fc8@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=wenlin.kang@windriver.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.