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. ~Andrew
