On 10.05.2023 22:13, Andrew Cooper wrote: > On 09/05/2023 3:24 pm, Jan Beulich wrote: >> On 09.05.2023 16:03, Andrew Cooper wrote: >>> On 08/05/2023 8:45 am, Jan Beulich wrote: >>>> On 04.05.2023 21:39, Andrew Cooper wrote: >>>>> When adding new words to a featureset, there is a reasonable amount of >>>>> boilerplate and it is preforable to split the addition into multiple >>>>> patches. >>>>> >>>>> GCC 12 spotted a real (transient) error which occurs when splitting >>>>> additions >>>>> like this. Right now, FEATURESET_NR_ENTRIES is dynamically generated >>>>> from the >>>>> highest numeric XEN_CPUFEATURE() value, and can be less than what the >>>>> FEATURESET_* constants suggest the length of a featureset bitmap ought to >>>>> be. >>>>> >>>>> This causes the policy <-> featureset converters to genuinely access >>>>> out-of-bounds on the featureset array. >>>>> >>>>> Rework X86_NR_FEAT to be related to FEATURESET_* alone, allowing it >>>>> specifically to grow larger than FEATURESET_NR_ENTRIES. >>>>> >>>>> Reported-by: Jan Beulich <jbeul...@suse.com> >>>>> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> >>>> While, like you, I could live with the previous patch even if I don't >>>> particularly like it, I'm not convinced of the route you take here. >>> It's the route you tentatively agreed to in >>> https://lore.kernel.org/xen-devel/a282c338-98ab-6c3f-314b-267a5a82b...@suse.com/ >> Right. Yet I deliberately said "may be the best" there, as something >> better might turn up. And getting the two numbers to always agree, as >> suggested, might end up being better. > > Then don't write "yes" if what you actually mean is "I'd prefer a > different option if possible", which is a "no". > > I cannot read your mind, and we both know I do not have time to waste on > this task. > > And now I have to go and spend yet more time doing it differently.
I'm sorry for that. Yet please also allow for me to re-consider an earlier voiced view, once I see things in more detail. Jan
