public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Marcin Wojtas <mw@semihalf.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	stable <stable@kernel.org>
Subject: Re: [PATCH net] net: mvpp2: debugfs: fix problem with previous memory leak fix
Date: Sun, 25 Sep 2022 08:05:58 +0100	[thread overview]
Message-ID: <Yy/91grVshObYNNR@shell.armlinux.org.uk> (raw)
In-Reply-To: <Yy/8FawjLnaE2Swj@shell.armlinux.org.uk>

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!

  reply	other threads:[~2022-09-25  7:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21 11:44 [PATCH net] net: mvpp2: debugfs: fix problem with previous memory leak fix Greg Kroah-Hartman
2022-09-22 16:05 ` Russell King (Oracle)
2022-09-22 17:08   ` Marcin Wojtas
2022-09-24 23:27     ` Marcin Wojtas
2022-09-25  6:58       ` Russell King (Oracle)
2022-09-25  7:05         ` Russell King (Oracle) [this message]
2022-09-25  7:55         ` Marcin Wojtas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yy/91grVshObYNNR@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mw@semihalf.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stable@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox