On Mon, Jan 15, 2018 at 1:01 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Mon, 2018-01-15 at 10:12 +0100, Dmitry Vyukov wrote: > >> However, there can be some surprising things, for example, executing >> one ioctl/setsockopt with data meant for another one, or these >> 0xffffffffffffffff are actually mean 0 (for involved reasons), > > I think those fff was actually what was throwing me off. > >> or we >> can simply have bugs in these descriptions so they don't match C >> structures and then all data is messed/shifted. > > No, I think this part was OK. > >> If this representation does not make sense to you right away, your >> best bet is looking at/running the C reproducer where you can see true >> data layout: >> >> > [...] > Yeah, good point, I should've just done that. > >> > Ah, then again, now I see the fault injection - I guess dev_set_name() >> > just failed and we didn't check the return value, will fix that. >> >> Yes, it's highly likely the root cause. The raw.log file shows there >> there was an immediately preceding fault in kmalloc in the same >> process, in a close stack. > > Yep, I submitted the fix now (with the correct reported-by). > > Also for the other one, the wiphy_register() warning. Thanks!
