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
| ||
|
Message-ID: <20230417110721.2c6ya5v3hz6grruc@quack3> Date: Mon, 17 Apr 2023 13:07:21 +0200 From: Jan Kara <jack@...e.cz> To: "Ritesh Harjani (IBM)" <ritesh.list@...il.com> Cc: linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org, Jan Kara <jack@...e.cz>, Christoph Hellwig <hch@...radead.org>, "Darrick J . Wong" <djwong@...nel.org>, Ojaswin Mujoo <ojaswin@...ux.ibm.com>, Disha Goel <disgoel@...ux.ibm.com>, Christoph Hellwig <hch@....de> Subject: Re: [PATCHv5 2/9] fs/buffer.c: Add generic_buffer_fsync implementation On Mon 17-04-23 13:01:49, Jan Kara wrote: > On Sun 16-04-23 15:38:37, Ritesh Harjani (IBM) wrote: > > Some of the higher layers like iomap takes inode_lock() when calling > > generic_write_sync(). > > Also writeback already happens from other paths without inode lock, > > so it's difficult to say that we really need sync_mapping_buffers() to > > take any inode locking here. Having said that, let's add > > generic_buffer_fsync() implementation in buffer.c with no > > inode_lock/unlock() for now so that filesystems like ext2 and > > ext4's nojournal mode can use it. > > > > Ext4 when got converted to iomap for direct-io already copied it's own > > variant of __generic_file_fsync() without lock. Hence let's add a helper > > API and use it both in ext2 and ext4. > > > > Later we can review other filesystems as well to see if we can make > > generic_buffer_fsync() which does not take any inode_lock() as the > > default path. > > > > Tested-by: Disha Goel <disgoel@...ux.ibm.com> > > Reviewed-by: Christoph Hellwig <hch@....de> > > Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@...il.com> > > There is a problem with generic_buffer_fsync() that it does not call > blkdev_issue_flush() so the caller is responsible for doing that. That's > necessary for ext2 & ext4 so fine for now. Actually a slight correction: ext2 could use a variant of generic_buffer_fsync() that flushes disk caches. Honza -- Jan Kara <jack@...e.com> SUSE Labs, CR
Powered by blists - more mailing lists