← Back to context

Comment by Aissen

4 years ago

Greg does not joke around: https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh...

    [PATCH 000/190] Revertion of all of the umn.edu commits

Seriously.... I am undecided one way or another on reverting everything, but I am happy that someone is looking closely at this.

One thing I hope they have considered is a possible intent to get a particular important patch from umn.edu reverted to reintroduce a kernel bug. Discrediting all commits from the organization could inadvertently lead to the reintroduction of legacy exploits.

How does the kernel still run after reverting like this?

  • I was wondering the same thing. From the Patch itself:

    > This patchset has the "easy" reverts, there are 68 remaining ones that need to be manually reviewed. Some of them are not able to be reverted as they already have been reverted, or fixed up with follow-on patches as they were determined to be invalid. Proof that these submissions were almost universally wrong.

  • In all likelihood, it'll run just fine.

    Skimming through subject lines of 190 commits being reverted here, every single one of them is along the lines of "add refcount/NULL/etc check and conditionally do (or do not) de-allocate memory before error-path return". I.e. worst case - this will reintroduce some rare memory leak or memory lifecycle bug.

    Also, all of patches in question are in drivers. So depending on hardware used, any given system's user is likely to only have to worry about 2-3, maybe 5 of the patches, not all 190.

  • The answer is somewhere between "it's 'only' 190 patches" and "Greg posting this patch series doesn't mean it's applied to stable yet"

>Some of them are not able to be reverted as they already have been reverted, or fixed up with follow-on patches as they were determined to be invalid. Proof that these submissions were almost universally wrong.