Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
Sender: Ingo Molnar <mingo.kernel.org@gmail.com>
Date:   Mon, 2 Oct 2023 20:57:31 +0200
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
Message-ID: <ZRsSm7vDnMVEEk/f@gmail.com>
References: <20230808030357.1213829-1-kolyshkin@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20230808030357.1213829-1-kolyshkin@gmail.com>
Precedence: bulk


* 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