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: <7e19c9a0-603f-bbef-bd13-bf7252ad38e6@arm.com>
Date:   Thu, 18 Jan 2018 18:31:34 +0000
From:   Suzuki K Poulose <Suzuki.Poulose@....com>
To:     Dave Martin <Dave.Martin@....com>,
        Robin Murphy <robin.murphy@....com>
Cc:     mark.rutland@....com, marc.zyngier@....com,
        catalin.marinas@....com, will.deacon@....com,
        linux-kernel@...r.kernel.org, james.morse@....com,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 0/2] arm64: Run enable method for errata work arounds
 on late CPUs

On 18/01/18 14:25, Suzuki K Poulose wrote:
> On 18/01/18 14:21, Dave Martin wrote:
>> On Thu, Jan 18, 2018 at 12:08:43PM +0000, Robin Murphy wrote:
>>> On 18/01/18 12:00, Robin Murphy wrote:
>>> [...]
>>>>> +struct enable_arg {
>>>>> +    int (*enable)(struct arm64_cpu_capabilities const *);
>>>>> +    struct arm64_cpu_capabilities const *cap;
>>>>> +};
>>>>> +
>>>>> +static int __enable_cpu_capability(void *arg)
>>>>> +{
>>>>> +    struct enable_arg const *e = arg;
>>>>> +
>>>>> +    return e->enable(e->cap);
>>>>> +}
>>>>
>>>> AFAICS, you shouldn't even need the intermediate struct - if you were
>>>> instead to call stop_machine(&caps->enable, ...), the wrapper could be:
>>>>
>>>>      <type> **fn = arg;
>>>>      *fn(container_of(fn, struct arm64_cpu_capabilities, enable));
>>>>
>>>> (cheaty pseudocode because there's no way I'm going to write a
>>>> pointer-to-function-pointer type correctly in an email client...)
>>>>
>>>> That's certainly a fair bit simpler in terms of diffstat; whether it's
>>>> really as intuitive as I think it is is perhaps another matter, though.
>>>
>>> Ah, right, but then you'd be back to casting away const, and at that point
>>> it makes no sense to do the container_of dance instead of just passing the
>>> struct pointer itself around...
>>>
>>> I shall now excuse myself from this discussion, as I'm clearly not helping
>>> :)
>>>
>>> Robin.
>>
>> That's what I was about to say... but neat trick.
>>
>> However, it does concentrate the type fudge in one place and keeps the
>> arm64_cpu_capabilities::enable() prototype correct, so it's still better
>> than the original.
>>
>>
>> Thinking about it, the following is probably clearer and no worse:
>>
>> static int __enable_cpu_capability(void *arg)
>> {
>>     struct arm64_cpu_capabilities const *cap = arg;
>>
>>     return cap->enable(cap);
>> }
>>
>> ...
>>
>> stop_machine(__enable_cpu_capability, (void *)caps, cpu_online_mask);
>>
>>
>> In your version, the argument would be (void *)&caps->enable, which is
>> really just a proxy for (void *)caps, unless I missed something.
>>
>>
>> What do you think Suzuki?  I can respin my patch if you fancy picking it
>> up.  Either way, it's not urgent.
> 
> Thanks for cooking that up Dave & Robin. I prefer your second version.
> Please feel free to respin it. As you rightly said, this is not urgent
> and could pick it up in my re-writing of the capability infrastructure ;-)

Dave,

I have picked this up in my new series for revamping cpu capabilities and
will send it after a bit of testing. So, no need to respin it.

Cheers
Suzuki

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ