From: Jamie Lokier <jamie@shareable.org>
To: Oliver Neukum <oliver@neukum.org>
Cc: "Alan Cox" <alan@lxorguk.ukuu.org.uk>,
"Jan Blunck" <jblunck@suse.de>,
linux-fsdevel@vger.kernel.org,
"Linux-Kernel Mailinglist" <linux-kernel@vger.kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
jkacur@redhat.com, "Thomas Gleixner" <tglx@linutronix.de>,
"Arnd Bergmann" <arnd@arndb.de>,
"Christoph Hellwig" <hch@infradead.org>,
"Frédéric Weisbecker" <fweisbec@gmail.com>,
"Alexander Viro" <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 1/2] BKL: Remove BKL from default_llseek()
Date: Wed, 18 Nov 2009 17:50:03 +0000 [thread overview]
Message-ID: <20091118175003.GF28723@shareable.org> (raw)
In-Reply-To: <200911181835.55007.oliver@neukum.org>
Oliver Neukum wrote:
> Am Mittwoch, 18. November 2009 18:27:30 schrieb Jamie Lokier:
> > > No. Your logic is flawed
> > >
> > > The BKL is protected something here - it protects the change of offset
> > > with respect to other BKL users within drivers. The question is what if
> > > anything in any other driver code depends upon the BKL and uses it to
> > > protect f_pos. Probably very little if anything but a grep for f_pos
> > > through the drivers might not be a bad idea before assuming this. Very
> > > few touch f_pos except in their own llseek method.
> >
> > Of course, drivers shouldn't be using f_pos outside their llseek
> > method, as they should all behave the same with pread/pwrite as with
> > llseek+read/write.
>
> Might not a driver update f_pos after read/write?
It could indirectly, through *ppos.
There should be no direct accesses to f_pos outseek llseek. If there
are still, those might indicate driver bugs. (I'm not 100% sure about
this - hence asking).
Drivers used to update f_pos indirectly through *ppos, and for this,
Alan's observation about BKL protecting the value from changing does apply.
But nowadays, even that doesn't happen. sys_read() and sys_write()
make a copy of f_pos using file_pos_read(), so drivers cannot see the
value change during the call - except for their own change.
I find myself wondering why the VFS isn't responsible for the position
update instead of the driver... Would it be a valid cleanup to move
it from the driver to VFS?
-- Jamie
next prev parent reply other threads:[~2009-11-18 17:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-18 16:07 [PATCH 1/2] BKL: Remove BKL from default_llseek() Jan Blunck
2009-11-18 16:07 ` [PATCH 2/2] BKL: Update documentation on llseek( \b) Jan Blunck
2009-11-18 16:07 ` Jan Blunck
2009-11-18 17:15 ` [PATCH 1/2] BKL: Remove BKL from default_llseek() Alan Cox
2009-11-18 17:27 ` Jamie Lokier
2009-11-18 17:33 ` Arnd Bergmann
2009-11-18 18:00 ` Alan Cox
2009-11-18 18:06 ` Arnd Bergmann
2009-11-18 18:14 ` Alan Cox
2009-11-18 19:17 ` Arnd Bergmann
2009-11-18 17:35 ` Oliver Neukum
2009-11-18 17:50 ` Jamie Lokier [this message]
2009-11-18 18:16 ` Alan Cox
2009-11-19 2:40 ` Jamie Lokier
2009-11-19 10:13 ` Alan Cox
2009-11-18 17:55 ` Alan Cox
2009-11-18 17:55 ` Jan Blunck
2009-11-18 17:53 ` Jan Blunck
2009-11-18 18:17 ` Alan Cox
2009-11-18 20:02 ` Jan Blunck
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=20091118175003.GF28723@shareable.org \
--to=jamie@shareable.org \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arnd@arndb.de \
--cc=fweisbec@gmail.com \
--cc=hch@infradead.org \
--cc=jblunck@suse.de \
--cc=jkacur@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oliver@neukum.org \
--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.