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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 16 Jan 2020 11:12:10 -0800 From: Ira Weiny <ira.weiny@...el.com> To: Jan Kara <jack@...e.cz> Cc: linux-kernel@...r.kernel.org, Alexander Viro <viro@...iv.linux.org.uk>, "Darrick J. Wong" <darrick.wong@...cle.com>, Dan Williams <dan.j.williams@...el.com>, Dave Chinner <david@...morbit.com>, Christoph Hellwig <hch@....de>, "Theodore Y. Ts'o" <tytso@....edu>, linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org Subject: Re: [RFC PATCH V2 08/12] fs/xfs: Add lock/unlock mode to xfs On Thu, Jan 16, 2020 at 10:24:46AM +0100, Jan Kara wrote: > On Fri 10-01-20 11:29:38, ira.weiny@...el.com wrote: > > From: Ira Weiny <ira.weiny@...el.com> > > > > XFS requires regular files to be locked while changing to/from DAX mode. > > > > Define a new DAX lock type and implement the [un]lock_mode() inode > > operation callbacks. > > > > We define a new XFS_DAX_* lock type to carry the lock through the > > transaction because we don't want to use IOLOCK as that would cause > > performance issues with locking of the inode itself. > > > > Signed-off-by: Ira Weiny <ira.weiny@...el.com> > ... > > diff --git a/fs/xfs/xfs_inode.h b/fs/xfs/xfs_inode.h > > index 492e53992fa9..693ca66bd89b 100644 > > --- a/fs/xfs/xfs_inode.h > > +++ b/fs/xfs/xfs_inode.h > > @@ -67,6 +67,9 @@ typedef struct xfs_inode { > > spinlock_t i_ioend_lock; > > struct work_struct i_ioend_work; > > struct list_head i_ioend_list; > > + > > + /* protect changing the mode to/from DAX */ > > + struct percpu_rw_semaphore i_dax_sem; > > } xfs_inode_t; > > This adds overhead of ~32k per inode for typical distro kernel. Wow! > That's not > going to fly. Probably not... > That's why ext4 has similar kind of lock in the superblock > shared by all inodes. For read side it does not matter because that's > per-cpu and shared lock. For write side we don't care as changing inode > access mode should be rare. Sounds reasonable to me. I'll convert it. Thanks for pointing this out, that would have been bad indeed. Ira
Powered by blists - more mailing lists