|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN PATCH v2 2/3] x86/uaccess: replace __{get,put}_user_bad() with STATIC_ASSERT_UNREACHABLE()
On 07.02.2024 16:58, Federico Serafini wrote:
> On 07/02/24 16:24, Jan Beulich wrote:
>> On 07.02.2024 16:08, Federico Serafini wrote:
>>> On 07/02/24 15:16, Jan Beulich wrote:
>>>> On 07.02.2024 14:51, Federico Serafini wrote:
>>>>> On 07/02/24 08:38, Jan Beulich wrote:
>>>>>> On 07.02.2024 02:08, Stefano Stabellini wrote:
>>>>>>> On Tue, 6 Feb 2024, Jan Beulich wrote:
>>>>>>>> On 26.01.2024 11:05, Federico Serafini wrote:
>>>>>>>>> @@ -208,7 +205,7 @@ do {
>>>>>>>>> \
>>>>>>>>> case 8:
>>>>>>>>> \
>>>>>>>>> put_unsafe_asm(x, ptr, grd, retval, "q", "", "ir",
>>>>>>>>> errret); \
>>>>>>>>> break;
>>>>>>>>> \
>>>>>>>>> - default: __put_user_bad();
>>>>>>>>> \
>>>>>>>>> + default: STATIC_ASSERT_UNREACHABLE();
>>>>>>>>> \
>>>>>>>>> }
>>>>>>>>> \
>>>>>>>>> clac();
>>>>>>>>> \
>>>>>>>>> } while ( false )
>>>>>>>>> @@ -227,7 +224,7 @@ do {
>>>>>>>>> \
>>>>>>>>> case 2: get_unsafe_asm(x, ptr, grd, retval, "w", "=r",
>>>>>>>>> errret); break; \
>>>>>>>>> case 4: get_unsafe_asm(x, ptr, grd, retval, "k", "=r",
>>>>>>>>> errret); break; \
>>>>>>>>> case 8: get_unsafe_asm(x, ptr, grd, retval, "", "=r",
>>>>>>>>> errret); break; \
>>>>>>>>> - default: __get_user_bad();
>>>>>>>>> \
>>>>>>>>> + default: STATIC_ASSERT_UNREACHABLE();
>>>>>>>>> \
>>>>>>>>> }
>>>>>>>>> \
>>>>>>>>> clac();
>>>>>>>>> \
>>>>>>>>> } while ( false )
>>>>>>>>
>>>>>>>> Related to my remark on patch 1 - how is one to know the macro this was
>>>>>>>> invoked from, when seeing the resulting diagnostic?
>>>>>>>
>>>>>>> I am not sure what do you mean here... we do get an error like the
>>>>>>> following (I added a STATIC_ASSERT_UNREACHABLE for case 4):
>>>>>>>
>>>>>>> ./arch/x86/include/asm/uaccess.h:262: Error: static assertion failed:
>>>>>>> unreachable
>>>>>>
>>>>>> Right - and how do I know what _user_ of the macro actually triggered
>>>>>> it? ISTR suggesting to use one or more of __FILE__ / __LINE__ /
>>>>>> __FUNCTION__ here, for that specific purpose ...
>>>>>
>>>>> To test the macro and its diagnostics,
>>>>> I modified the first "git grep" occurrence of ASSERT_UNREACHABLE()
>>>>> on the x86 code with STATIC_ASSERT_UNREACHABLE(),
>>>>> that is in file arch/x86/alternative.c, line 312,
>>>>> function _apply_alternatives().
>>>>>
>>>>> What I got is the following build error:
>>>>>
>>>>> ...
>>>>> arch/x86/alternative.c: Assembler messages:
>>>>> arch/x86/alternative.c:312: Error: static assertion failed: unreachable
>>>>> CC arch/x86/copy_page.o
>>>>> make[2]: *** [Rules.mk:247: arch/x86/alternative.o] Error 1
>>>>
>>>> But that's not what my request was about. Here sufficient context is
>>>> given, even if it would be nice if the function was also visible right
>>>> away. But that's not the same as the case above, where the new macro
>>>> is used inside another macro.
>>>
>>> An example of that is the get_unsafe_size() macro,
>>> whose body uses STATIC_ASSERT_UNREACHABLE().
>>> A wrong use of get_unsafe_size() at line n
>>> leads to a build error pointing to the line n,
>>> isn't this the desired behavior?
>>
>> Aiui this would point to the line in the header file, when what you need
>> to spot the bad use of the macro is the line in the source file actually
>> using the macro. Quoting from an earlier mail of yours:
>>
>> ./arch/x86/include/asm/uaccess.h:262: Error: static assertion failed:
>> unreachable
>
> It points to the header file uaccess.h because at line 262 there is
> an intentional wrong use of put_guest_size(), within the body of
> __copy_to_guest_pv() function.
Yet that's again only a helper function being inlined into the ultimate
caller. That ultimate caller is what wants identifying in the diag. Not
the least because of ...
> This example can be misleading because {get,put}_unsafe_size() are
> defined in the same file but the diagnostics is doing the
> right thing.
... this. And really __copy_to_guest_pv() is the wrong place to put a
wrong put_guest_size() in, to try out how diagnostics would look like
in reality: That function falls back to copy_to_guest_ll() for all
cases it can't handle directly. You want to place a bogus put_guest()
somewhere in a .c file to see what results.
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |