All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Lukas Wunner <lukas@wunner.de>
Cc: Sasha Levin <sashal@kernel.org>,
	Nathan Chancellor <natechancellor@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.com>,
	Mark Brown <broonie@kernel.org>,
	Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 4.19-stable 4/5] spi: bcm2835aux: Fix use-after-free on unbind
Date: Wed, 9 Dec 2020 10:36:55 +0100	[thread overview]
Message-ID: <X9Cat0z0YBZkXlvv@kroah.com> (raw)
In-Reply-To: <20201209083747.GA7377@wunner.de>

On Wed, Dec 09, 2020 at 09:37:47AM +0100, Lukas Wunner wrote:
> On Tue, Dec 08, 2020 at 04:17:45PM -0500, Sasha Levin wrote:
> > On Tue, Dec 08, 2020 at 06:11:45PM +0100, Lukas Wunner wrote:
> > > On Tue, Dec 08, 2020 at 08:47:39AM -0500, Sasha Levin wrote:
> > > > Could we instead have the backports exhibit the issue (like they did
> > > > upstream) and then take d853b3406903 on top?
> > > 
> > > The upstream commit e13ee6cc4781 did not apply cleanly to 4.19 and earlier,
> > > several adjustments were required.  Could I have made it so that the fixup
> > > d853b3406903 would have still been required?  Probably, but it seems a
> > > little silly to submit a known-bad patch.
> [...]
> > 2. It'll make auditing later easier. What will happen now is that after
> > this patch is merges, we'll trigger a warning saying that there's a fix
> > upstream for one of these patches, and we'll end up wasting the time (of
> > probably a few folks) figuring this out.
> 
> Would it be possible to amend the tooling such that multiple
> "[ Upstream commit ... ]" lines are supported at the top of
> the commit message, signifying that the backport patch
> subsumes all cited upstream commits?

You could, but that's extra work, which I think you are trying to avoid
when you say:

> Could the extra work for stable maintainers be avoided that way?

this :)


> I imagine there might be more cases where a "clean" backport is
> not possible, requiring multiple upstream patches to be combined.

It is quite rare.  And again, it's almost always better to just take all
of the patches involved, as individual patches, that way we "know" we
did it right, and it's easier to track and audit and review that way.

> > Note I'm not asking to submit a broken patch, but I'm asking to submit a
> > minimal backport followed by the upstream fix to that upstream bug :)
> 
> Then please apply the series sans bcm2835aux patch and I'll follow up
> with a two-patch series specifically for that driver.

Can you just resend the whole series so we know we got it correct?

thanks,

greg k-h

  reply	other threads:[~2020-12-09  9:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-06 12:31 [PATCH 4.19-stable 1/5] spi: Introduce device-managed SPI controller allocation Lukas Wunner
2020-12-06 12:31 ` [PATCH 4.19-stable 2/5] spi: bcm-qspi: Fix use-after-free on unbind Lukas Wunner
2020-12-06 12:31 ` [PATCH 4.19-stable 3/5] spi: bcm2835: " Lukas Wunner
2020-12-06 12:31 ` [PATCH 4.19-stable 4/5] spi: bcm2835aux: " Lukas Wunner
2020-12-08  0:49   ` Nathan Chancellor
2020-12-08  7:32     ` Lukas Wunner
2020-12-08 13:47       ` Sasha Levin
2020-12-08 17:11         ` Lukas Wunner
2020-12-08 20:28           ` Nathan Chancellor
2020-12-08 21:17           ` Sasha Levin
2020-12-09  8:37             ` Lukas Wunner
2020-12-09  9:36               ` Greg KH [this message]
2020-12-09  9:38                 ` Lukas Wunner
2020-12-09  9:44                   ` Greg KH
2020-12-10  7:01                     ` Lukas Wunner
2020-12-10 12:45                       ` Greg KH
2020-12-10 16:13                         ` Lukas Wunner
2020-12-10 19:24                           ` Lukas Wunner
2020-12-06 12:31 ` [PATCH 4.19-stable 5/5] spi: bcm2835: Release the DMA channel if probe fails after dma_init Lukas Wunner

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=X9Cat0z0YBZkXlvv@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.com \
    --cc=lukas@wunner.de \
    --cc=natechancellor@gmail.com \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=sudipm.mukherjee@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.