linux-kernel - Re: [git pull] vfs.git - including i

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] [day] [month] [year] [list]

Date:	Sun, 24 Jan 2016 07:48:50 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Dave Chinner <david@...morbit.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [git pull] vfs.git - including i_mutex wrappers

On Sun, Jan 24, 2016 at 06:04:06PM +1100, Dave Chinner wrote:

> Hence even for ->setattr, we can remove the IOLOCK usage if the
> vfs takes the the new i_rwsem in exclusive mode because we would
> still have a functional IO submission barrier....
> 
> > For data operations on regular files it's probably up to filesystems, as
> > i_mutex is now.  Not sure if IOLOCK would map well on that; can you live with
> > that thing taken outside of transaction?
> 
> Yes. IOLOCK has the same scope as i_mutex in the IO path.

Umm...  So e.g. xfs_create() could take IOLOCK before xfs_trans_reserve()?
If so, you probably could eventually be able to use ->i_rwsem for it (and
drop it in places where it's already taken by method callers).  I'm nowhere
near being familiar enough with details of fs/xfs locking to tell how much
PITA would the last part be - e.g. a function used both inside ->lookup()
and in ->read_iter() and currently taking IOLOCK shared would need to
have it lifted into both callers and removed from ->lookup(), etc., which
might or might not be painful.