From: Joel Fernandes <joel@joelfernandes.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Matthew Blecker <matthewb@google.com>,
Jesse Barnes <jsbarnes@google.com>,
Mike Frysinger <vapier@google.com>,
Christian Brauner <christian@brauner.io>,
vpillai <vpillai@digitalocean.com>,
vineethrp@gmail.com, Peter Zijlstra <peterz@infradead.org>,
stable <stable@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
mingo@kernel.org
Subject: Re: [PATCH] sched/headers: Fix sched_setattr userspace compilation breakage
Date: Thu, 28 May 2020 21:45:24 -0400 [thread overview]
Message-ID: <20200529014524.GA38759@google.com> (raw)
In-Reply-To: <CAHk-=whf6b=OijDL=+PUTBsrhURzLZQ5xAq5tWDqOQpTmePFDA@mail.gmail.com>
On Thu, May 28, 2020 at 04:23:26PM -0700, Linus Torvalds wrote:
> On Thu, May 28, 2020 at 4:09 PM Joel Fernandes <joel@joelfernandes.org> wrote:
> >
> > > So no, this patch is fundamentally wrong. It negates the whole point
> > > of having a uapi header at all.
> >
> > Sorry, I naively assumed that headers in 'include/uapi/' are safe to include
> > from userspace. I feel terrible.
>
> Well, they "kind of" are safe to include.
>
> It's just that normally they are meant for system integrators to
> include as part of the system header files. So they are designed not
> to be safe for normal programs, but for library writers.
>
> And to make things more confusing, sometimes people _do_ include
> kernel header files directly, just because they want to get features
> that either haven't been exposed by the system libraries, or because
> the system libraries copied the uapi header files for an older version
> of the kernel, and you want the shiny new feature, so...
>
> And some of those header files are easier to do that with than others...
Got it. Thank you Linus for the detailed reply, I really appreciate that.
> > The problem is <sched.h> still does not get us 'struct sched_attr' even
> > though the manpage of sched_setattr(2) says including <sched.h> is all that's
> > needed.
>
> Ouch. But clearly you get it from -somewhere- since it then complains
> about the double declaration.
>
> Strange.
The reason is, since <sched.h> did not provide struct sched_attr as the
manpage said, so I did the include of uapi's linux/sched/types.h myself:
#include <sched.h>
// inclusion of this header to get struct sched_attr will break due to
// another structure struct sched_param redefinition.
#include <linux/sched/types.h>
glibc's <sched.h> already defines struct sched_param (which is a POSIX
struct), so my inclusion of <linux/sched/types.h> above which is a UAPI
header exported by the kernel, breaks because the following commit moved
sched_param into the UAPI:
e2d1e2aec572a ("sched/headers: Move various ABI definitions to <uapi/linux/sched/types.h>")
Simply reverting that part of the patch also fixes it, like below. Would
that be an acceptable fix? Then I can go patch glibc to get struct
sched_attr by including the UAPI's <linux/sched/types.h>. Otherwise, I
suspect glibc will also break if it tried to include the UAPI header.
If this is the wrong fix still, I'm sorry and I'll continue to research the
solution.
> > Also, even if glibc included 'include/uapi/linux/sched/types.h' to get struct
> > sched_attr's definition, we would run into the same issue I reported right?
> > The 'struct sched_param' is already defined by glibc, and this header
> > redefines it.
>
> That's kind of the point: glibc sets up whatever system headers it
> wants. The uapi ones are there to _help_ it, but it's not like glibc
> _has_ to use them.
>
> In fact, traditionally we didn't have any uapi header files at all,
> and we just expected the system libraries to scrape them and make
> their own private copies.
>
> The uapi headers are _meant_ to make that easier, and to allow system
> headers to then co-exists with the inevitable "I need to get newer
> headers because I'm using a bleeding edge feature that glibc isn't
> exposing" crowd.
>
> Put another way: a very non-portable programs _could_ include the uapi
> headers directly, if the system library headers were set up that way.
This might be painful for struct sched_attr because new attributes keep
getting added to it, so having the UAPI help glibc and other libcs in this
regard might be attractive.
---8<-----------------------
From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
Subject: [PATCH] sched/headers: Fix sched_setattr userspace compilation
This is a partial revert of e2d1e2aec572a to fix the following.
On a modern Linux distro, compiling the following program fails:
#include<stdlib.h>
#include<stdint.h>
// pthread.h includes sched.h internally.
#include<pthread.h>
// inclusion of this header to get struct sched_attr will break due to
// struct sched_param redefinition.
#include<linux/sched/types.h>
void main() {
struct sched_attr sa;
return;
}
Compiler errors are:
/usr/include/linux/sched/types.h:8:8: \
error: redefinition of ‘struct sched_param’
8 | struct sched_param {
| ^~~~~~~~~~~
In file included from /usr/include/x86_64-linux-gnu/bits/sched.h:74,
from /usr/include/sched.h:43,
from /usr/include/pthread.h:23,
from /tmp/s.c:4:
/usr/include/x86_64-linux-gnu/bits/types/struct_sched_param.h:23:8:
note: originally defined here
23 | struct sched_param
| ^~~~~~~~~~~
This also causes a problem with using sched_attr in Chrome. The issue is
sched_param is already provided by glibc.
Fixes: e2d1e2aec572a ("sched/headers: Move various ABI definitions to <uapi/linux/sched/types.h>"
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
---
include/linux/sched.h | 5 ++++-
include/uapi/linux/sched/types.h | 4 ----
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index fc2d2ede2d9ef..e6917b9d919fd 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -55,13 +55,16 @@ struct robust_list_head;
struct root_domain;
struct rq;
struct sched_attr;
-struct sched_param;
struct seq_file;
struct sighand_struct;
struct signal_struct;
struct task_delay_info;
struct task_group;
+struct sched_param {
+ int sched_priority;
+};
+
/*
* Task state bitmask. NOTE! These bits are also
* encoded in fs/proc/array.c: get_task_state().
diff --git a/include/uapi/linux/sched/types.h b/include/uapi/linux/sched/types.h
index c852153ddb0d3..f863e747ff5f8 100644
--- a/include/uapi/linux/sched/types.h
+++ b/include/uapi/linux/sched/types.h
@@ -4,10 +4,6 @@
#include <linux/types.h>
-struct sched_param {
- int sched_priority;
-};
-
#define SCHED_ATTR_SIZE_VER0 48 /* sizeof first published struct */
#define SCHED_ATTR_SIZE_VER1 56 /* add: util_{min,max} */
--
2.27.0.rc0.183.gde8f92d652-goog
next prev parent reply other threads:[~2020-05-29 1:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-28 13:55 [PATCH] sched/headers: Fix sched_setattr userspace compilation breakage Joel Fernandes (Google)
2020-05-28 22:21 ` Linus Torvalds
2020-05-28 23:08 ` Joel Fernandes
2020-05-28 23:23 ` Linus Torvalds
2020-05-29 1:45 ` Joel Fernandes [this message]
2020-05-29 2:17 ` Linus Torvalds
2020-05-29 16:17 ` Joel Fernandes
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=20200529014524.GA38759@google.com \
--to=joel@joelfernandes.org \
--cc=christian@brauner.io \
--cc=gregkh@linuxfoundation.org \
--cc=jsbarnes@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthewb@google.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vapier@google.com \
--cc=vineethrp@gmail.com \
--cc=vpillai@digitalocean.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.