I read and understood the points like one can find thousand of filesystem issues like this, but there is no point of that because the filesystem is not designed to handle those issues or those expectations. And, even if we try to solve those issues then we will get into loop of other issues.
Please confirm whether my understanding correct or not? On Mon, 16 Mar, 2020, 9:24 am Theo de Raadt, <[email protected]> wrote: > It is like you didn't read and understand the points I was making. > > Neeraj Pal <[email protected]> wrote: > > > On Thu, 27 Feb, 2020, 10:30 am Theo de Raadt, <[email protected]> > wrote: > > > > > > > > Any of a thousand failures could occur. > > > > > > 1 - you didn't fsck those filesystems. > > > 2 - even if you did, fsck does not create clean filesystems out of > garbage. > > > > > > The only tooling I know of which could convert a totally broken > filesystem > > > into a less broken filesystem is "dump | restore", but I expect even > dump > > > to be full of bugs. > > > > > > > Thanks for information, @Theo and my apologies for the delayed response. > > > > I would say there is no point in doing fsck for my purpose. Because my > > purpose was filesystem fuzzing. So, I can't use fsck because it will > > remodify some of the random fuzzed metadata bits and try to make them > > correct. > > > > > > > > This filesystem was not written to meet the parameters you expect of > it. > > > > > > We could make 50 changes to try to cope, but it will simply escalate > > > into directory loops, clusters layed out on top of directory maps which > > > get modified by fsck, etc etc etc. > > > > > > It cannot be won because this filesystem was not written to meet the > > > parameters you are suddenly expecting of it. > > > > > > > Yeah, you are correct but I have tried the same UFS filesystem fuzzing on > > NetBSD and it didn't get stuck or I haven't observed any panic/crash. > > > > I am not comparing it from NetBSD but I am just thinking whether is it > > possible to correct them or at least make them less crash/panic. > > > > Actually, I have ported the fsfuzzer into OpenBSD with some modification > > like arc4random() based calls to generate better-randomized input and > also > > improved the logging and stuff for better working. > > NetBSD also has syzkaller support for filesystem fuzzing. > > So, I was thinking of something useful on OpenBSD in the same area. > > > > I also have some other crashes like page faults, protection faults, etc. > > Should I raise them on openbsd-bugs? > > > > > > Regards, > > Neeraj > > > > > >
