[PATCH] erofs: move erofs out of staging

[Qu Wenruo]

[...]
> 
> Yeah, it looks like we need searching more levels mapping to find the final
> physical block address of inode/node/data in btrfs.
> 
> IMO, in a little lazy way, we can reform and reuse existed function in
> btrfs-progs which can find the mapping info of inode/node/data according to
> specified ino or ino+pg_no.

Maybe no need to go as deep as ino.

What about just go physical bytenr? E.g. for XFS/EXT* choose a random
bytenr. Then verify if that block is used, if not, try again.

If used, check if it's metadata. If not, try again.
(feel free to corrupt data, in fact btrfs uses some data as space cache,
so it should make some sense)

If metadata, corrupt that bytenr/bytenr range in the metadata block,
regenerate checksum, call it a day and let kernel suffer.

For btrfs, just do extra physical -> logical convert in the first place,
then follow the same workflow.
It should work for any fs as long as it's on single device.

> 
>>
>> It may depends on the granularity. But definitely a good idea to do so
>> in a generic way.
>> Currently we depend on super kind student developers/reporters on such
> 
> Yup, I just guess Wen Xu may be interested in working on a generic way to fuzz
> filesystem, as I know they dig deep in filesystem code when doing fuzz.

Don't forget Yoon Jungyeon, I see more than one times he reported fuzzed
images with proper reproducer and bugzilla links.
Even using his personal mail address, not school mail address.

Those guys are really awesome!

> BTW,
> which impresses me is, constructing checkpoint by injecting one byte, and then
> write a correct recalculated checksum value on that checkpoint, making that
> checkpoint looks valid...

IIRC F2FS guys may be also investigating a similar mechanism, as they
also got a hard fight against reports from those awesome reporters.

So such fuzzed image is a new trend for fs development.

Thanks,
Qu

> 
> Thanks,
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/linux-erofs/attachments/20190820/3e4288e7/attachment.sig>