linux-kernel - Re: Issue with lazy umount and closing file descriptor in between

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKYAXd_kwtRjWxm_UcxZvNgLwBBc-M9YMc7DZx1Kv2vsd1SJJA@mail.gmail.com>
Date:	Mon, 12 Sep 2011 09:45:23 +0900
From:	NamJae Jeon <linkinjeon@...il.com>
To:	Amit Sahrawat <amit.sahrawat83@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	Bryan Donlan <bdonlan@...il.com>
Subject: Re: Issue with lazy umount and closing file descriptor in between

2011/9/12 Bryan Donlan <bdonlan@...il.com>:
> On Wed, Sep 7, 2011 at 12:37, Amit Sahrawat <amit.sahrawat83@...il.com> wrote:
>> I know that lazy umount was designed keeping in mind that the
>> mountpoint is not accesible to all future I/O but for the ongoing I/O
>> it will continute to work. It is only after the I/O is finished that
>> the umount will actually occur. But this can be tricky at times
>> considering there are situations where the operation will continue to
>> be executed than what is expected duration, and you cannot unplug the
>> device during that period because there are chances of filesystem
>> corruption on doing so.
>> Is there anything which could be done in this context? because simply
>> reading the fd-table and closing fd's will not serve the purpose and
>> there is every chance of a OOPs occuring due to this closing.
>> Signalling from this point to the all the process's with open fd's on
>> that mountpoint to close fd i.e., handling needs to be done from the
>> user space applications...? Does this make sense
>>
>> Please through some insight into this. I am not looking for exact
>> solution it is just mere opinion's on this that can add to this.
>
> Essentially what you want here is a 'forced unmount' option.
>
> It's difficult to do this directly in the existing VFS model; you'd
> need to essentially change the operations structure for all open
> files/inodes for that filesystem in a race-free manner, _and_ wait for
> any outstanding operations to complete. The VFS isn't really designed
> to support something like this. What you could try doing, however, is
> creating a wrapper filesystem - one that redirects all requests to an
> underlying filesystem, but supports an operation to:
>
> 1) Make all future requests fail with -EIO
> 2) Invalidate any existing VMA mappings
> 3) Wait for all outstanding requests to complete
> 4) Unmount (ie, unreference) the underlying filesystem
>
> This will result in some overhead, of course, but would seem to be the
> safest route.
>

I have a idea to resolve this problem. plz try to do like this.

1. first, fd is set to -1 or .. in fdtable about opened file. If then,
when user app try next write, BAD desctriptor error will be faced.(it
can not cause BAD descrpitor, plz check condition of BAD descriptor).
2. second, plz flush dirty page and request in i/o scheduler.
3. third , try to close fd after previous I/O is finished like above trying.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/