[Ocfs2-devel] [PATCH] ocfs2: llseek requires to ocfs2 inode lock for the file in SEEK_END

[Sunil Mushran]

AFAIR, this behavior has been there since day 1 and changing it will impact
performance negatively. I would recommend against making this change for
one app.


On Wed, Jun 26, 2013 at 6:50 PM, shencanquan <shencanquan at huawei.com> wrote:

> On 2013/6/27 9:25, Andrew Morton wrote:
>
> > On Thu, 27 Jun 2013 09:19:52 +0800 shencanquan <shencanquan at huawei.com>
> wrote:
> >
> >> On 2013/6/27 5:18, Andrew Morton wrote:
> >>
> >>>
> >>> My guess is that there is some other code path which is modifying
> >>> inode->i_size without holding inode->i_mutex, and while holding
> >>> ocfs2_inode_lock().  If so, that code is surely wrong - it should hold
> >>> i_mutex while modifying i_size.
> >>
> >>
> >> inode->i_mutex lock only protect the inode size on the same machine.
> >
> > ah ;)
> >
> >>> And all this is only really applicable to 32-bit CPUs, which you
> >>> probably aren't using.
> >>
> >> I don't understand this.
> >
> > The i_size_read/i_size_write infrastructure is designed to efficiently
> > handle the situation where a 32-bit machine reads a 64-bit number which
> > might be undergoing modification on another CPU.  We don't want the
> > reading CPU to see an invalid number when the writing CPU is in the
> > middle of modifying the two 32-bit words.
> >
> >
> >
>
> ok. thanks.
>
>
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/ocfs2-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/ocfs2-devel/attachments/20130626/3f723c36/attachment.html