Jan, ----- Ursprüngliche Mail ----- >> >> 1bcded92d938 ("mtd: block2mtd: Convert to bdev_open_by_dev/path()") >> > >> > I haven't seen this commit, I was not Cc'ed. >> >> Me neither. :-/ > > I'm sorry for that but I took the maintainers entry for BLOCK2MTD which is: > > BLOCK2MTD DRIVER > M: Joern Engel <joern@xxxxxxxxxxxxxxx> > L: linux-mtd@xxxxxxxxxxxxxxxxxxx > S: Maintained > F: drivers/mtd/devices/block2mtd.c > > And both Joern and linux-mtd were CCed on the patch. If different people > should be CCed these days, please update the entry. Thanks! Ah, you did a manual lookup? Because get_maintainer.pl seems to do the right thing: $ ./scripts/get_maintainer.pl drivers/mtd/devices/block2mtd.c Joern Engel <joern@xxxxxxxxxxxxxxx> (maintainer:BLOCK2MTD DRIVER) Miquel Raynal <miquel.raynal@xxxxxxxxxxx> (maintainer:MEMORY TECHNOLOGY DEVICES (MTD)) Richard Weinberger <richard@xxxxxx> (maintainer:MEMORY TECHNOLOGY DEVICES (MTD)) Vignesh Raghavendra <vigneshr@xxxxxx> (maintainer:MEMORY TECHNOLOGY DEVICES (MTD)) linux-mtd@xxxxxxxxxxxxxxxxxxx (open list:BLOCK2MTD DRIVER) linux-kernel@xxxxxxxxxxxxxxx (open list) >> >> from the vfs-brauner tree and commit: >> >> >> >> ff6abbe85634 ("mtd: block2mtd: Add a valid holder to blkdev_put()") >> > >> > I will drop this commit from mtd/next. Please take it through the >> > vfs-brauner tree as well to avoid conflicts or otherwise, Richard, can >> > you send an update at -rc1? >> >> A side effect of 1bcded92d938 ("mtd: block2mtd: Convert to >> bdev_open_by_dev/path()") >> is that it fixes the problem too. That's a good thing. >> >> I'm a bit puzzled how to fix the problem for 6.5.y and 6.6.y stable releases. >> Back porting 1bcded92d938 seems risky to me since the commit is large. >> On the other hand, ff6abbe85634 will not make it into Linus' tree and therefore >> is not suitable for stable either. > > Yes, that's one of the cases where stable rules make life harder for actual > fixes... You can try pushing ff6abbe85634 to stable even if it is not > upstream since it fixes a real bug and taking the upstream solution is > indeed IMO too intrusive. Sometimes stable maintainers accept such fixes. Yep, let's try this route. :-) Thanks, //richard