From: Ingo Molnar <mingo@kernel.org>
To: Kir Kolyshkin <kolyshkin@gmail.com>
Cc: linux-kernel@vger.kernel.org, libc-alpha@sourceware.org,
musl@lists.openwall.com, linux-api@vger.kernel.org,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Joel Fernandes <joel@joelfernandes.org>,
Christian Brauner <brauner@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: [musl] Re: [PATCH] sched/headers: move struct sched_param out of uapi
Date: Mon, 2 Oct 2023 20:57:31 +0200 [thread overview]
Message-ID: <ZRsSm7vDnMVEEk/f@gmail.com> (raw)
In-Reply-To: <20230808030357.1213829-1-kolyshkin@gmail.com>
* Kir Kolyshkin <kolyshkin@gmail.com> wrote:
> Both glibc and musl define struct sched_param in sched.h, while kernel
> has it in uapi/linux/sched/types.h, making it cumbersome to use
> sched_getattr(2) or sched_setattr(2) from userspace.
>
> For example, something like this:
>
> #include <sched.h>
> #include <linux/sched/types.h>
>
> struct sched_attr sa;
>
> will result in "error: redefinition of ‘struct sched_param’" (note the
> code doesn't need sched_param at all -- it needs struct sched_attr
> plus some stuff from sched.h).
>
> The situation is, glibc is not going to provide a wrapper for
> sched_{get,set}attr, thus the need to include linux/sched_types.h
> directly, which leads to the above problem.
Meh, I truly detest this patch, because 'struct sched_param' is very much
part of the syscall ABI signature:
include/linux/syscalls.h:
asmlinkage long sys_sched_setparam(pid_t pid,
struct sched_param __user *param);
asmlinkage long sys_sched_setscheduler(pid_t pid, int policy,
struct sched_param __user *param);
asmlinkage long sys_sched_getparam(pid_t pid,
struct sched_param __user *param);
... but OTOH let's not pretend that UAPI headers have much justification
to exist unless they are useful & can be utilized in some of the most
common user-space library environments as-is. Namespace collisions happen.
So I'm inclined to apply this workaround, but changed the title and added
the caveat below to the changelog:
sched/headers: Move 'struct sched_param' out of uapi, to work around glibc/musl breakage
...
Oh, and here is the previous attempt to fix the issue:
https://lore.kernel.org/all/20200528135552.GA87103@google.com/
While I support Linus arguments, the issue is still here
and needs to be fixed.
[ mingo: Linus is right, this shouldn't be needed - but on the other
hand I agree that this header is not really helpful to
user-space as-is. So let's pretend that
<uapi/linux/sched/types.h> is only about sched_attr, and
call this commit a workaround for user-space breakage
that it in reality is ... Also, remove the Fixes tag. ]
So unless Linus objects, I'll apply this to tip:sched/core for a v6.7 merge.
Thanks,
Ingo
next prev parent reply other threads:[~2023-10-02 18:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-08 3:03 [musl] " Kir Kolyshkin
2023-10-02 18:57 ` Ingo Molnar [this message]
2023-10-02 19:12 ` [musl] " enh
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=ZRsSm7vDnMVEEk/f@gmail.com \
--to=mingo@kernel.org \
--cc=brauner@kernel.org \
--cc=joel@joelfernandes.org \
--cc=kolyshkin@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=musl@lists.openwall.com \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).