All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Christoph Hellwig <hch@infradead.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Stefan Richter <stefanr@s5r6.in-berlin.de>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	John Kacur <jkacur@redhat.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Al Viro <viro@zeniv.linux.org.uk>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 6/6] procfs: Kill the bkl in ioctl
Date: Tue, 13 Apr 2010 14:03:32 -0400	[thread overview]
Message-ID: <20100413180332.GB21302@infradead.org> (raw)
In-Reply-To: <201004121934.18307.arnd@arndb.de>

On Mon, Apr 12, 2010 at 07:34:17PM +0200, Arnd Bergmann wrote:
> >  - make sure every file operation either has a ->llseek instead or
> >    calls nonseekable_open from ->open
> 
> I still think it would be better to always set llseek if we do that,
> even if nonseekable_open is already there. I can come up with scripts
> that check that case, but checking that the open function always
> calls nonseekable_open when it returns success is beyond my grep
> skills ;-)

Yes, it's not quite easily greppable.  Making no seek allowed the
implicit default will fortunately allow us to get rid of that oddness.

> >  - 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.
> 
> This part is really hard. While in many cases, the driver maintainer
> might know what user space is potentially opening some character
> device, it's really hard to tell for outsiders whether the behaviour
> should be no_llseek (then the default) or noop_llseek to work around
> broken user space.

That's why it's last on the list.

> I think the rule set for the conversion needs to be one that can
> be done purely based on the code. How about this:
> 
> For each file operation {
> 	if (uses f_pos) {
> 		if (same module uses BKL)
> 			-> default_llseek
> 		else
> 			-> generic_file_llseek
> 	} else {
> 		if (driver maintained)
> 			-> no_llseek (with maintainer ACK)
> 		else
> 			-> noop_llseek
> 	}
> }
> 
> Once that is done, we can turn the default into nonseekable
> behavior and start removing instances of explicit no_llseek
> and nonseekable_open.

That plan sounds good to me.

> Should we also rename default_llseek to deprecated_llseek in the
> process, to go along with the approach for ioctl?

I wouldn't bother.  If you can actually work on your plan default_llseek
should be gone soon enough.


  parent reply	other threads:[~2010-04-13 18:03 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-30  6:20 [PATCH 0/6] Kill the bkl in procfs Frederic Weisbecker
2010-03-30  6:20 ` [PATCH 1/6] procfs: Kill BKL in llseek on proc base Frederic Weisbecker
2010-03-30  6:40   ` Alexey Dobriyan
2010-03-30  6:50     ` Frederic Weisbecker
2010-03-30  6:20 ` [PATCH 2/6] procfs: Use generic_file_llseek in /proc/kcore Frederic Weisbecker
2010-03-30 10:28   ` Arnd Bergmann
2010-03-30  6:20 ` [PATCH 3/6] procfs: Use generic_file_llseek in /proc/kmsg Frederic Weisbecker
2010-03-30 10:38   ` Arnd Bergmann
2010-03-30  6:20 ` [PATCH 4/6] procfs: Use generic_file_llseek in /proc/vmcore Frederic Weisbecker
2010-03-30 10:38   ` Arnd Bergmann
2010-03-30  6:20 ` [PATCH 5/6] procfs: Push down the bkl from ioctl Frederic Weisbecker
2010-03-30  6:31   ` Alexey Dobriyan
2010-03-30  7:02     ` Frederic Weisbecker
2010-04-09 14:45     ` [PATCH v2] " Frederic Weisbecker
2010-04-10 13:25       ` [PATCH v3] " Frederic Weisbecker
2010-05-17  1:23         ` [PATCH v4] " Frederic Weisbecker
2010-03-30 10:37   ` [PATCH 5/6] " Arnd Bergmann
2010-03-30 18:27     ` Frederic Weisbecker
2010-03-30 18:54       ` Arnd Bergmann
2010-03-30 19:21         ` Frederic Weisbecker
2010-03-30  6:20 ` [PATCH 6/6] procfs: Kill the bkl in ioctl Frederic Weisbecker
2010-03-30  6:38   ` Alexey Dobriyan
2010-03-30  7:07     ` Frederic Weisbecker
2010-03-30 10:33       ` Arnd Bergmann
2010-03-31 17:22         ` Frederic Weisbecker
2010-03-31 20:21           ` Arnd Bergmann
2010-03-31 21:04             ` Arnd Bergmann
2010-03-31 21:55               ` Alan Cox
2010-04-01  9:07                 ` Arnd Bergmann
2010-03-31 21:56               ` Frederic Weisbecker
2010-04-01 11:37                 ` Arnd Bergmann
2010-04-01 10:22               ` John Kacur
2010-03-31 21:41             ` Frederic Weisbecker
2010-04-01 12:42               ` Arnd Bergmann
2010-04-03 17:53                 ` Stefan Richter
2010-04-10 16:09                 ` Frederic Weisbecker
2010-04-12 15:05                   ` Arnd Bergmann
2010-04-10 16:14                 ` Frederic Weisbecker
2010-04-10 16:24                 ` Frederic Weisbecker
2010-04-01 11:39           ` Stefan Richter
2010-04-01 12:45             ` Arnd Bergmann
2010-04-10 15:28               ` Frederic Weisbecker
2010-04-11 13:03                 ` Christoph Hellwig
2010-04-12 17:34                   ` Arnd Bergmann
2010-04-12 21:53                     ` Frederic Weisbecker
2010-04-13  9:26                       ` Arnd Bergmann
2010-04-13 20:10                         ` Frederic Weisbecker
2010-04-13 18:03                     ` Christoph Hellwig [this message]
2010-04-10 13:27 ` [PATCH 0/6] Kill the bkl in procfs Frederic Weisbecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100413180332.GB21302@infradead.org \
    --to=hch@infradead.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=fweisbec@gmail.com \
    --cc=jkacur@redhat.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.