linux-ext4 - Re: [PATCH v2 5/5] ext4: remove alloc

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BANLkTimQbrOVDpgZGmhT9-rzMWEjVgkf4A@mail.gmail.com>
Date:	Tue, 10 May 2011 21:20:58 +0300
From:	"Amir G." <amir73il@...rs.sourceforge.net>
To:	"Ted Ts'o" <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org, Yongqiang Yang <xiaoqiangnk@...il.com>
Subject: Re: [PATCH v2 5/5] ext4: remove alloc_semp

On Tue, May 10, 2011 at 4:29 PM, Ted Ts'o <tytso@....edu> wrote:
> On Thu, Mar 24, 2011 at 06:58:13PM +0200, amir73il@...rs.sourceforge.net wrote:
>> From: Amir Goldstein <amir73il@...rs.sf.net>
>>
>> After taking care of all group init races, all that remains is to
>> remove alloc_semp from ext4_allocation_context and ext4_buddy structs.
>>
>> Signed-off-by: Amir Goldstein <amir73il@...rs.sf.net>
>
> Hey Amir,
>
> What sort of testing have you done with this patch series?  In
> particular, have you tried doing online resizes while the file system
> is heavily loaded?

I have tested many small resizes, not block group aligned and added
debug prints in mballoc.c to verify that in-memory bb_free and group_desc
bg_free_blocks remain in sync.

Sorry, I did not run the same tests under heavy load.
I would think that one would need to know exactly how to load his
system to make that load relevant to this test, rather than blindly
fsstressing the system.
If you have specific ideas for testing please let us know.
I think Yongqiang could run these tests.

Regarding the "risk" of online resize with this patch,
if you look at ext4_add_groupblocks() in it's new form,
you will surely notice that it is an exact replica of ext4_free_blocks()
with lots of irrelevant code removed, so the code path of online resize,
is essentially the same as the code patch of freeing any range of blocks
with regards to buddy cache init and locks.

It was actually possible to alter ext4_free_blocks() a bit and reuse it
to do most of the work done by ext4_add_groupblocks(), but I did not
want to make these changes to ext4_free_blocks(). it's your call if
you think that would be better off.

Anyway, I was kind of hoping for another pair of eyes to validate my changes
when I first posted these patches. So what do you say?
Does the core change to synchronize ext4_mb_init_group() by locking
the buddy pages look reasonable to you?
You were the one who suggested that approach in the first place.

Amir.
--
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