[Bug 232387] head -r339076: system crash in vnet_epair_init during kern_jail_set in a kyua test on powerpc64

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Thu Oct 25 20:30:13 UTC 2018


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232387

--- Comment #9 from Mark Millard <marklmi26-fbsd at 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_START
         * from the base memory pointer, so pre-calculate that now to avoid
         * it on each use.
         */
        vnet->vnet_data_base = (uintptr_t)vnet->vnet_data_mem - VNET_START;

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-ppc mailing list