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: <20120704022317.GA16947@gmail.com> Date: Wed, 4 Jul 2012 10:23:17 +0800 From: Zheng Liu <gnehzuil.liu@...il.com> To: Zach Brown <zab@...bo.net> Cc: Ric Wheeler <rwheeler@...hat.com>, Jan Kara <jack@...e.cz>, Eric Sandeen <sandeen@...hat.com>, Theodore Ts'o <tytso@....edu>, Fredrick <fjohnber@...o.com>, linux-ext4@...r.kernel.org, Andreas Dilger <adilger@...ger.ca>, wenqing.lz@...bao.com Subject: Re: ext4_fallocate Hi Zach, Thanks for reviewing this patch. On Tue, Jul 03, 2012 at 10:57:35AM -0700, Zach Brown wrote: > > >workload frequently does a uninitialized extent conversion. Thus, now > >we set it to 256 (1MB chunk), and put it into super block in order to > >adjust it dynamically in sysfs. > > It's a bit of a tangent, but this caught my eye. Oh, actually now the default value is set to 1MB in this patch. But I think maybe other users want to change this value. So I add an interface in sysfs to adjust dynaimically. Certainly it is convenient for me to do the above tests. :-) > > >+ /* If extent has less than 2*s_extent_zeroout_len zerout directly */ > >+ if (ee_len<= 2*sbi->s_extent_zeroout_len&& > > (EXT4_EXT_MAY_ZEROOUT& split_flag)) { > > >- if (allocated<= EXT4_EXT_ZERO_LEN&& > >+ if (allocated<= sbi->s_extent_zeroout_len&& > > (EXT4_EXT_MAY_ZEROOUT& split_flag)) { > > > } else if ((map->m_lblk - ee_block + map->m_len< > >- EXT4_EXT_ZERO_LEN)&& > >+ sbi->s_extent_zeroout_len)&& > > I'd be worried about having to verify that nothing bad happened if these > sbi s_extent_zeroout_len references could see different values if they > raced with a sysfs update. Can they do that? > > Maybe avoid the risk all together and have an on-stack copy that's only > referenced once at the start? I don't think 's_extent_zeroout_len' is updated frequently by user, but using an on-stack copy quite can avoid the risk. I will fix it if most of all think that this patch is useful and can be applied. 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