Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Oct 2018 20:30:11 +0000
From:      bugzilla-noreply@freebsd.org
To:        powerpc@FreeBSD.org
Subject:   [Bug 232387] head -r339076: system crash in vnet_epair_init during kern_jail_set in a kyua test on powerpc64
Message-ID:  <bug-232387-25139-843ACQoj01@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 #9 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
(In reply to Mark Millard from comment #6)

Looks to me like r29 is the value of
(uintptr_t)&VNET_NAME(n) <from _VNET_PTR>.

But r30 is supposed to be:

(curthread->td_vnet)->vnet_data_base

where:

        /*
         * All use of vnet-specific data will immediately subtract VNET_STA=
RT
         * from the base memory pointer, so pre-calculate that now to avoid
         * it on each use.
         */
        vnet->vnet_data_base =3D (uintptr_t)vnet->vnet_data_mem - VNET_STAR=
T;

and:

/*
 * Location of the kernel's 'set_vnet' linker set.
 */
extern uintptr_t        *__start_set_vnet;
__GLOBL(__start_set_vnet);
extern uintptr_t        *__stop_set_vnet;
__GLOBL(__stop_set_vnet);

#define VNET_START      (uintptr_t)&__start_set_vnet
#define VNET_STOP       (uintptr_t)&__stop_set_vnet

This traces back to differing definitions for wokring vs. crashing.

Working (gcc 4.2.1 toolchain)
/boot/kernel/kernel :
00000000013dba00 g       *ABS*  0000000000000000 __start_set_vnet
/boot/kernel/if_epair.ko :
0000000000015448 g       *ABS*  0000000000000000 __start_set_vnet

devel/powerpc64-xtoolchain-gcc based kernel:
/boot/kergoo/kernel :
0000000001223800 g       set_vnet       0000000000000000 .protected
__start_set_vnet
/boot/kergoo/if_epair.ko :
0000000000014d30 g       set_vnet       0000000000000000 .protected
__start_set_vnet

This apparently leads to VNET_START being some small value, possibly 0.
That in turn means that ?->vnet_data_base ends up not being the intended
offset but directly an address.

This makes adding:

(uintptr_t)&VNET_NAME(n) <from _VNET_PTR>.

and:

(curthread->td_vnet)->vnet_data_base

junk that makes the indexed store sdtx r3,r29,r30 fail for a bad target
address.

--=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-843ACQoj01>