| 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: <20110901070848.GQ32358@dastard> Date: Thu, 1 Sep 2011 17:08:48 +1000 From: Dave Chinner <david@...morbit.com> To: Allison Henderson <achender@...ux.vnet.ibm.com> Cc: linux-kernel@...r.kernel.org, Ext4 Developers List <linux-ext4@...r.kernel.org>, Andreas Dilger <adilger@...ger.ca> Subject: Re: lock i_mutex for fallocate? On Wed, Aug 31, 2011 at 05:33:25PM -0700, Allison Henderson wrote: > Hi All, > > In ext4 punch hole, we realized that the punch hole operation needs > to be done under i_mutex just like truncate. i_mutex for truncate > is held in the vfs layer, so we dont need to lock it at the file > system layer, but vfs does not lock i_mutex for fallocate. We can > lock i_mutex for fallocate at the fs layer, but question was raised > then: should i_mutex for fallocate be held in the vfs layer instead? No. > I do not know if other file systems need i_mutex to be locked for > fallocate, For one, XFS does not require i_mutex to be held for any extent manipulation of any kind (allocation, truncation, hole punch, unwritten extent conversion, etc). Hence the current structure of having the filesystem take i_mutex if it needs it to protect allocations against races is appropriate. 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/
Powered by blists - more mailing lists