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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan