[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v5 1/4] xen: introduce CONFIG_GENERIC_BUG_FRAME


  • To: Oleksii <oleksii.kurochko@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 7 Mar 2023 14:16:14 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lnkl8qHeuIo2xSv5AcVadwAmFMvyNJ3U2Oj/yZGo8XE=; b=TwWPhbrg/I5yYFEBFs1gtL3zoVzoaBNbyHPfoR4fo6SCXrCIIA929vM6IEmlBqtSpGazm30sqSUNZ5q77SE0iiPYMcR8V8LLqVisMN4GzPn+tIf8kCrUwe7dENdKyaAsRCteeblU2xRllaVW01JCnn5vuJqaHV8dwKzd8iJ+he2lRouSOS5Kh6w7HG+aIKmhjbN2/p80fkD57cFk6A8IXnEP1O/bto1coT5JQ92l4O2RtCAu/G11cKQdOGNl4YWa37NklacFjKGqGSn0LqJUWu/y28eBScPEam2l5urSxo1OIfGYMd0auJYrEjn48xM1GT20HarDeUIDCI4PBWDfMg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kgbOcfcjqr47eOSCJDR5ZqtHR8YHSwiokWu1qzS8oXDz+VZyg9qFUGVCJM//zVph1cOdV/ihFPU/SEaadoR9Oxe/mCKxVhlBTO+FOQpk1YpmdEvVz2AUiXuDtm5Yh5+EiesXl6py/jBinXr1RvpTMszsZ3IPKkzjPp3YY6XqUTdgXJXd4A9kseps6aU7GT4n5OCLM8IjcUNcsQe0j58chNbdE41M5djOiW7mQZrpozbOhuZQLenaw5GoPZah2otWD2qJeSHYnzameJUPJ8ZN2A1n3nJBujzPzSE1X3pMxaL3IQypR9Oo6fGrUi+39bsjiY0wVtL+9Av97z11qRVXQg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Julien Grall <julien@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Gianluca Guida <gianluca@xxxxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 07 Mar 2023 13:16:21 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 07.03.2023 14:13, Oleksii wrote:
>>>>>> +
>>>>>> +#define BUG_FRAME(type, line, ptr, second_frame, msg) do
>>>>>> {                   \
>>>>>> +    BUILD_BUG_ON((line) >> (BUG_LINE_LO_WIDTH +
>>>>>> BUG_LINE_HI_WIDTH));         \
>>>>>> +    BUILD_BUG_ON((type) >=
>>>>>> BUGFRAME_NR);                                     \
>>>>>> +    asm volatile (
>>>>>> _ASM_BUGFRAME_TEXT(second_frame)                          \
>>>>>> +                   :: _ASM_BUGFRAME_INFO(type, line, ptr,
>>>>>> msg)
>>>>>> );            \
>>>>>> +} while (0)
>>>>
>>>> Isn't this tied to BUG_FRAME_STRUCT being defined (or not)? At
>>>> least
>>>> the 1st BUILD_BUG_ON() looks problematic if an arch wasn't to use
>>>> the generic struct: With how you have things right now
>>>> BUG_LINE_{LO,HI}_WIDTH may not be defined, and the check would
>>>> also
>>>> be at risk of causing false positives. Perhaps it's appropriate
>>>> to
>>>> have a separate #ifdef (incl the distinct identifier used), but
>>>> that
>>>> first BUILD_BUG_ON() needs abstracting out.
>> Missed that. Thanks.
>> I'll introduce that a separate #ifdef before BUG_FRAME:
>>
>> #ifndef BUILD_BUG_ON_LINE_WIDTH
>> #define BUILD_BUG_ON_LINE_WIDTH \
>>         BUILD_BUG_ON((line) >> (BUG_LINE_LO_WIDTH +
>> BUG_LINE_HI_WIDTH))
>> #endif
> I think even better will be to do in the following way:
> 
> #ifndef LINE_WIDTH
> #define LINE_WIDTH (BUG_LINE_LO_WIDTH + BUG_LINE_HI_WIDTH)
> #endif
> 
> #define BUG_FRAME(type, line, ptr, second_frame, msg) do {            
> \
>     BUILD_BUG_ON((line) >> LINE_WIDTH);                               
> \
>     BUILD_BUG_ON((type) >= BUGFRAME_NR);                              
> \
>     asm volatile ( _ASM_BUGFRAME_TEXT(second_frame)                   
> \
>                    :: _ASM_BUGFRAME_INFO(type, line, ptr, msg) );     
> \
> } while (false)

Not sure - that'll still require arches to define LINE_WIDTH. What
if they store the line number in a 32-bit field? Then defining
LINE_WIDTH to 32 would yield undefined behavior here.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.