Messages in this thread | | | Date | Tue, 17 Oct 2006 14:51:58 -0700 | From | "James Lamanna" <> | Subject | Re: Linux ISO-9660 Rock Ridge bug needs fix |
| |
On 10/17/06, Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote: > James Lamanna <jlamanna@gmail.com> wrote: > > > > > Joerg Shilling wrote: [snip...] > > > > Hi Joerg, > > > > I am unable to duplicate this bug that supposedly exists even on older > > kernels. > > For instance, on a 2.6.16 kernel I do the following: > > Mm, I did not test, I did only check the source and it seems that I did > interpret the check > > len += offsetof(struct rock_ridge, u); > if (len > rs->len) { > printk(KERN_NOTICE "rock: directory entry would overflow " > "storage\n"); > printk(KERN_NOTICE "rock: sig=0x%02x, size=%d, remaining=%d\n", > sig, len, rs->len); > return -EIO; > } > > the wrong way.... because the error text is wrong. It should be corrected into > > "rock: directory entry would _underflow_ storage\n"
Yes I saw this check and misinterpreted it initially also.
I actually think 'overflow' is still correct since its testing for the calcuated size (directory entry) being larger than the size reported by the filesystem (storage).
I still submit my patch to Linus et. al. for consideration that also detects overflow in the case of a v 1.12 PX entry. I may have time to build a git kernel today or tomorrow and actually test it against a RR iso image.
> > > Using the inode field from RRip 1.12 is definitely not trivial as it may affect > many parts of the source and needs intensive testing.
Yes. If it is actually correct it allows for the use of iget_locked() in isofs/inode.c instead of iget5_locked() (per Documentation/filesystems/vfs.txt). Though I'll let a real VFS person decide if that has any advantages.
-- James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |