Re: What to do with a kernel bug which lets my package work result look bad ?
On Sat, 05 Sep 2015, Thomas Schmitt wrote:
> packages (*), i stumbled over a bug in fs/isofs/rock.c which
> truncates filenames of length 254 or 255 to quite random
> lengths and thus can let readdir(3) emit multiple identical
> names in the same directory.
Ugh. Yeah, that code looks broken at first glance. Looks like it doesn't
try to return as much as possible of a file name when it hits the character
limit: it seems to just end the filename at the previous chunk.
Maybe it should instead drop the long name, and return the ISOFS name,
instead. Nasty crap will, of course, happen if there is a
colision between the two namespaces. I don't know enough about Rock Ridge
to know whether it mandates something specific in this regard.
Whatever is done to fix this, it needs to properly handle 255-byte file
names, anyway. A simple fix at first glance would be to append enough of
the current chunk to hit exactly the 255-byte boundary, and truncate at that
point. This would fix the issue for all valid ISOFS+RRIP filename sizes.
However, one has to check the code throughoutly to ensure it can deal with
the 255-bytes size. If it doesn't, that's a separate bug that needs fixing.
> What to do now with this knowledge ?
Opening a bug report on bugzilla.kernel.org for 'isofs' would be the typical
way to go about it, I guess. You could just report in LKML as well, but
then you must ask again should nobody reply after two weeks, etc.
> Does Debian have a kernel department ? With round tuits ?
We do, but they're often overworked. You can file a bug in the Debian BTS
against the "linux" source package, which is the kernel.
> (On LKML they will at best urge me to fix it myself.
They'd like you to do that, I suppose, since nobody is really working on
ISOFS. But this is a clear bug that hits legal filesystems, so it is not a
"fix it yourself" deal. It MIGHT be a "fix it yourself if you want it done
anytime soon", though :-(
OTOH, it is a >10-year old bug, so there are some kudos and credit to be
proud of for anyone that fixes it :-)
> ISO 9660 driver. This constant "254" might have a good
> reason. Who can tell ?)
Most of the RRIP support in Linux ISOFS predates git (2.6.11/2.6.12), which
kinda means in practice that you are better off analysing the code in depth
to find out its limitations (and fix them).
The code in fs/isofs/rock.c looks like it has lots of cowebs and some
bitrot, though.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: