From: Thomas Gleixner <tglx@linutronix.de>
To: Pranav Tyagi <pranav.tyagi03@gmail.com>
Cc: "Ingo Molnar" <mingo@redhat.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Darren Hart" <dvhart@infradead.org>,
"Davidlohr Bueso" <dave@stgolabs.net>,
"André Almeida" <andrealmeid@igalia.com>,
linux-kernel@vger.kernel.org, jann@thejh.net,
keescook@chromium.org, skhan@linuxfoundation.org,
linux-kernel-mentees@lists.linux.dev
Subject: Re: [PATCH] futex: don't leak robust_list pointer on exec race
Date: Wed, 30 Jul 2025 19:16:48 +0200 [thread overview]
Message-ID: <87pldhioov.ffs@tglx> (raw)
In-Reply-To: <CAH4c4jKmj2gwmW2LS8CuGyw6phtiN+=_Bef8_pSEzjnbsqPOeg@mail.gmail.com>
On Wed, Jul 30 2025 at 20:21, Pranav Tyagi wrote:
> On Fri, Jun 13, 2025 at 6:38 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> I face a small issue while refactoring the common code in a helper.
>
> The main obstacle to a full refactor is that the native and compat
> syscalls use different user-visible types (size_t vs compat_size_t,
> struct robust_list_head * vs compat_uptr_t). Because put_user() is
> type-checked at compile-time, I can’t unify both into one function
> without either unsafe casting or weakening type safety (this is as far
> as I understand).
>
> The best I can do is refactor the common task lookup/permission
> logic into a helper, and leave ABI-specific put_user() calls in thin wrappers.
These are two different SYSCALL() implementations, so they
can deal with the difference sizes of put_user() there.
Thanks,
tglx
next prev parent reply other threads:[~2025-07-30 17:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-07 6:44 [PATCH] futex: don't leak robust_list pointer on exec race Pranav Tyagi
2025-06-09 9:45 ` Thomas Gleixner
2025-06-11 14:03 ` Pranav Tyagi
2025-06-13 13:08 ` Thomas Gleixner
2025-06-18 6:20 ` Pranav Tyagi
2025-07-24 17:37 ` Kees Cook
2025-07-25 11:43 ` Pranav Tyagi
2025-07-30 14:51 ` Pranav Tyagi
2025-07-30 17:16 ` Thomas Gleixner [this message]
2025-08-04 7:01 ` Pranav Tyagi
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=87pldhioov.ffs@tglx \
--to=tglx@linutronix.de \
--cc=andrealmeid@igalia.com \
--cc=dave@stgolabs.net \
--cc=dvhart@infradead.org \
--cc=jann@thejh.net \
--cc=keescook@chromium.org \
--cc=linux-kernel-mentees@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pranav.tyagi03@gmail.com \
--cc=skhan@linuxfoundation.org \
/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.