From: Matthew Wilcox <matthew@wil.cx>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andi Kleen <andi@firstfloor.org>,
Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [RESEND] [PATCH] VFS: make file->f_pos access atomic on 32bit arch
Date: Tue, 7 Oct 2008 12:00:21 -0600 [thread overview]
Message-ID: <20081007180020.GI25780@parisc-linux.org> (raw)
In-Reply-To: <200810080327.44530.nickpiggin@yahoo.com.au>
On Wed, Oct 08, 2008 at 03:27:44AM +1100, Nick Piggin wrote:
> So.. is everyone agreed that corrupting f_pos is a bad thing? (serious
> question) If so, then we should get something like this merged sooner
> rather than later.
I'm not convinced it's a bad thing. f_pos is going to get 'corrupted'
(ie not pointing where you think it's going to point) sooner or later
anyway if you have two threads accessing the same file without locking.
The fact that it can point to an offset that was accessed by neither
thread A nor thread B seems irrelevant to me.
Separately, if we do decide something along these lines is a good idea,
then file_pos_update() needs to be better. The current patch has:
if (offset>=0 && offset<=inode->i_sb->s_maxbytes) {
/* Special lock needed here? */
- if (offset != file->f_pos) {
- file->f_pos = offset;
+ if (file_pos_update(file, offset))
file->f_version = 0;
- }
retval = offset;
}
It seems to me that the set of f_version to 0 should be atomic with
the changing of f_pos. So something like this might work better:
+static inline void file_pos_update(struct file *file, loff_t offset, int v)
+{
+#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
+ write_seqlock(&file->f_pos_seqlock);
+ if (offset != file->f_pos) {
+ file->f_pos = offset;
+ if (v)
+ file->f_version = 0;
+ }
+ write_sequnlock(&file->f_pos_seqlock);
+#elif BITS_PER_LONG == 32 && defined(CONFIG_PREEMPT)
+ preempt_disable();
+ if (offset != file->f_pos) {
+ file->f_pos = offset;
+ if (v)
+ file->f_version = 0;
+ }
+ preempt_enable();
+#else
+ if (offset != file->f_pos) {
+ file->f_pos = offset;
+ if (v)
+ file->f_version = 0;
+ }
+#endif
+}
Since 'v' will be known at compile time, the tests optimise away to nothing.
I also think the patch would be more favourably received if it were
structured as:
+#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
+static inline loff_t file_pos_read(struct file *file)
+{
...
+}
+
+static inline void file_pos_write(struct file *file, loff_t pos)
+{
...
+}
+
...
+#elif BITS_PER_LONG == 32 && defined(CONFIG_PREEMPT)
...
+#else
...
+#endif
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
prev parent reply other threads:[~2008-10-07 18:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-07 5:07 [RESEND] [PATCH] VFS: make file->f_pos access atomic on 32bit arch Hisashi Hifumi
2008-10-07 6:43 ` Andi Kleen
2008-10-07 10:11 ` Hisashi Hifumi
2008-10-07 10:29 ` Andi Kleen
2008-10-07 16:27 ` Nick Piggin
2008-10-07 17:50 ` Andrew Morton
2008-10-07 18:59 ` Peter Zijlstra
2008-10-08 2:35 ` Nick Piggin
2008-10-08 2:52 ` Matthew Wilcox
2008-10-09 12:23 ` Pavel Machek
2008-10-09 12:49 ` Valdis.Kletnieks
2008-10-09 13:01 ` Matthew Wilcox
2008-10-09 13:38 ` Miklos Szeredi
2008-10-09 14:58 ` Linus Torvalds
2008-10-09 17:29 ` Jeremy Fitzhardinge
2008-10-08 4:48 ` Hisashi Hifumi
2008-10-08 5:10 ` Nick Piggin
2008-10-08 5:16 ` Matthew Wilcox
2008-10-08 6:28 ` Andrew Morton
2008-10-08 6:51 ` Peter Zijlstra
2008-10-08 8:32 ` Eric Dumazet
2008-10-08 8:48 ` Nick Piggin
2008-10-08 9:17 ` Peter Zijlstra
2008-10-09 21:51 ` dcg
2008-10-10 2:25 ` Nick Piggin
2008-10-09 12:16 ` Pavel Machek
2008-10-08 0:40 ` Nick Piggin
2008-10-07 18:00 ` Matthew Wilcox [this message]
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=20081007180020.GI25780@parisc-linux.org \
--to=matthew@wil.cx \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=hifumi.hisashi@oss.ntt.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox