Re: [PATCH] x86/mm: compile out __set_fixmap_x() when not needed

[Jan Beulich <jbeulich@xxxxxxxx>]

On 09.11.2026 14:19, Jan Beulich wrote:
> On 09.11.2026 13:51, Nicola Vetrini wrote:
>> On 2026-11-09 13:35, Jan Beulich wrote:
>>> On 09.11.2026 11:50, Nicola Vetrini wrote:
>>>> On 2026-11-09 10:04, Jan Beulich wrote:
>>>>> On 07.11.2026 08:23, Nicola Vetrini wrote:
>>>>>> On 2026-11-03 12:28, Jan Beulich wrote:
>>>>>>> On 03.11.2026 10:42, Jan Beulich wrote:
>>>>>>>> Only HYPERV_GUEST has a need for an executable fixmap, so with 
>>>>>>>> that
>>>>>>>> option
>>>>>>>> unset __set_fixmap_x() (and l1_fixmap_x[] in turn) is unreachable.
>>>>>>>> Address
>>>>>>>> this Misra rule 2.1 violation by introduction ofa new FIXMAP_X
>>>>>>>> Kconfig
>>>>>>>> setting.
>>>>>>>>
>>>>>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>>>>>> ---
>>>>>>>> Why is __set_fixmap_x() not found by Eclair as a rule 2.1 
>>>>>>>> violation
>>>>>>>> in
>>>>>>>> the
>>>>>>>> x86_64-amd job?
>>>>>>>
>>>>>>> Same question actually for both functions converted to static by 
>>>>>>> [1].
>>>>>>> This
>>>>>>> apparently being a wider problem, are we (again / still) having an
>>>>>>> issue
>>>>>>> with the scanning of the linking steps?
>>>>>>>
>>>>>>> Jan
>>>>>>>
>>>>>>> [1]
>>>>>>> https://lists.xen.org/archives/html/xen-devel/2026-10/msg01537.html
>>>>>>
>>>>>> It was a Xen project decision not to consider for R2.1 functions 
>>>>>> that
>>>>>> are never referenced: you can see in
>>>>>> "automation/eclair_analysis/ECLAIR/deviations.ecl". Of course that 
>>>>>> is
>>>>>> reversible and I am in favour of not hiding those violations, but 
>>>>>> the
>>>>>> rationale for the justification that was given is that the compiler
>>>>>> will
>>>>>> indeed DCE those:
>>>>>>
>>>>>>     * - R2.1
>>>>>>       - The compiler implementation guarantees that the unreachable
>>>>>> code
>>>>>> is
>>>>>>         removed. Constant expressions and unreachable branches of if
>>>>>> and
>>>>>> switch
>>>>>>         statements are expected.
>>>>>>       - Tagged as `safe` for ECLAIR.
>>>>>
>>>>> For the cases at hand (and then likely many more) the compiler 
>>>>> doesn't
>>>>> DCE
>>>>> anything. Imo the wording here is completely bogus. It may say "If 
>>>>> the
>>>>> compiler implementation guarantees ..." Which it might do for static
>>>>> functions, but aiui without LTO it never will for non-static ones.
>>>>>
>>>>
>>>> I'm not saying the configuration is good as is. Ideally that should be
>>>> removed or restricted to static functions and the likely newly present
>>>> violations triaged.
>>>>
>>>>> Then I'm also puzzled by the deviations.ecl entry:
>>>>>
>>>>> -doc_begin="The compiler implementation guarantees that the 
>>>>> unreachable
>>>>> code is removed.
>>>>> Constant expressions and unreachable branches of if and switch
>>>>> statements are expected."
>>>>> -config=MC3A2.R2.1,+reports={safe,"first_area(^.*has an
>>>>> invariantly.*$)"}
>>>>> -config=MC3A2.R2.1,+reports={safe,"first_area(^.*incompatible with
>>>>> labeled statement$)"}
>>>>> -doc_end
>>>>>
>>>>> First - these are two different deviations, and hence imo should be 
>>>>> two
>>>>> separate entries. More important here though is that I can't connect
>>>>> the
>>>>> two config= lines to the deviation of unreferenced non-static
>>>>> functions.
>>>>> There's nothing "... has an invariantly ..."  or "... incompatible 
>>>>> with
>>>>> labeled statement ..." there? How would the full diagnostic for an
>>>>> unreferenced global function (or data item) look like?
>>>>
>>>> These two have nothing do do with functions never referenced indeed: 
>>>> the
>>>> rule is about unreachable code in general, of which functions that are
>>>> never called is just a subcase.
>>>
>>> Yet then in your earlier mail which part of deviations.ecl did you 
>>> refer
>>> to?
>>
>> Sorry, I assumed I had pasted it [1], but forgot:
>>
>> -doc_begin="Some functions are intended to be not referenced."
>> -config=MC3A2.R2.1,+reports={deliberate,"first_area(^.*is never 
>> referenced$)"}
>> -doc_end
>>
>> this bit specifically is about both static and non-static functions
> 
> Oh, I see. Since this deviation is unspecific as to static / non-static,
> I didn't think it was the one relevant here.

What's possibly worse (and what may have added to me not spotting it):
This does not look to have a representation in docs/misra/deviations.txt.
Such an inconsistency imo needs addressing.

How would the above configuration setting look like when limiting things
to static functions?

Jan