From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [PATCH 1/1] futex: remove duplicated code Date: Thu, 18 May 2017 18:30:10 +0100 Message-ID: <20170518173010.GK21359@arm.com> References: <20170515130742.18357-1-jslaby@suse.cz> <20170515131644.GA3605@arm.com> <14580dfc-9721-38ab-a1e0-6b4aba13b406@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from foss.arm.com ([217.140.101.70]:34896 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754853AbdERRaL (ORCPT ); Thu, 18 May 2017 13:30:11 -0400 Content-Disposition: inline In-Reply-To: <14580dfc-9721-38ab-a1e0-6b4aba13b406@suse.cz> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Jiri Slaby Cc: tglx@linutronix.de, linux-kernel@vger.kernel.org, Richard Henderson , Ivan Kokshaysky , Matt Turner , Vineet Gupta , Catalin Marinas , Richard Kuo , Tony Luck , Fenghua Yu , Michal Simek , Ralf Baechle , Jonas Bonn , Stefan Kristiansson , Stafford Horne , "James E.J. Bottomley" , Helge Deller , Benjamin Herrenschmidt , Paul Mackerras , Martin Schwidefsky On Wed, May 17, 2017 at 10:01:29AM +0200, Jiri Slaby wrote: > On 05/15/2017, 03:16 PM, Will Deacon wrote: > > Whilst I think this is a good idea, the code in question actually results > > in undefined behaviour per the C spec and is reported by UBSAN. > > Hi, yes, I know -- this patch was the 1st from the series of 3 which I > sent a long time ago to fix that up too. But I remember your patch, so I > sent only this one this time. > > > See my > > patch fixing arm64 here (which I'd forgotten about): > > > > https://www.spinics.net/lists/linux-arch/msg38564.html > > > > But, as stated in the thread above, I think we should go a step further > > and remove FUTEX_OP_{OR,ANDN,XOR,OPARG_SHIFT} altogether. They don't > > appear to be used by userspace, and this whole thing is a total mess. > > > > Any thoughts? > > Ok, I am all for that. I think the only question is who is going to do > the work and submit it :)? Do I understand correctly to eliminate all > these functions and the path into the kernel? But won't this break API > -- are there really no users of this interface? That's the million-dollar question, really. I don't know of any code using it, and I couldn't find any when I looked (also nothing reported by Debian Codesearch afaict), but I was hoping linux-arch might have some thoughts on this too. For now, I'll queue my arm64 patch before I forget about it again! Will From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com ([217.140.101.70]:34896 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754853AbdERRaL (ORCPT ); Thu, 18 May 2017 13:30:11 -0400 Date: Thu, 18 May 2017 18:30:10 +0100 From: Will Deacon Subject: Re: [PATCH 1/1] futex: remove duplicated code Message-ID: <20170518173010.GK21359@arm.com> References: <20170515130742.18357-1-jslaby@suse.cz> <20170515131644.GA3605@arm.com> <14580dfc-9721-38ab-a1e0-6b4aba13b406@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14580dfc-9721-38ab-a1e0-6b4aba13b406@suse.cz> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Jiri Slaby Cc: tglx@linutronix.de, linux-kernel@vger.kernel.org, Richard Henderson , Ivan Kokshaysky , Matt Turner , Vineet Gupta , Catalin Marinas , Richard Kuo , Tony Luck , Fenghua Yu , Michal Simek , Ralf Baechle , Jonas Bonn , Stefan Kristiansson , Stafford Horne , "James E.J. Bottomley" , Helge Deller , Benjamin Herrenschmidt , Paul Mackerras , Martin Schwidefsky , Yoshinori Sato , Rich Felker , "David S. Miller" , Ingo Molnar , "H. Peter Anvin" , Chris Zankel , Max Filippov , Arnd Bergmann , x86@kernel.org, linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org, linux-mips@linux-mips.org, openrisc@lists.librecores.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-arch@vger.kernel.org Message-ID: <20170518173010.Zky7HLwqsvtMBjq8oghpBhdRaDIW3bgI38X45VTnhhU@z> On Wed, May 17, 2017 at 10:01:29AM +0200, Jiri Slaby wrote: > On 05/15/2017, 03:16 PM, Will Deacon wrote: > > Whilst I think this is a good idea, the code in question actually results > > in undefined behaviour per the C spec and is reported by UBSAN. > > Hi, yes, I know -- this patch was the 1st from the series of 3 which I > sent a long time ago to fix that up too. But I remember your patch, so I > sent only this one this time. > > > See my > > patch fixing arm64 here (which I'd forgotten about): > > > > https://www.spinics.net/lists/linux-arch/msg38564.html > > > > But, as stated in the thread above, I think we should go a step further > > and remove FUTEX_OP_{OR,ANDN,XOR,OPARG_SHIFT} altogether. They don't > > appear to be used by userspace, and this whole thing is a total mess. > > > > Any thoughts? > > Ok, I am all for that. I think the only question is who is going to do > the work and submit it :)? Do I understand correctly to eliminate all > these functions and the path into the kernel? But won't this break API > -- are there really no users of this interface? That's the million-dollar question, really. I don't know of any code using it, and I couldn't find any when I looked (also nothing reported by Debian Codesearch afaict), but I was hoping linux-arch might have some thoughts on this too. For now, I'll queue my arm64 patch before I forget about it again! Will