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: <alpine.LFD.2.00.1303271426420.18375@localhost> Date: Wed, 27 Mar 2013 14:31:48 +0100 (CET) From: Lukáš Czerner <lczerner@...hat.com> To: "Theodore Ts'o" <tytso@....edu> cc: Lukáš Czerner <lczerner@...hat.com>, Ext4 Developers List <linux-ext4@...r.kernel.org> Subject: Re: [PATCH 5/7] ext4: refactor truncate code On Wed, 27 Mar 2013, Theodore Ts'o wrote: > Date: Wed, 27 Mar 2013 08:36:51 -0400 > From: Theodore Ts'o <tytso@....edu> > To: Lukáš Czerner <lczerner@...hat.com> > Cc: Ext4 Developers List <linux-ext4@...r.kernel.org> > Subject: Re: [PATCH 5/7] ext4: refactor truncate code > > On Wed, Mar 27, 2013 at 11:53:42AM +0100, Lukáš Czerner wrote: > > > + up_write(&ei->i_data_sem); > > > > In ext_truncate we used to unlock it after the ext4_handle_sync(), > > however in ind_truncate we used to unlock it before the > > ext4_handle_sync(). Which one is correct ? I guess it does not have > > to be done under the i_data_sem, so maybe we can move it outside the > > semaphore in the punch_hole code as well ? > > Yes, we can move this outside of the semaphore protected code. Given > that ext4_handle_sync() an inline function which sets a single memory > location, my guess is that it didn't make a huge amount of difference, > but it's better to keep the critical section as small as possible. > I'll make that change. > > > Hmm.... one thing I'm not sure about, now that I'm looking at this > code. We call ext4_discard_preallocations() twice; once before we > remove the extent, and once afterwards. I'm not sure why we're doing > that. It doesn't look to me like ext4_free_blocks() ever releases > blocks back to the preallocation space. Am I missing something, or > could we eliminate one of the calls to ext4_discard_preallocations()? I was wondering about that as well. There is a possibility of allocation occurring in ext4_ext_remove_space() however it is only metadata allocation and as such there should be no preallocation so it seems to me that the second ext4_discard_preallocations() is unnecessary. Note that it has been there from the introduction of punch hole. However let's take it one step further. What about the first call of ext4_discard_preallocations() is this entirely necessary for a punch hole ? I am wondering whether we can optimize things by dropping the preallocation only within the hole we're punching, or possibly only when we punch a hole at the end, or past the end of the file. -Lukas > > - Ted > -- > 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