Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967466AbdIZDBo (ORCPT ); Mon, 25 Sep 2017 23:01:44 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:53996 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933842AbdIZDBn (ORCPT ); Mon, 25 Sep 2017 23:01:43 -0400 Date: Tue, 26 Sep 2017 04:01:39 +0100 From: Al Viro To: Linus Torvalds Cc: Kyle Huey , open list , "Robert O'Callahan" Subject: Re: [git pull] vfs.git regression fix Re: Regression related to ipc shmctl compat Message-ID: <20170926030138.GA32076@ZenIV.linux.org.uk> References: <20170926010036.GX32076@ZenIV.linux.org.uk> <20170926014656.GY32076@ZenIV.linux.org.uk> <20170926020047.GZ32076@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1945 Lines: 37 On Mon, Sep 25, 2017 at 07:07:01PM -0700, Linus Torvalds wrote: > On Mon, Sep 25, 2017 at 7:03 PM, Linus Torvalds > wrote: > > > > I agree. It might be better to just remove the address space logic, > > because afaik it never worked for them. > > .. and sadly, we should probably disable the locking ones by default > too, because while they *work*, sparse only handles static cases, and > we have way too many dynamically conditional cases that are outside > the scope of what sparse does. > > It would probably be good to disable things that are fundamentally > hard to fix, and aim for a clean sparse build, and maybe people would > start using it at least for user pointer checking where it really does > work. > > Of course, even there it depends on pointers _statically_ being user > pointers, but happily we do largely follow that rule. We've had a few > nasty cases where we have a pointer that is conditionally user or > kernel pointer, but they are thankfully pretty rare. BTW, while we are at it - I'd been rebasing POLL... annotations through the last three cycles and it doesn't take much work (usually 20-30 minutes). Mind if I throw vfs.git#misc.poll into -next and send it your way next cycle? Right now it's pretty much in zero-noise state - a few of the remaining warnings are spurious, but most of what remains consists of real bugs. One class is ->poll() instance returning -E... in some case; callers expect a bitmap instead. Another, and that's much nastier, is EPOLL... mess. We have EPOLL... definitions identical for all architectures. Unfortunately, we rely upon them being equal to corresponding POLL... (when both are defined) and some of those are different on different architectures (sparc is the strangest one in that respect). Both are exposed to userland, so we can't just go and change them at will. Not sure what can be done with that, syscall ABI being what it is...