which is quickly disproven: and now instead of just reverting the commit that didn't belong in the first place, 9 more commits are getting backported:

And just like every other case I've seen of this, nobody ever bothers trying to get to the root cause of the problem, and the person who created the problem is nowhere to be found. Greg makes up some alternate history ("we're bug compatible"). .

Generate videos in just a few seconds. Try Grok Imagine, free for a limited time.

Also looks like the same stable maintainer is responsible for the ext4 regression in 6.16.1+: took a single patch ( ) out of a series of 11 that built on each other:

Should have been a two line fix, but they decided to go back to explicit cleanup instead.

Looks like just a bad assumption, the kfree cleanup can handle NULL because kfree itself can handle NULL, their cleanup function didn't.

@andersonc0d3 related to yesterday's discussion :).

Funny how rules seem to only be applied in a certain direction, never against people who are "too big to lose".

When a CoC complaint was brought by me against Greg KH's libel against the researcher, causing his name to show up on news sites saying he tried to "backdoor" the kernel, the board (which Greg KH is a member of), surprisingly found no violations, no apology necessary.

mentioning that while there's clearly a person involved, they're ignoring feedback about what's being shoveled out. A CoC complaint was raised against them: the person has been forced to apologize and was told they need to politely raise this with the person privately.

actions" before even speaking to the person, ignoring their response that they were being slandered. In 2025, a kernel developer (not me) complained about a stable maintainer sending untagged, unverified AI slop to mailing lists, including bogus URLs, nonsensical explanations. .

It would be remiss of me to not point out the hypocrisy of the Linux CoC: in 2021, before there were any published rules on labeling human-written patches arising from experimental static analysis tools, Greg KH publicly accused an academic researcher of "intentionally malicious.

Fixes tag I think should be 8ca1b5a49885f0c0c486544da46a9e0ac790831d : Also explains their confusion, as the cited commit was from 2 years before cpusets_insane_config_key was introduced.

Just paid the last of the 7.5 year maintenance fees for the third RAP patent, time flies.

Same message, so presumably same company:

net: usb: asix_devices: add phy_mask for ax88772 mdio bus.

4 bad backports to 6.16 yesterday of known-broken commits with already-existing fixes:.btrfs: zoned: reserve data_reloc block group on mount.iommu/vt-d: Optimize iotlb_sync_map for non-caching/non-RWBF modes.mfd: axp20x: Set explicit ID for AXP313 regulator.

paper inc I guess:

Code was refactored/removed in 6.17, which is probably why only 6.16 has the problem currently.

Also triggers with ext4/036 from fstests:

There's no point in reporting this stuff because the vulnerability is simple:. stable maintainers using AI who have no idea what they're doing and are using it as a substitute for the work everyone else assumes they've performed. It'll keep happening until that bug's fixed.