From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: Elevated i_writecount doesn't guarantee ->release to be called
Date: Thu, 29 Jan 2015 17:35:33 +0000
Message-ID: <20150129173532.GF29656@ZenIV.linux.org.uk>
References: <54c95874.1pbbCloLAl3wWsPR%akpm@linux-foundation.org>
 <20150128224534.GB29656@ZenIV.linux.org.uk>
 <20150129124630.GB11635@quack.suse.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: akpm@linux-foundation.org, fabf@skynet.be,
	mm-commits@vger.kernel.org, linux-fsdevel@vger.kernel.org
To: Jan Kara <jack@suse.cz>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:50757 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754248AbbA2Rfg (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Thu, 29 Jan 2015 12:35:36 -0500
Content-Disposition: inline
In-Reply-To: <20150129124630.GB11635@quack.suse.cz>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Thu, Jan 29, 2015 at 01:46:30PM +0100, Jan Kara wrote:
>   Thanks for pointing this out. You made me at look where exactly is
> get_write_access() called and there are even places where we call it
> without having file descriptor at all (e.g.  truncate path). So ext3, ext4,
> udf, and gfs2 are racy. If we race, results aren't that bad (we just keep
> preallocated blocks in the inode) but still it would be nice to fix.
> 
> Obviously we could maintain a private writecount in ->open() method but it
> would seem a bit sad to do that for this mostly theoretical issue. Maybe we
> just verify whether preallocation is truncated when evicting inode from
> memory and if not, do it there. It's not perfect but even with current racy
> solution noone noticed in practice.

The trouble with doing that on inode eviction is that we might have done
r/o remount by then, so any metadata writes are unexpected at that point...