linux-kernel - Re: [PATCH v6 09/24] x86/resctrl: Use set_bit()/clear

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 29 Sep 2023 17:13:50 +0100
From:   James Morse <james.morse@....com>
To:     David Laight <David.Laight@...LAB.COM>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc:     Fenghua Yu <fenghua.yu@...el.com>,
        Reinette Chatre <reinette.chatre@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        H Peter Anvin <hpa@...or.com>,
        Babu Moger <Babu.Moger@....com>,
        "shameerali.kolothum.thodi@...wei.com" 
        <shameerali.kolothum.thodi@...wei.com>,
        D Scott Phillips OS <scott@...amperecomputing.com>,
        "carl@...amperecomputing.com" <carl@...amperecomputing.com>,
        "lcherian@...vell.com" <lcherian@...vell.com>,
        "bobo.shaobowang@...wei.com" <bobo.shaobowang@...wei.com>,
        "tan.shaopeng@...itsu.com" <tan.shaopeng@...itsu.com>,
        "xingxin.hx@...nanolis.org" <xingxin.hx@...nanolis.org>,
        "baolin.wang@...ux.alibaba.com" <baolin.wang@...ux.alibaba.com>,
        Jamie Iles <quic_jiles@...cinc.com>,
        Xin Hao <xhao@...ux.alibaba.com>,
        "peternewman@...gle.com" <peternewman@...gle.com>,
        "dfustini@...libre.com" <dfustini@...libre.com>,
        "amitsinght@...vell.com" <amitsinght@...vell.com>
Subject: Re: [PATCH v6 09/24] x86/resctrl: Use set_bit()/clear_bit() instead
 of open coding

Hi David,

On 17/09/2023 22:00, David Laight wrote:
> From: James Morse
>> Sent: 14 September 2023 18:21
>>
>> The resctrl CLOSID allocator uses a single 32bit word to track which
>> CLOSID are free. The setting and clearing of bits is open coded.
>>
>> A subsequent patch adds resctrl_closid_is_free(), which adds more open
>> coded bitmaps operations. These will eventually need changing to use
>> the bitops helpers so that a CLOSID bitmap of the correct size can be
>> allocated dynamically.
>>
>> Convert the existing open coded bit manipulations of closid_free_map
>> to use set_bit() and friends.
>>
>>  int closids_supported(void)
>> @@ -126,7 +126,7 @@ static void closid_init(void)
>>  	closid_free_map = BIT_MASK(rdt_min_closid) - 1;
>>
>>  	/* CLOSID 0 is always reserved for the default group */
>> -	closid_free_map &= ~1;
>> +	clear_bit(0, &closid_free_map);

> Don't the clear_bit() etc functions use locked accesses?

Yes. In this case there is no need for it to be atomic, just to use the bitmap API so this
can be made bigger in the future. It's currently protected by the rdtgroup_mutex (I'll add
some lockdep annotations to document that).


> These are always measurably more expensive than the C operators.

I'll switch this to use the double-underscore version which are non-atomic,
double-underscore is usually a warning not to use this function!

I doubt the performance matters as this is only ever called from a mkdir() syscall when
the configuration is changed, which we anticipate only really happens once at boot.



Thanks,

James