On Fri, Jan 10, 2025 at 11:23:51AM +0900, Dominique Martinet wrote:
> Greg Kroah-Hartman wrote on Thu, Jan 09, 2025 at 11:09:38AM +0100:
> > On Thu, Jan 09, 2025 at 11:09:02AM +0100, Greg Kroah-Hartman wrote:
> > > > Before 74363ec674cb ("zram: fix uninitialized ZRAM not releasing backing
> > > > device") that was indeed not a problem so I confirm this is a
> > > > regression, even if it is unlikely.
> > > > It doesn't look exploitable by unprivileged users anyway so I don't have
> > > > any opinion on whether the patches should be held until upstream picks
> > > > this latest fix up as well either.
> > >
> > > Looks like Sasha just dropped the offending commit from the 5.10 and
> > > 5.15 queues (but forgot to drop some dep-of patches, I'll go fix that
> > > up), so I'll also drop the patch from the 6.1.y queue as well to keep
> > > things in sync.
> > >
> > > If you all want this change to be in 6.1.y (or any other tree), can you
> > > provide a working backport, with this patch merged into it?
> >
> > Oops, nope, this was already in a 6.1.y release, so I'll go apply this
> > patch there now. Sorry for the noise...
>
> Thank you! I hadn't even noticed the patch had made it to 6.1.122
> earlier, good catch.
>
> So to recap:
> - 6.1 is now covered;
> - for 5.15/5.10, you suggested squashing this prereq directly into the
> 74363ec674cb ("zram: fix uninitialized ZRAM not releasing backing
> device") backport ; given the patch got merged to 6.1 as is does it
> still make sense?
> I can resend both patches together as a set if it's become more
> preferable.
> (... Perhaps adding a tag like [ v6.1 tree commit xyz123 ] even if I
> doubt it's standard)
> - (for completeness I checked 5.4, 74363ec674cb doesn't apply so I won't
> bother)
A patch set is fine, as that would match what 6.1.y has now.
thanks,
greg k-h
