On Fri, Oct 25, 2024 at 12:10:48AM +0300, ahmed Ehab wrote: > On Thu, Oct 24, 2024 at 6:35 AM Kent Overstreet <[email protected]> > wrote: > > > On Thu, Oct 24, 2024 at 01:50:15AM +0300, ahmed Ehab wrote: > > > Hi sir, > > > I am currently working on a bug related to invalid extent_entry_type. Is > > > there a place where we set this type for a bch_extent_entry? I found a > > > method for crc type but I got no luck finding a generalized method for > > this. > > > > There isn't a general method, no; and perhaps there should be, like we > > do for bkey initialization. > > > > What are you seeing? > > > I am working on this sykaller-reported bug > https://syzkaller.appspot.com/bug?extid=4f29c3f12f864d8a8d17. The failure > happens because there is a bch_extent_entry with type = 2165668814409170944. > This results in __ffs(entry->type) = 36 which is bigger than > BCH_EXTENT_ENTRY_MAX. I think we might need a place to initialize the type.
No - look at the codepath; this is the big <-> little endian conversion code. The issue is that bch2_ptr_swab() has to work on keys that haven't validated yet (because we can't validate them until they're swabbed to native endianness) - so bch2_ptr_swab() needs to cope with that and do its own validation.
