From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sunil Mushran Date: Wed, 26 Jun 2013 20:34:19 -0700 Subject: [Ocfs2-devel] [PATCH] ocfs2: llseek requires to ocfs2 inode lock for the file in SEEK_END In-Reply-To: <51CB9A81.2000007@huawei.com> References: <51C2BC1F.2010106@huawei.com> <20130626141803.a67cb8e4ca38a9ef2967a448@linux-foundation.org> <51CB9338.3050408@huawei.com> <20130626182536.c319334d.akpm@linux-foundation.org> <51CB9A81.2000007@huawei.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ocfs2-devel@oss.oracle.com 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 wrote: > On 2013/6/27 9:25, Andrew Morton wrote: > > > On Thu, 27 Jun 2013 09:19:52 +0800 shencanquan > 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