> I'd argue the differences are not just style changes and even "just style" changes are not trivial.
Op did all the research and multiple implementations of a fix. Ellerman refactored the fix to be simpler, but the effect is the same.
> The kernel style guide specifically mentions to avoid using conditional compilation where possible, and as a result, Michael Ellerman's patch is far cleaner.
It more seems like he knew about IS_ENABLED and Miculas didn't, because he uses `IS_ENABLED(CONFIG_PPC32)` instead of Miculas' `#ifdef CONFIG_PPC32`. Besides, Ellerman's changes are all inside `#ifdef CONFIG_PPC_FPU_REGS` blocks anyway so I'm not sure this was a major consideration. Using `IS_ENABLED` gets you 90% of the way to the "cleaner" patch, and in a ~30 line patch I don't know if it's worth golfing further.
Oh he also got a code review giving him exactly these tips [0]. IDK, getting real "I don't want to coach this rookie, I'll just do this myself, thanks for the tip" vibes from Ellerman here. Maybe that's valid, but it seems like not a wonderful way to keep people interested in kernel dev.
I'm just disagreeing that the patches are the same. I agree that Miculas did do the hard work by finding the cause of the issue in the first place - but he's correctly credited as the reporter.
As for the clean patch - part of the issue is that Miculas was slightly overengineering some of it with the additional macros and added noise with extra conditions on the fpidx declaration.
Ellerman's "I don't want to coach this rookie" vibe is somewhat understandable given this is the security mailing list - it's just not the time and the place to be going back-and-forth.
I generally agree and gave you an upvote. The macros up top were hard for me to grok too, mostly I was reading it thinking, "why isn't this just a cast" and it turns out is could be! And I get this is the security mailing list, but it's 32-bit PPC, and they took days to really get to it. FWIW I think Ariel was being overly cautious; it's hard to see how this could be a significant security issue, and it feels counterproductive to punish him for being cautious. I can kind of see both sides, but I just can't get over doing all the work Ariel did and only getting a "Reported by" credit. His feelings are justified IMO.
Op did all the research and multiple implementations of a fix. Ellerman refactored the fix to be simpler, but the effect is the same.
> The kernel style guide specifically mentions to avoid using conditional compilation where possible, and as a result, Michael Ellerman's patch is far cleaner.
It more seems like he knew about IS_ENABLED and Miculas didn't, because he uses `IS_ENABLED(CONFIG_PPC32)` instead of Miculas' `#ifdef CONFIG_PPC32`. Besides, Ellerman's changes are all inside `#ifdef CONFIG_PPC_FPU_REGS` blocks anyway so I'm not sure this was a major consideration. Using `IS_ENABLED` gets you 90% of the way to the "cleaner" patch, and in a ~30 line patch I don't know if it's worth golfing further.
Miculas' patch: https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...
Ellerman's patch: https://lore.kernel.org/all/20220609133245.573565-1-mpe@elle...
EDIT:
Oh he also got a code review giving him exactly these tips [0]. IDK, getting real "I don't want to coach this rookie, I'll just do this myself, thanks for the tip" vibes from Ellerman here. Maybe that's valid, but it seems like not a wonderful way to keep people interested in kernel dev.
[0]: https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-June/24...