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
