Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761921AbYF3NJc (ORCPT ); Mon, 30 Jun 2008 09:09:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755400AbYF3NJM (ORCPT ); Mon, 30 Jun 2008 09:09:12 -0400 Received: from vsmtp03.dti.ne.jp ([202.216.231.138]:64854 "EHLO vsmtp03.dti.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756940AbYF3NJL (ORCPT ); Mon, 30 Jun 2008 09:09:11 -0400 From: hooanon05@yahoo.co.jp Subject: Re: [PATCH] fsstack: fsstack_copy_inode_size locking To: Hugh Dickins Cc: Erez Zadok , Andrew Morton , mhalcrow@us.ibm.com, hch@infradead.org, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org In-Reply-To: References: <8725.1214800317@jrobl> Date: Mon, 30 Jun 2008 22:08:12 +0900 Message-ID: <7439.1214831292@jrobl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 907 Lines: 26 Hugh Dickins: > It certainly shouldn't be. The problem would have come from two > racing i_size_write(dst)s, one of the unlocked increments getting > lost, leaving seqcount odd, so the next i_size_read(dst) would > spin forever waiting for it to go even. I see. The unlocked increment can cause the next i_size_read() hang. > I'm not sure what you mean by that. i_size_read() doesn't fail, > but it may loop; and if the seqcount has got out of step from > concurrent unlocked i_size_write()s, then it'll spin forever. What I meant by "fail" was "loop" actually. And I understand that you didn't writing directly (bypassing unionfs) too. Junjiro Okajima -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/