Date: Sat, 30 Mar 2019 07:05:59 +0000 From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 232387] head -r345558 (updated): system crash during kldload if_epair on powerpc64 (for more modern buildworld buildkernel toolchain experiments) Message-ID: <bug-232387-25139-gX6QmxRlnB@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-232387-25139@https.bugs.freebsd.org/bugzilla/> References: <bug-232387-25139@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=3D232387 --- Comment #16 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Mark Millard from comment #15) I added printing &DPCPU_NAME(epair_dpcpu) to: static void epair_dpcpu_init(void) This and ddb use gives the following information for the use of: #define _DPCPU_PTR(b, n) \ (__typeof(DPCPU_NAME(n))*)((b) + (uintptr_t)&DPCPU_NAME(n)) . . . #define DPCPU_ID_PTR(i, n) _DPCPU_PTR(dpcpu_off[(i)], n) (Typed from a picture:) &DPCPU_NAME(epair_dpcpu)=3D0xe00000008fcee810 show dpcpu_off in ddb shows: dpcpu_off[0]=3D0x1ffffffffecf6980 dpcpu_off[1]=3D0x2000000002adc980 dpcpu_off[2]=3D0x2000000002ada980 dpcpu_off[3]=3D0x2000000002ad8980 The failing virtual address was reported as: virtual address =3D 0x8e9e5198 . . . cpuid =3D 0 Then, checking: 0x1ffffffffecf6980+0xe00000008fcee810=3D=3D0x8e9e5190 so 0x8 short. But: <epair_modevent+0xd0> addi r3,r22,24 <epair_modevent+0xd4> bl <0000001b.plt_call._mtx_init> and: <_mtx_init+0x20> mr r30,r3 . . . <_mtx_init+0x60> addi r3,r30,-24 <_mtx_init+0x64> clrldi r7,r6,32 <_mtx_init+0x68> mr r6,r8 <_mtx_init+0x6c> bl <lock_init+0x8> and: <lock_init+0x140> stw r4,8(r3) So 0x8e9e5190+24-24+8=3D=3D0x8e9e5198 (the failure address). It appears to me that the dpcpu_off[i] figures are expected to convert 0xc???_????_????_???? type (direct-map) addresses to 0xe???_????_????_???? addresses but &DPCPU_NAME(epair_dpcpu) already was a 0xe???_????_????_???? type of address. The result overflowed/wrapped/truncated and was invalid. This looks likely to be a problem for any kldload'd .ko that uses a DPCPU_DEFINE and DPCPU_ID_PTR similarly to (showing my printf addition as well): struct epair_dpcpu { struct mtx if_epair_mtx; /* Per-CPU locking. */ int epair_drv_flags; /* Per-CPU ``hw'' drv flags= . */ struct eid_list epair_ifp_drain_list; /* Per-CPU list of ifps with * data in the ifq. */ }; DPCPU_DEFINE(struct epair_dpcpu, epair_dpcpu); static void epair_dpcpu_init(void) { struct epair_dpcpu *epair_dpcpu; struct eid_list *s; u_int cpuid; printf("epair_dpcpu_init: &DPCPU_NAME(epair_dpcpu)=3D%p\n", &DPCPU_NAME(epair_dpcpu)); CPU_FOREACH(cpuid) { epair_dpcpu =3D DPCPU_ID_PTR(cpuid, epair_dpcpu); /* Initialize per-cpu lock. */ EPAIR_LOCK_INIT(epair_dpcpu); . . . --=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-232387-25139-gX6QmxRlnB>