[Bug 233341] 12.0-RC1 i386 vnet does not behave like the amd64 vnet version.

[bugzilla-noreply at freebsd.org]

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

--- Comment #10 from Kristof Provost <kp at freebsd.org> ---
A simple kldload pflog / kldunload pflog is sufficient to provoke this on i386,
but not on amd64.

The panic happens trying to access V_pflogifs in pflog_clone_destroy():
#15 0x224022c0 in pflog_clone_destroy (ifp=0x22fc7800) at
/usr/src/sys/netpfil/pf/if_pflog.c:149
149                     if (V_pflogifs[i] == ifp)

(kgdb) info registers
eax            0xffffffc0       -64
ecx            0x7597b08        123304712
edx            0x2      2
ebx            0x9aa7680        162166400
esp            0x0      0x0
ebp            0x1db26acc       0x1db26acc
esi            0x22fc7800       586971136
edi            0x22fc7800       586971136
eip            0x224022c0       0x224022c0
eflags         0x210246 2163270
cs             0x20     32
ss             0x0      0
ds             0x28     40
es             0x28     40
fs             0x8      8
gs             0x0      0
(kgdb) disassemble
Dump of assembler code for function pflog_clone_destroy:
0x224022a0 <pflog_clone_destroy+0>:     push   %ebp
0x224022a1 <pflog_clone_destroy+1>:     mov    %esp,%ebp
0x224022a3 <pflog_clone_destroy+3>:     push   %esi
0x224022a4 <pflog_clone_destroy+4>:     push   %eax
0x224022a5 <pflog_clone_destroy+5>:     mov    $0xffffffc0,%eax
0x224022aa <pflog_clone_destroy+10>:    mov    0x8(%ebp),%esi
0x224022ad <pflog_clone_destroy+13>:    nop
0x224022ae <pflog_clone_destroy+14>:    nop
0x224022af <pflog_clone_destroy+15>:    nop
0x224022b0 <pflog_clone_destroy+16>:    mov    %fs:0x0,%ecx
0x224022b7 <pflog_clone_destroy+23>:    mov    0x31c(%ecx),%ecx
0x224022bd <pflog_clone_destroy+29>:    mov    0x1c(%ecx),%ecx
0x224022c0 <pflog_clone_destroy+32>:    cmp    %esi,0x22403140(%ecx,%eax,1)
<-------------
0x224022c7 <pflog_clone_destroy+39>:    je     0x224022d0
<pflog_clone_destroy+48>
0x224022c9 <pflog_clone_destroy+41>:    add    $0x4,%eax

Strangely, adding a printf("KP: %d\n", i); just before that prevents it from
panicking. With that printf() the module unloads just fine. Disassembling that
version shows:

        for (i = 0; i < PFLOGIFS_MAX; i++) {
        printf("KP %d\n", i);
    12b0:       89 7c 24 04             mov    %edi,0x4(%esp)
    12b4:       c7 04 24 71 01 00 00    movl   $0x171,(%esp)
    12bb:       e8 fc ff ff ff          call   12bc <pflog_clone_destroy+0x1c>
    12c0:       64 a1 00 00 00 00       mov    %fs:0x0,%eax
                if (V_pflogifs[i] == ifp)
    12c6:       8b 80 1c 03 00 00       mov    0x31c(%eax),%eax
    12cc:       8b 40 1c                mov    0x1c(%eax),%eax
    12cf:       39 b4 b8 00 21 00 00    cmp    %esi,0x2100(%eax,%edi,4)
    12d6:       75 0b                   jne    12e3 <pflog_clone_destroy+0x43>
                        V_pflogifs[i] = NULL;
    12d8:       c7 84 b8 00 21 00 00    movl   $0x0,0x2100(%eax,%edi,4)
<-------------------
    12df:       00 00 00 00
static void
pflog_clone_destroy(struct ifnet *ifp)
{
        int i;

        for (i = 0; i < PFLOGIFS_MAX; i++) {
    12e3:       47                      inc    %edi
    12e4:       83 ff 10                cmp    $0x10,%edi
    12e7:       75 c7                   jne    12b0 <pflog_clone_destroy+0x10>
        printf("KP %d\n", i);
                if (V_pflogifs[i] == ifp)
                        V_pflogifs[i] = NULL;

As opposed to the panicking version:
        for (i = 0; i < PFLOGIFS_MAX; i++)
                if (V_pflogifs[i] == ifp)
    12b7:       8b 89 1c 03 00 00       mov    0x31c(%ecx),%ecx
    12bd:       8b 49 1c                mov    0x1c(%ecx),%ecx
    12c0:       39 b4 01 40 21 00 00    cmp    %esi,0x2140(%ecx,%eax,1)
<--------------
    12c7:       74 07                   je     12d0 <pflog_clone_destroy+0x30>

It's almost as if there's a compiler issue here. My x86 asm foo is a bit too
weak to work out what's supposed to be happening here, and what might be wrong.

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