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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.11.2026 19:43, Nicola Vetrini wrote:
> On 2026-11-10 13:57, Jan Beulich wrote:
>> 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?
> 
> Probably something like:
> 
> -config=MC3A2.R2.1,+reports={deliberate,"first_area(^.*is never 
> referenced$&&decl(kind(function)&&storage_duration(static))"}

Using that (with the missing parenthesis added) I get (pipeline [1])
no change in numbers for Arm64 and a drop by 4 for x86-64, compared
to the results with [2]). With that I'm not sure whether it's worth
keeping the rule in this modified form vs deleting it altogether.

Jan

[1] https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/3059613055
[2] https://lists.xen.org/archives/html/xen-devel/2026-11/msg01007.html