Received: by 2002:a25:1104:0:0:0:0:0 with SMTP id 4csp292761ybr; Fri, 22 May 2020 06:51:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx1TYfmn2q1HeAI0IDcSOpE4vIfj/03YLxtOMJkDVhWsng9gGue9I2m0OEhi8UvQwjXzd0t X-Received: by 2002:a50:ee0b:: with SMTP id g11mr2968230eds.114.1590155463938; Fri, 22 May 2020 06:51:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590155463; cv=none; d=google.com; s=arc-20160816; b=zzGbk7oTpjTmdBzSW4p5Xd3LGvSs9SpgUZuMhBijaJ0Gelzo7phHe633cha1pYCY+B mLqg2PBmUM5prPHrvFjShwvQb3wV3cEZHjY3E+YfID7SXCqOeFzAOmt/w1Sh/gXImnai /aGbYTXiSvU5UpMxeBi4ux1tbf4bCyY0ossTYB1oWo5qvyX5NY87HaIqUIHKBGANZ2P3 WEbKf+nC3Gc29xFT9QYgTEsMR5QRgRambhhEFf9yeVldRTKjon4Hw3c8GA8szph9idv/ eCPt6hpHocHjZUl1xYlVaKfcyFIdpVCU54WJwaclwTgsWqFjPs1dCbRMjdgU07kz4wpx E7hw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=U+dI1yw6EfbVnOkPk7a+X1FsweCtb++2TrpmGQr/pCU=; b=S7lMzyVCn00lkUpqUE8oYPBV8Rd2y1C6Eo1YBdA+pBF9DqbflsAlfw6cC2ToeKWVeE RaznQz0O+CxVDGKVbvhZLHzKnpCSLRaKzJNKAlBUBrggI8bnNeYa7S9GdeFqWBKS5z0m ngXQvuReXdunQvUecYIrkxONTCE3UPNMWTJgUnqdkO5zLLhV67PWrj+KrO5HXuKEMM1D T4n04TKgp2dpuQRZHAtKbEGKb3MV75y7uZqymtytKJ62/xqVq5qd2ZscJIL6jqRUAbJo GJL6lR94jgArKataLUZecFkEERBPUg/u56uYBc3iCwzx+5chhrluIw/BhrTicbfsubYG 4B5g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k5si4584617edk.415.2020.05.22.06.50.38; Fri, 22 May 2020 06:51:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729929AbgEVNqx (ORCPT + 99 others); Fri, 22 May 2020 09:46:53 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:36161 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729406AbgEVNqx (ORCPT ); Fri, 22 May 2020 09:46:53 -0400 Received: from ip5f5af183.dynamic.kabel-deutschland.de ([95.90.241.131] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jc80g-0001Cc-Mb; Fri, 22 May 2020 13:46:50 +0000 Date: Fri, 22 May 2020 15:46:49 +0200 From: Christian Brauner To: Joel Fernandes Cc: LKML , Matthew Blecker , Jesse Barnes , Mike Frysinger , Christian Brauner , Vineeth Remanan Pillai , vineethrp@gmail.com, Peter Zijlstra , stable , Greg Kroah-Hartman Subject: Re: [PATCH RFC] sched/headers: Fix sched_setattr userspace compilation issues Message-ID: <20200522134649.lcqgwbgbnqxebcng@wittgenstein> References: <20200521155346.168413-1-joel@joelfernandes.org> <20200522131355.f4bdc2f4h2zyqbku@wittgenstein> <20200522133816.GB210175@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200522133816.GB210175@google.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 22, 2020 at 09:38:16AM -0400, Joel Fernandes wrote: > On Fri, May 22, 2020 at 03:13:55PM +0200, Christian Brauner wrote: > > On Thu, May 21, 2020 at 11:55:21AM -0400, Joel Fernandes wrote: > > > On Thu, May 21, 2020 at 11:53 AM Joel Fernandes (Google) > > > wrote: > > > > > > > > On a modern Linux distro, compiling the following program fails: > > > > #include > > > > #include > > > > #include > > > > #include > > > > > > > > void main() { > > > > struct sched_attr sa; > > > > > > > > return; > > > > } > > > > > > > > with: > > > > /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 is also causing a problem on using sched_attr Chrome. The issue is > > > > sched_param is already provided by glibc. > > > > > > > > Guard the kernel's UAPI definition of sched_param with __KERNEL__ so > > > > that userspace can compile. > > > > > > > > Signed-off-by: Joel Fernandes (Google) > > > > > > If it is more preferable, another option is to move sched_param to > > > include/linux/sched/types.h > > > > Might it be worth Ccing libc-alpha here? Seems like one of those classic > > header conflicts. > > sched_param is defined by POSIX from my reading of the manpage. Is the kernel > supposed to define it in the UAPI at all? I guarded it with __KERNEL__ as you > can see. Your patch is fine of course. :) It's just that conflicts like this have happened before. Another conflict is e.g. in wait.h where the kernel has #define P_* and libc has an enum for P_* and it's not at all guaranteed that they are identical. Plus, sometimes the order of header inclusion matters because of things like this (or something like this). That's why having it seen on libc-alpha might help prevent accidentaly causing bugs where you now include a header that gives you a different definition than you expected. > > Resent with libc-alpha CC'd per your suggestion. Thanks! Christian