linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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 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).