linux-kernel - Re: [PATCH] xen: make multicall debug boot time selectable

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] [day] [month] [year] [list]

Message-ID: <9495c804-6d23-43c5-a3c9-b91b9c27cef5@oracle.com>
Date: Mon, 8 Jul 2024 10:32:46 -0400
From: boris.ostrovsky@...cle.com
To: Jürgen Groß <jgross@...e.com>,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        linux-doc@...r.kernel.org
Cc: Jonathan Corbet <corbet@....net>, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>, xen-devel@...ts.xenproject.org
Subject: Re: [PATCH] xen: make multicall debug boot time selectable



On 7/8/24 5:04 AM, Jürgen Groß wrote:
> On 06.07.24 00:36, boris.ostrovsky@...cle.com wrote:
>>
>>

> 
>> Also, would it be better to keep these fields as a struct of scalars 
>> and instead have the percpu array of this struct? Otherwise there is a 
>> whole bunch of [MC_BATCH] arrays, all of them really indexed by the 
>> same value. (And while at it, there is no reason to have 
>> callbacks[MC_BATCH] sized like that -- it has nothing to do with batch 
>> size and can probably be made smaller)
> 
> As today the mc_buffer's entries are copied via a single memcpy(), there
> are 3 options:

Ah yes, it's memcpy, I didn't think of that. Then leaving it as is is 
the best.

> 
> - make mc_debug_data a percpu pointer to a single array, requiring to
>    copy the mc_buffer's entries in a loop
> 
> - let struct mc_debug_data contain two arrays (entries[] and struct foo 
> {}[],
>    with struct foo containing the other pointers/values)
> 
> - keep the layout as in my patch
> 
> Regarding the callbacks: I think the max number of callbacks is indeed 
> MC_BATCH,
> as for each batch member one callback might be requested. So I'd rather 
> keep it
> the way it is today.


Right, I was trying to point out that it's the max number but I suspect 
it usually is smaller --  we currently ask for a callback in fewer than 
half of the cases where we submit a request.


-boris