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