Bodo Eggert wrote: > Warning: I'm only looking at the patch. > > You are supposed to print an error message for a user, not to write in a > chat window to a 1337 script kiddie. OK, you just matched the current style, > and your patch is IMHO OK for a quick security fix, but: > > - Security fixes should be CCed to the security mailing list, shouldn't they? > (It might be security@ or stable@, I'll remember tomorrow, but then I'd > forget to comment) ok. > - Imagine you have three mounts containing a minix fs, how can you tell which > one is the the defective one? good point. > - The message says "minix_bmap", while the patch suggests it's in > block_to_path. Therefore I asume "minix_bmap" to have only random > informational value. Yup, you're right. > - Does block < 0 or block > $size make a difference? well, block > size is likely to arrive from a corrupt i_size, and the insistence upon going ahead and checking the next page after encountering an error on the last one... I don't have any scenario in mind where we'd be repeatedly trying to check blocks < 0. > - the printk lacks the loglevel. As do all other printk's in minixfs... (hm and 11,619 other printk's in the kernel :) ) > - Asuming minix supports error handling, shouldn't it do something? > > I'd suggest a message saying something like "minix: Bad block address on > device 08:15, needs fsck". Fair enough, as you said I was just fixing up the issue, not rewriting the code around it. But yes, I should probably have considered at least a better message here. I can fix this up & resend. But I'm not promising to audit all other printk's in minixfs this time around. ;-) -Eric - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
