On Tue, Nov 7, 2017 at 2:21 AM, Fengguang Wu <fengguang...@intel.com> wrote: > > FYI this happens in v4.14-rc8 -- it's not necessarily a new bug.
Probably not. Looks like a use-after-free bug in vlan_device_event() judging by the base pointer: ECX: 6b6b6b6b this is one of those circumstances where having the faddr2line output for that EIP would make it much easier to see exactly which access it is that causes problems. There's lots of inlining going on, so without that it's a pain to figure out. The code is 0: 31 c0 xor %eax,%eax 2: 8d 76 00 lea 0x0(%esi),%esi 5: 89 c2 mov %eax,%edx 7: 89 c3 mov %eax,%ebx 9: 81 e2 ff 0f 00 00 and $0xfff,%edx f: 89 d1 mov %edx,%ecx 11: c1 fb 0c sar $0xc,%ebx 14: c1 e9 09 shr $0x9,%ecx 17: 8d 0c d9 lea (%ecx,%ebx,8),%ecx 1a: 8b 4c 8e 10 mov 0x10(%esi,%ecx,4),%ecx 1e: 85 c9 test %ecx,%ecx 20: 74 34 je 0x56 22: 81 e2 ff 01 00 00 and $0x1ff,%edx 28:* 8b 14 91 mov (%ecx,%edx,4),%edx <-- trapping instruction 2b: 85 d2 test %edx,%edx 2d: 74 27 je 0x56 2f: f6 82 30 01 00 00 01 testb $0x1,0x130(%edx) 36: 74 1e je 0x56 and just by going by the constants in question (0xfff and 0x1ff), I can see that it's one of vlan_group_for_each_dev(..) { ... } things, but that's pretty much all I can tell. Apparently we'll get that faddr2line output soon. In the meantime, I think this is a real bug report but I don't see enough information to really go on. Of course, if it's bisectable, that would be great too. Linus