Re: Elevated i_writecount doesn't guarantee ->release to be called

[Fabian Frederick <fabf@skynet.be>]

> On 29 January 2015 at 18:35 Al Viro <viro@ZenIV.linux.org.uk> wrote:
>
>
> 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...

What would you suggest then ? I could try to do the right update on AFFS
then apply it on ext3,4,udf,gfs2 as well. Maybe some generic_release
would be useful to avoid repeating the same logic around private
preallocation management ?

Regards,
Fabian
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html