Date: Sat, 01 Sep 2018 22:14:08 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 231064] data abort in in_pcbremlbgrouphash() on ThunderX Message-ID: <bug-231064-227-hZuGP4bGm2@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-231064-227@https.bugs.freebsd.org/bugzilla/> References: <bug-231064-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231064 --- Comment #1 from Mark Johnston <markj@FreeBSD.org> --- It looks like the lbgroup hash table is getting corrupted; many of the list heads are equal to 0xffffff00ffffff or 0xffffff. Nothing on the system actually uses SO_REUSEPORT_LB, so we shouldn't be inserting any hash table entries. I tried making the hash-table read-only using pmap_protect(), but that doesn't seem to catch the problem - the system still panics the same w= ay.=20 This plus the fact that the bug is apparently sensitive to memory layout (g= oes away when compiling with GENERIC or when increasing KSTACK_PAGES) makes it = seem like this isn't a generic kernel bug. That said, there are some bugs in the SO_REUSEPORT_LB implementation: - Lookups are protected with epoch, but the hash table doesn't use CK_ lists and we don't defer frees of the hash table entries. - in_pcblbgroup_free() uses the wrong malloc type. - Lots of style bugs. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-231064-227-hZuGP4bGm2>