All of lore.kernel.org
 help / color / mirror / Atom feed
From: shencanquan <shencanquan@huawei.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH] ocfs2: llseek requires to ocfs2 inode lock for the file in SEEK_END
Date: Thu, 27 Jun 2013 09:50:57 +0800	[thread overview]
Message-ID: <51CB9A81.2000007@huawei.com> (raw)
In-Reply-To: <20130626182536.c319334d.akpm@linux-foundation.org>

On 2013/6/27 9:25, Andrew Morton wrote:

> On Thu, 27 Jun 2013 09:19:52 +0800 shencanquan <shencanquan@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.

  reply	other threads:[~2013-06-27  1:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-20  8:23 [Ocfs2-devel] [PATCH] ocfs2: llseek requires to ocfs2 inode lock for the file in SEEK_END shencanquan
2013-06-26 21:18 ` Andrew Morton
2013-06-27  1:19   ` shencanquan
2013-06-27  1:25     ` Andrew Morton
2013-06-27  1:50       ` shencanquan [this message]
2013-06-27  3:34         ` Sunil Mushran
2013-06-27  8:56           ` Jensen
2013-06-27 22:08           ` Andrew Morton
2013-06-27 22:59             ` Sunil Mushran
2013-06-28  9:11               ` Jeff Liu
2013-06-29 13:28                 ` Joel Becker
2013-06-29 13:37 ` Joel Becker
2013-07-01  1:38   ` Jensen
2013-07-02 19:58     ` Mark Fasheh
2013-07-02 21:19       ` Joel Becker

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=51CB9A81.2000007@huawei.com \
    --to=shencanquan@huawei.com \
    --cc=ocfs2-devel@oss.oracle.com \
    /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.