From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2009 invoked from network); 2 Oct 2023 18:57:51 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 2 Oct 2023 18:57:51 -0000 Received: (qmail 5687 invoked by uid 550); 2 Oct 2023 18:57:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 5660 invoked from network); 2 Oct 2023 18:57:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696273054; x=1696877854; darn=lists.openwall.com; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc:subject:date:message-id:reply-to; bh=6otIAIPh5XIg1eGDA9+e/nRojsDL+BWNZmCLTXEiHIA=; b=Io0pbX335tF8umfr3RZGefWZ859W7Ftdfwqb3yp4K9KsQmT3jMzdzK7kzpecunNAvE MaZga56/fniXtqC+uEobK9CHEkF00sXeyNhEXt4KEM6NF2+4JTYie3udnPbUS7kjemRr x8C+6FIuhB2HLgKYsY2AnOHOmfnkTkS+ntpErZRJSxE/E3fkbUkrl7hpswPWyORhsMKt Vb8b5dTdADFuNgUpSILMHgJOyozNBNymIc4IhPA/P6LaIRFGGlgK9cLziw1kVcMP5wvI uKgMsfzJkG/KjRa+6g0hXEAhqI9CAmE1Gev45u1Hq/KuFt4hMnSAOokciNHBGZoVXpUm 9gdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696273054; x=1696877854; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6otIAIPh5XIg1eGDA9+e/nRojsDL+BWNZmCLTXEiHIA=; b=HvEJVb3ivdotzWWh7IYR5YzplgxbBNscmYXpL9IHuo7aDRuWQlI/ooh9piLQkAix6a ofudAf0dYICGLC9ZZKTx6SZDOMpKY/aTScHXOpTIwIP+hx7tGTEdsp1XidXOFJjgXIC5 FmFcQP86pBh7wCAXTetA2AyL0AgFTSXpjgbQ1f3g9E21QLZjkXe628j85rPlu451k7q5 ZFnfTYn7qWIMyqx0zJnuABS7RAtLrDHeSILaekg9TzQ0UH2c/ZjSzBCHRYFLEhIDfr46 KX2tlrtGT7FAhsO6Jglh4KLRR4WNiVeJWtq7b4g4znT3rjzVXRgGsBH6bvND+JP0MpIk FD3g== X-Gm-Message-State: AOJu0YzUuHE5Auezo4feogUIFlKKqRAUsh0sPvfaHb8YurrP+CBJgAVH WsIUlP25q+CxOjuQzd+DqHs= X-Google-Smtp-Source: AGHT+IHD8FhvaBavsFW1owvzNtaVcgzQZwpKsi3fOHEFxFljS9IxvDlviiFOn1pYk31ZGH6V97T+BQ== X-Received: by 2002:a17:906:1097:b0:9a9:e393:8bcd with SMTP id u23-20020a170906109700b009a9e3938bcdmr9775679eju.5.1696273053905; Mon, 02 Oct 2023 11:57:33 -0700 (PDT) Sender: Ingo Molnar Date: Mon, 2 Oct 2023 20:57:31 +0200 From: Ingo Molnar To: Kir Kolyshkin Cc: linux-kernel@vger.kernel.org, libc-alpha@sourceware.org, musl@lists.openwall.com, linux-api@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Joel Fernandes , Christian Brauner , Linus Torvalds Message-ID: 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> Subject: [musl] Re: [PATCH] sched/headers: move struct sched_param out of uapi * Kir Kolyshkin 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 > #include > > 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 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