All of lore.kernel.org
 help / color / mirror / Atom feed
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: 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

  reply	other threads:[~2023-10-02 18:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-08  3:03 [PATCH] sched/headers: move struct sched_param out of uapi Kir Kolyshkin
2023-10-02 18:57 ` Ingo Molnar [this message]
2023-10-02 19:01 ` [tip: sched/core] sched/headers: Move 'struct sched_param' out of uapi, to work around glibc/musl breakage tip-bot2 for Kir Kolyshkin
2023-10-02 19:12 ` [PATCH] sched/headers: move struct sched_param out of uapi 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.
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.