From: Miklos Szeredi <mszeredi@suse.cz>
To: Amerigo Wang <amwang@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, heiko.carstens@de.ibm.com,
linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk
Subject: Re: [Patch] pipe: use file_update_time() when hold i_mutex
Date: Mon, 03 Aug 2009 18:58:07 +0200 [thread overview]
Message-ID: <1249318687.29890.28.camel@tucsk> (raw)
In-Reply-To: <4A66DA2E.90601@redhat.com>
On Wed, 2009-07-22 at 17:21 +0800, Amerigo Wang wrote:
> Miklos Szeredi wrote:
> > On Tue, 2009-07-21 at 18:07 +0800, Amerigo Wang wrote:
> >
> >> Andrew Morton wrote:
> >>
> >>> On Mon, 6 Jul 2009 01:35:30 -0400
> >>> Amerigo Wang <amwang@redhat.com> wrote:
> >>>
> >>>
> >>>
> >>>> file_update_time() should be called with i_mutex held,
> >>>> move it before mutex_unlock().
> >>>>
> >>>>
> >>>>
> >>> Why do you believe that file_update_time() needs i_mutex?
> >>>
> >>>
> >> file_update_time() modifies inode, no? :)
> >>
> >
> > So does touch_atime(), yet neither needs i_mutex.
> >
> Yes?
>
> Then how the inode is protected when file_update_time() modifies
> it?
Protected against what?
For example the inode isn't protected against concurrent access by
stat(2), since that doesn't take i_mutex.
And indeed it looks like there are races there, since set/get operations
are not atomic on the timestamp, so stat could return a garbled value if
it races with file_update_time() or touch_atime().
Possibly worth fixing, but I'm not sure how to do that without affecting
the scalability of stat and friends and without adding too much
complexity.
Thanks,
Miklos
prev parent reply other threads:[~2009-08-03 16:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-06 5:35 [Patch] pipe: use file_update_time() when hold i_mutex Amerigo Wang
2009-07-20 21:11 ` Andrew Morton
2009-07-21 10:07 ` Amerigo Wang
2009-07-21 11:09 ` Miklos Szeredi
2009-07-22 9:21 ` Amerigo Wang
2009-08-03 16:58 ` Miklos Szeredi [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=1249318687.29890.28.camel@tucsk \
--to=mszeredi@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=amwang@redhat.com \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox