linux-kernel - Re: [RFC PATCH] fs: file freeze support

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20150120222222.GF16552@dastard>
Date:	Wed, 21 Jan 2015 09:22:22 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Jan Kara <jack@...e.cz>
Cc:	Namjae Jeon <namjae.jeon@...sung.com>,
	'Theodore Ts'o' <tytso@....edu>,
	'Alexander Viro' <viro@...iv.linux.org.uk>,
	'Brian Foster' <bfoster@...hat.com>,
	'Dmitry Monakhov' <dmonakhov@...nvz.org>,
	'Lukáš Czerner' <lczerner@...hat.com>,
	linux-fsdevel@...r.kernel.org,
	'Ashish Sangwan' <a.sangwan@...sung.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] fs: file freeze support

On Tue, Jan 20, 2015 at 12:21:37PM +0100, Jan Kara wrote:
> On Mon 19-01-15 22:07:01, Namjae Jeon wrote:
> > > > When this state is set, any process which tries to modify the file's address
> > > > space, either by pagefault mmap writes or using write(2), will block until
> > > > the this state is cleared. I_WRITE_FREEZED is set by calling FS_IOC_FWFREEZE
> > > > ioctl and clear by FS_IOC_FWTHAW ioctl.
....
> > I checked the routines where checks for I_FROZEN would be required.
> > Most of them are Ok but do_unlinkat() confuses me a little.
> > vfs_unlink is called under parent inode's i_mutex, so we cannot sleep
> > keeping parent's i_mutex held.
> > i.e while freezing file, all file in directory are blocked by parent
> > i_mutex. Is it ok to release parnets->mutex before checking for I_FROZEN
> > or there is some idea?
>   So I believe Dave thought that you'd just reuse places we currently use
> to call sb_start_write() / mnt_want_write(). You'd probably have to come up
> with a function like path_want_write() (takes struct path as an argument)
> and which will call mnt_want_write(), sb_start_write(), and do appropriate
> inode freeze handling. Then you replace all calls to mnt_want_write() with
> calls to path_want_write()... Possibly you can also provide a trivial
> wrapper for path_want_write() which takes struct file instead.

Yes, that's pretty much what I as thinking - a single function
that does all the freeze checking/blocking for a given operation,
regardless of the type of freeze we block on. That way all the
nesting semantics are located in one set of code, and it's easy to
verify correct.

> This should also deal with the locking problems you describe above as
> mnt_want_write() is always called before taking i_mutex.

*nod*

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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/