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: <20130326055530.GB17165@gmail.com> Date: Tue, 26 Mar 2013 13:55:30 +0800 From: Zheng Liu <gnehzuil.liu@...il.com> To: Theodore Ts'o <tytso@....edu>, Eric Sandeen <sandeen@...hat.com>, Ext4 Developers List <linux-ext4@...r.kernel.org>, Jan Kara <jack@...e.cz> Subject: Re: [PATCH] ext4: fix ext4_evict_inode() racing against workqueue processing code On Tue, Mar 26, 2013 at 01:52:51PM +0800, Zheng Liu wrote: > Sorry for the late reply. > > On Wed, Mar 20, 2013 at 10:45:23AM -0400, Theodore Ts'o wrote: > > On Wed, Mar 20, 2013 at 09:14:42AM -0500, Eric Sandeen wrote: > > > > > > As an aside, is there any reason to have "dioread_nolock" as an option > > > at this point? If it works now, would you ever *not* want it? > > > > > > (granted it doesn't work with some journaling options etc, but that > > > behavior could be automatic, w/o the need for special mount options). > > > > The primary restriction is that diread_nolock doesn't work when fs > > block size != page size. If your proposal is that we automatically > > enable diread_nolock when we can use it safely, that's definitely > > something to consider for the next merge window. > > Yes, I also think we can automatically enable dioread_nolock because it > brings us some benefits. > > BTW, I think there is an minor improvement for dio overwrite codepath > with indirect-based file. We don't need to take i_mutex in this > condition just as we have done for extent-based file. If a user mounts > a ext2/3 file system with a ext4 kernel modules, he/she could get a > lower latency. But it seems that it would break dio semantic in ext2/3. > Currently in ext2/3 if we issue a overwrite dio and then issue a read > dio. We will always read the latest data because we wait on i_mutex > lock. But after parallelizing overwite dio, this semantic might breaks. > I re-read this doc but it seems that it doesn't describe this case. ^^^ Ah, sorry, I forgot to paste the link here. https://ext4.wiki.kernel.org/index.php/Clarifying_Direct_IO%27s_Semantics Regards, - Zheng -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists