lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 25 Sep 2022 08:05:58 +0100 From: "Russell King (Oracle)" <linux@...linux.org.uk> To: Marcin Wojtas <mw@...ihalf.com> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, stable <stable@...nel.org> Subject: Re: [PATCH net] net: mvpp2: debugfs: fix problem with previous memory leak fix On Sun, Sep 25, 2022 at 07:58:29AM +0100, Russell King (Oracle) wrote: > On Sun, Sep 25, 2022 at 01:27:06AM +0200, Marcin Wojtas wrote: > > Hi Russell, > > > > I improved the patch compile and work (tested on my CN913x board). > > Feel free to submit (if you wish, I can do it too - please let me know > > your preference): > > https://github.com/semihalf-wojtas-marcin/Linux-Kernel/commit/0abb75115ffb2772f595bb3346573e27e650018b > > I don't see what the compile fixes were in that - it looks like my patch > ported onto current -net. Obvious changes: > > - moved mvpp2_dbgfs_exit() declaration from after mvpp2_dbgfs_cleanup() > to before. > - moved definition of mvpp2_root to the top of the file (as no effect > on the code.) > > and the change to port it: > > - dropped my mvpp2_dbgfs_init() hunk (because it's different in -net) > - removed static declaration of mvpp2_root in mvpp2_dbgfs_init() > > I'm not seeing any other changes. > > Note that Sasha has submitted a revert of Greg's original patch for > mainline, so my original patch should apply as-is if that revert > happens - and I don't see any compile issues with it. On that - it seems the Stable kernel maintainers can't cope with being told not to apply a patch - we've had a big long discussion about it on IRC over the past few days. Sasha states that the mainline process is broken - and as long as Greg's original patch is in place, stable will repeatedly attempt to backport it no matter whether a proper fix is being worked on, whether maintainers are busy, and so on and so forth. The only way to stop stable backporting patches is to revert them in mainline - as I asked to happen in this case on the 13th. So it's all our fault for not reverting the patch. It's got nothing to do with stable maintainers unable to keep track of which patches they shouldn't be picking up. I maintain that the stable kernel process is totally broken due to this - it makes no allowance for whether maintainers can sort the problem out in a timely manner. Quite honestly, I now regard the stable kernel process as being utterly broken. In my mind, it's not a stable kernel. It's an unstable kernel with randomly applied patches that may or may not be appropriate. Certainly, stable-kernel-rules.rst is a total and utter joke - they aren't rules at all, the stable kernel maintainers don't have any rules about patches they backport. Anyway, I guess we're going to have to wait for Sasha's revert to be merged into -net first, which will make backporting our true and proper memory-leak fix a lot easier. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists