Re: [PATCH 5.10 000/139] 5.10.168-rc1 review

[Sasha Levin]

On Tue, Feb 14, 2023 at 03:25:52PM +0000, Russell King (Oracle) wrote:
> On Tue, Feb 14, 2023 at 10:09:38AM -0500, Sasha Levin wrote:
> > On Tue, Feb 14, 2023 at 02:53:13PM +0000, Russell King (Oracle) wrote:
> > > On Tue, Feb 14, 2023 at 07:20:46AM +0100, Greg Kroah-Hartman wrote:
> > > > On Mon, Feb 13, 2023 at 11:50:24AM -0800, Florian Fainelli wrote:
> > > > > On 2/13/23 06:49, Greg Kroah-Hartman wrote:
> > > > > > This is the start of the stable review cycle for the 5.10.168 release.
> > > > > > There are 139 patches in this series, all will be posted as a response
> > > > > > to this one.  If anyone has any issues with these being applied, please
> > > > > > let me know.
> > > > > >
> > > > > > Responses should be made by Wed, 15 Feb 2023 14:46:51 +0000.
> > > > > > Anything received after that time might be too late.
> > > > > >
> > > > > > The whole patch series can be found in one patch at:
> > > > > > 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.168-rc1.gz
> > > > > > or in the git tree and branch at:
> > > > > > 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> > > > > > and the diffstat can be found below.
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > greg k-h
> > > > >
> > > > > There is a regression coming from:
> > > > >
> > > > > nvmem: core: fix registration vs use race
> > > > >
> > > > > which causes the following to happen for MTD devices:
> > > > >
> > > > > [    6.031640] kobject_add_internal failed for mtd0 with -EEXIST, don't try
> > > > > to register things with the same name in the same directory.
> > > > > [    7.846965] spi-nor: probe of spi0.0 failed with error -17
> > > > >
> > > > > attached is a full log with the call trace. This does not happen with
> > > > > v6.2-rc8 where the MTD partitions are successfully registered.
> > > >
> > > > Can you use `git bisect` to find the offending commit?
> > >
> > > The reason for this is because, due to how my patch series was
> > > backported, you have ended up with nvmem_register() initialising
> > > its embedded device, and then calling device_add() on it _twice_.
> > >
> > > Basically, the backport of:
> > >
> > > 	"nvmem: core: fix registration vs use race"
> > >
> > > is broken, because the original patch _moved_ the device_add() and
> > > that has not been carried forward to whatever got applied to stable
> > > trees.
> > >
> > > It looks like the 5.15-stable version of this patch was correct.
> > >
> > > Maybe whoever tried to fixup the failure needs to try again?
> >
> > I've dropped the backport series from both 5.15 and 5.10.
>
> So you've dropped what looks to be a perfectly good backport in 5.15,
> and all of the 5.10 despite it just being the last patch which is the
> problem. Sounds like a total over-reaction to me.

The context is that we want to get the releases out today, and neither
of us will have time to verify that we did the right thing in 5.15 in
the next few hours.

I'm just defering it to the next release cycle which is probably a few
days away, not completely throwing it away.... why is it such a big
deal?

--
Thanks,
Sasha