Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751936Ab0DKNDs (ORCPT ); Sun, 11 Apr 2010 09:03:48 -0400 Received: from bombadil.infradead.org ([18.85.46.34]:39238 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751861Ab0DKNDq (ORCPT ); Sun, 11 Apr 2010 09:03:46 -0400 Date: Sun, 11 Apr 2010 09:03:41 -0400 From: Christoph Hellwig To: Frederic Weisbecker Cc: Arnd Bergmann , Stefan Richter , Alexey Dobriyan , LKML , Thomas Gleixner , Andrew Morton , John Kacur , KAMEZAWA Hiroyuki , Al Viro , Ingo Molnar Subject: Re: [PATCH 6/6] procfs: Kill the bkl in ioctl Message-ID: <20100411130341.GA6353@infradead.org> References: <1269930015-863-1-git-send-regression-fweisbec@gmail.com> <20100331172208.GB5163@nowhere> <4BB485ED.80806@s5r6.in-berlin.de> <201004011445.32657.arnd@arndb.de> <20100410152813.GE5204@nowhere> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100410152813.GE5204@nowhere> User-Agent: Mutt/1.5.19 (2009-01-05) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2181 Lines: 43 On Sat, Apr 10, 2010 at 05:28:16PM +0200, Frederic Weisbecker wrote: > So you mean we should attribute explicit default_llseek to the evil > places instead of explicit generic_file_llseek in the safe ones? > That's not a bad idea as it would result in much less changes. > > The problem happens the day you switch to generic_file_llseek() as the > new default llseek(), how do you prove that all remaining fops > that don't implement .llseek don't use the bkl? There will be > hundreds of them and saying "we've looked all of them and they don't > need it" will be a scary justification. > > On the opposite, attributing explicit generic_file_llseek or > non_seekable_open on the safe places and default_llseek on > the dozens of others doubtful places is easier to get a > safe conclusion. > > But yeah we should try, at least attributing explicit > default_llseek won't harm, quite the opposite. Note that an lssek that actually does something is the wrong default, even if we have it that way currently. If the default is changed it should be changed to give the semantics that nonseekable_open() gives us. Given that you guys are so motivated to do something in this area it might be a good idea to do this in a few simple steps: - make sure every file operation either has a ->llseek instead or calls nonseekable_open from ->open - remove nonseekable_open and all calls to it - switch all users of no_llseek to not set a ->llsek after auditing that there's no corner case where we want to allow pread/pwrite but not lseek, which is rather unlikely - walk through the instances now using default_llseek and chose a better implementation for this particular instance. Often this will be just removing the the lssek method as not allowing seeks is the right thing to do for character drivers, even if it is a behaviour change from the current version which usually is the result of sloppy coding. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/