linux-ext4 - Re: ext4-block-reservation.patch

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: <46780D76.9040706@linux.vnet.ibm.com>
Date:	Tue, 19 Jun 2007 22:38:06 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Eric Sandeen <sandeen@...hat.com>
CC:	alex@...sterfs.com, linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: ext4-block-reservation.patch



Eric Sandeen wrote:
> Aneesh Kumar K.V wrote:
>> Hi,
>>
>> In block reservation code while rebalancing the free blocks why are we not 
>> looking at the reservation slots that have no free blocks left.  Rebalancing
>> the free blocks equally across all the reservation slots will make sure
>> we have less chances of failure later when we try to reserve blocks. 
>>
>>
>> I understand that we consider the CPU slot on which reservation failed while
>> rebalancing. But what is preventing considering other CPU slot that might have
>> zero blocks left ?
>>
>>
>>
>>
>> +void ext4_rebalance_reservation(struct ext4_reservation_slot *rs, __u64 free)
>> +{
>> +       int i, used_slots = 0;
>> +       __u64 chunk;
>> +
>> +       /* let's know what slots have been used */
>> +       for (i = 0; i < NR_CPUS; i++)
> 
> BTW... I think you really want:
> 
>   +       for_each_possible_cpu(i) {
> 
> in this and other similar places.
> 
> NR_CPUS is a config-time option that may be much more than your actual
> count of runtime possible CPUs... on ia64 it's 512 by default, for
> example.  That's a lot of pointlessness on a 2, 4 or 8 cpu box :)
> 
> I can whip up a proper patch for current code to send (again)...
> 

This is what i have modified. I am yet to build test it. I am looking at forward porting the
mballoc patches and was planning to send it together.

-aneesh

View attachment "0001-RFC-delayed-allocation-for-ext4.patch" of type "text/x-patch" (8070 bytes)