kernel page fault in r8712u

kernel page fault in r8712u

[Haggai Eran]

Hi,

I've encountered the oops below running the r8712u driver. It occurred
on Raspberry Pi (OpenELEC 5.95 beta, running kernel version 4.0.3),
with the following device:
> 0bda:8172 Realtek Semiconductor Corp. RTL8191SU 802.11n WLAN Adapter

I'd be happy to dig in and see what the problem is, but I wanted to
make sure this is the right driver to look at. linuxwireless.org says
that this driver is going to be replaced by rtl8192su [1].

Have you seen this issue?

Thanks,
Haggai

[1] http://linuxwireless.org/en/users/Drivers/rtl819x/

[  834.537661] Unable to handle kernel paging request at virtual
address a9d797d7
[  834.544900] pgd = 96b14000
[  834.547604] [a9d797d7] *pgd=00000000
[  834.551186] Internal error: Oops: 5 [#1] ARM
[  834.555449] Modules linked in: cfg80211 bluetooth r8712u(C)
bcm2708_rng [last unloaded: btusb]
[  834.564092] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G         C
  4.0.1 #1
[  834.571303] Hardware name: BCM2708
[  834.574702] task: 9703a700 ti: 97056000 task.ti: 97056000
[  834.580125] PC is at put_compound_page+0x64/0x1d0
[  834.584833] LR is at put_page+0x48/0x4c
[  834.588670] pc : [<80076354>]    lr : [<80076508>]    psr: 00000113
[  834.588670] sp : 97057d70  ip : 97057d88  fp : 97057d84
[  834.600129] r10: 97335c00  r9 : 0000003c  r8 : 00000c21
[  834.605345] r7 : 9723cf00  r6 : 972a6900  r5 : 972a6900  r4 : 5d270b9a
[  834.611862] r3 : d7a0d795  r2 : d7a0d795  r1 : 00000001  r0 : a9d797d7
[  834.618390] Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment kernel
[  834.625690] Control: 00c5387d  Table: 16b14008  DAC: 00000015
[  834.631429] Process ksoftirqd/0 (pid: 3, stack limit = 0x97056188)
[  834.637601] Stack: (0x97057d70 to 0x97058000)
[  834.641957] 7d60:                                     00000000
972a6900 97057d94 97057d88
[  834.650132] 7d80: 80076508 800762fc 97057db4 97057d98 803d86c0
800764cc 9723cf00 89868bd0
[  834.658308] 7da0: 89868420 89868bd0 97057dcc 97057db8 803d8748
803d8660 00000001 9723cf00
[  834.666483] 7dc0: 97057de4 97057dd0 803d8844 803d872c 40000113
898c2d18 97057df4 97057de8
[  834.674657] 7de0: 803e4b94 803d8828 97057e14 97057df8 7f01a714
803e4b5c 00000009 89868420
[  834.682831] 7e00: 898c2d18 00000000 97057e4c 97057e18 7f01b094
7f01a6f4 8986a420 00000760
[  834.691003] 7e20: 972a6260 89868420 898c2d18 8986a420 00000c80
00000c21 0000003c 97335c00
[  834.699179] 7e40: 97057e6c 97057e50 7f01c6fc 7f01b014 000000ec
898c2d18 972a6906 00000018
[  834.707353] 7e60: 97057ebc 97057e70 7f01a354 7f01c6d4 9703a730
89868c34 97322480 8986a420
[  834.715529] 7e80: 89868bd0 9723cf00 fffff580 00000002 9703a730
00000000 00000000 8082cbec
[  834.723702] 7ea0: 80864760 00000000 80864780 80864780 97057edc
97057ec0 8001e12c 7f01a1b8
[  834.731874] 7ec0: 00000001 40000000 00000100 97056000 97057f2c
97057ee0 8001e4d8 8001e0c0
[  834.740048] 7ee0: 80033bc0 80033a88 973db180 04208040 00027227
0000000a 80864780 97056020
[  834.748223] 7f00: 97057f28 97002560 97056000 00000000 00000001
8082cbb8 00000002 00000000
[  834.756397] 7f20: 97057f3c 97057f30 8001e630 8001e3fc 97057f64
97057f40 80036430 8001e610
[  834.764568] 7f40: 00000000 97002580 97002560 80036320 00000000
00000000 97057fac 97057f68
[  834.772741] 7f60: 80032ff0 8003632c c4c0d0c4 00000001 00000000
97002560 00000000 97057f7c
[  834.780913] 7f80: 97057f7c 00000000 97057f88 97057f88 97002580
80032f1c 00000000 00000000
[  834.789088] 7fa0: 00000000 97057fb0 8000e740 80032f28 00000000
00000000 00000000 00000000
[  834.797261] 7fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[  834.805432] 7fe0: 00000000 00000000 00000000 00000000 00000013
00000000 c4c0ceca d0c0c040
[  834.813594] Backtrace:
[  834.816072] [<800762f0>] (put_compound_page) from [<80076508>]
(put_page+0x48/0x4c)
[  834.823722]  r5:972a6900 r4:00000000
[  834.827331] [<800764c0>] (put_page) from [<803d86c0>]
(skb_release_data+0x6c/0xcc)
[  834.834904] [<803d8654>] (skb_release_data) from [<803d8748>]
(skb_release_all+0x28/0x2c)
[  834.843071]  r7:89868bd0 r6:89868420 r5:89868bd0 r4:9723cf00
[  834.848759] [<803d8720>] (skb_release_all) from [<803d8844>]
(consume_skb+0x28/0x5c)
[  834.856490]  r4:9723cf00 r3:00000001
[  834.860088] [<803d881c>] (consume_skb) from [<803e4b94>]
(__dev_kfree_skb_any+0x44/0x48)
[  834.868167]  r4:898c2d18 r3:40000113
[  834.871974] [<803e4b50>] (__dev_kfree_skb_any) from [<7f01a714>]
(r8712_free_recvframe+0x2c/0x9c [r8712u])
[  834.881891] [<7f01a6e8>] (r8712_free_recvframe [r8712u]) from
[<7f01b094>] (recv_func+0x8c/0x6e8 [r8712u])
[  834.891533]  r6:00000000 r5:898c2d18 r4:89868420 r3:00000009
[  834.897456] [<7f01b008>] (recv_func [r8712u]) from [<7f01c6fc>]
(r8712_recv_entry+0x34/0x78 [r8712u])
[  834.906667]  r10:97335c00 r9:0000003c r8:00000c21 r7:00000c80
r6:8986a420 r5:898c2d18
[  834.914518]  r4:89868420
[  834.917398] [<7f01c6c8>] (r8712_recv_entry [r8712u]) from
[<7f01a354>] (recv_tasklet+0x1a8/0x31c [r8712u])
[  834.927047]  r6:00000018 r5:972a6906 r4:898c2d18 r3:000000ec
[  834.932903] [<7f01a1ac>] (recv_tasklet [r8712u]) from [<8001e12c>]
(tasklet_hi_action+0x78/0xcc)
[  834.941680]  r10:80864780 r9:80864780 r8:00000000 r7:80864760
r6:8082cbec r5:00000000
[  834.949529]  r4:00000000
[  834.952086] [<8001e0b4>] (tasklet_hi_action) from [<8001e4d8>]
(__do_softirq+0xe8/0x214)
[  834.960166]  r7:97056000 r6:00000100 r5:40000000 r4:00000001
[  834.965849] [<8001e3f0>] (__do_softirq) from [<8001e630>]
(run_ksoftirqd+0x2c/0x3c)
[  834.973492]  r10:00000000 r9:00000002 r8:8082cbb8 r7:00000001
r6:00000000 r5:97056000
[  834.981339]  r4:97002560
[  834.983901] [<8001e604>] (run_ksoftirqd) from [<80036430>]
(smpboot_thread_fn+0x110/0x15c)
[  834.992173] [<80036320>] (smpboot_thread_fn) from [<80032ff0>]
(kthread+0xd4/0xf0)
[  834.999731]  r9:00000000 r8:00000000 r7:80036320 r6:97002560
r5:97002580 r4:00000000
[  835.007519] [<80032f1c>] (kthread) from [<8000e740>]
(ret_from_fork+0x14/0x34)
[  835.014738]  r7:00000000 r6:00000000 r5:80032f1c r4:97002580
[  835.020420] Code: e590001c e5943000 e3130902 0a00001d (e5903000)
[  835.026527] ---[ end trace 633783c74480b173 ]---
[  835.031145] Kernel panic - not syncing: Fatal exception in interrupt
[  835.037494] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

Re: kernel page fault in r8712u

[Larry Finger]

On 05/16/2015 07:17 AM, Haggai Eran wrote:
> Hi,
>
> I've encountered the oops below running the r8712u driver. It occurred
> on Raspberry Pi (OpenELEC 5.95 beta, running kernel version 4.0.3),
> with the following device:
>> 0bda:8172 Realtek Semiconductor Corp. RTL8191SU 802.11n WLAN Adapter
>
> I'd be happy to dig in and see what the problem is, but I wanted to
> make sure this is the right driver to look at. linuxwireless.org says
> that this driver is going to be replaced by rtl8192su [1].
>
> Have you seen this issue?
>
> Thanks,
> Haggai
>
> [1] http://linuxwireless.org/en/users/Drivers/rtl819x/
>
> [  834.537661] Unable to handle kernel paging request at virtual
> address a9d797d7
> [  834.544900] pgd = 96b14000
> [  834.547604] [a9d797d7] *pgd=00000000
> [  834.551186] Internal error: Oops: 5 [#1] ARM
> [  834.555449] Modules linked in: cfg80211 bluetooth r8712u(C)
> bcm2708_rng [last unloaded: btusb]
> [  834.564092] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G         C
>    4.0.1 #1
> [  834.571303] Hardware name: BCM2708
> [  834.574702] task: 9703a700 ti: 97056000 task.ti: 97056000
> [  834.580125] PC is at put_compound_page+0x64/0x1d0
> [  834.584833] LR is at put_page+0x48/0x4c
> [  834.588670] pc : [<80076354>]    lr : [<80076508>]    psr: 00000113
> [  834.588670] sp : 97057d70  ip : 97057d88  fp : 97057d84
> [  834.600129] r10: 97335c00  r9 : 0000003c  r8 : 00000c21
> [  834.605345] r7 : 9723cf00  r6 : 972a6900  r5 : 972a6900  r4 : 5d270b9a
> [  834.611862] r3 : d7a0d795  r2 : d7a0d795  r1 : 00000001  r0 : a9d797d7
> [  834.618390] Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
> Segment kernel
> [  834.625690] Control: 00c5387d  Table: 16b14008  DAC: 00000015
> [  834.631429] Process ksoftirqd/0 (pid: 3, stack limit = 0x97056188)
> [  834.637601] Stack: (0x97057d70 to 0x97058000)
> [  834.641957] 7d60:                                     00000000

--snip--

> [  834.813594] Backtrace:
> [  834.816072] [<800762f0>] (put_compound_page) from [<80076508>]
> (put_page+0x48/0x4c)
> [  834.823722]  r5:972a6900 r4:00000000
> [  834.827331] [<800764c0>] (put_page) from [<803d86c0>]
> (skb_release_data+0x6c/0xcc)
> [  834.834904] [<803d8654>] (skb_release_data) from [<803d8748>]
> (skb_release_all+0x28/0x2c)
> [  834.843071]  r7:89868bd0 r6:89868420 r5:89868bd0 r4:9723cf00
> [  834.848759] [<803d8720>] (skb_release_all) from [<803d8844>]
> (consume_skb+0x28/0x5c)
> [  834.856490]  r4:9723cf00 r3:00000001
> [  834.860088] [<803d881c>] (consume_skb) from [<803e4b94>]
> (__dev_kfree_skb_any+0x44/0x48)
> [  834.868167]  r4:898c2d18 r3:40000113
> [  834.871974] [<803e4b50>] (__dev_kfree_skb_any) from [<7f01a714>]
> (r8712_free_recvframe+0x2c/0x9c [r8712u])
> [  834.881891] [<7f01a6e8>] (r8712_free_recvframe [r8712u]) from
> [<7f01b094>] (recv_func+0x8c/0x6e8 [r8712u])

Yes, this driver will likely be replaced, but I have no idea how soon that will be.

No, I am not aware of this problem, but see below.

The problem appears to be from r8712u. From the stack dump, the problem happens 
when r8712_free_recvframe() calls __dev_kfree_skb_any(). A complication is that 
my copy of the kernel source does not show such a call. :(

Please use gdb to help with the debugging. From the main directory of your 
source, enter the command 'gdb drivers/staging/rtl8712/r8712u.ko'. Once it 
prompts you, enter 'l *r8712_free_recvframe+0x2c'. The first character is ell, 
not one. That will show the actual line of code. Please post that info.

This driver has been used for a long time with x86 architecture, but not much 
with ARM, which has different alignment issues. That may be the source of the 
problem.

Larry

Re: kernel page fault in r8712u

[Haggai Eran]

On 16 May 2015 at 17:57, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> The problem appears to be from r8712u. From the stack dump, the problem
> happens when r8712_free_recvframe() calls __dev_kfree_skb_any(). A
> complication is that my copy of the kernel source does not show such a call.
> :(
>
> Please use gdb to help with the debugging. From the main directory of your
> source, enter the command 'gdb drivers/staging/rtl8712/r8712u.ko'. Once it
> prompts you, enter 'l *r8712_free_recvframe+0x2c'. The first character is
> ell, not one. That will show the actual line of code. Please post that info.

Here's what I get:

(gdb) l *r8712_free_recvframe+0x2c
0x16714 is in r8712_free_recvframe (drivers/staging/rtl8712/rtl8712_recv.c:145).
140             struct _adapter *padapter = precvframe->u.hdr.adapter;
141             struct recv_priv *precvpriv = &padapter->recvpriv;
142
143             if (precvframe->u.hdr.pkt) {
144
dev_kfree_skb_any(precvframe->u.hdr.pkt);/*free skb by driver*/
145                     precvframe->u.hdr.pkt = NULL;
146             }
147             spin_lock_irqsave(&pfree_recv_queue->lock, irqL);
148             list_del_init(&(precvframe->u.hdr.list));
149             list_add_tail(&(precvframe->u.hdr.list),
&pfree_recv_queue->queue);

It seems that dev_kfree_skb_any is an inline function that calls
__dev_kfree_skb_any,
so that should explain why that call didn't show up in the stack dump.

Haggai

Re: kernel page fault in r8712u

[Larry Finger]

On 05/16/2015 12:16 PM, Haggai Eran wrote:
> On 16 May 2015 at 17:57, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> The problem appears to be from r8712u. From the stack dump, the problem
>> happens when r8712_free_recvframe() calls __dev_kfree_skb_any(). A
>> complication is that my copy of the kernel source does not show such a call.
>> :(
>>
>> Please use gdb to help with the debugging. From the main directory of your
>> source, enter the command 'gdb drivers/staging/rtl8712/r8712u.ko'. Once it
>> prompts you, enter 'l *r8712_free_recvframe+0x2c'. The first character is
>> ell, not one. That will show the actual line of code. Please post that info.
>
> Here's what I get:
>
> (gdb) l *r8712_free_recvframe+0x2c
> 0x16714 is in r8712_free_recvframe (drivers/staging/rtl8712/rtl8712_recv.c:145).
> 140             struct _adapter *padapter = precvframe->u.hdr.adapter;
> 141             struct recv_priv *precvpriv = &padapter->recvpriv;
> 142
> 143             if (precvframe->u.hdr.pkt) {
> 144
> dev_kfree_skb_any(precvframe->u.hdr.pkt);/*free skb by driver*/
> 145                     precvframe->u.hdr.pkt = NULL;
> 146             }
> 147             spin_lock_irqsave(&pfree_recv_queue->lock, irqL);
> 148             list_del_init(&(precvframe->u.hdr.list));
> 149             list_add_tail(&(precvframe->u.hdr.list),
> &pfree_recv_queue->queue);
>
> It seems that dev_kfree_skb_any is an inline function that calls
> __dev_kfree_skb_any,
> so that should explain why that call didn't show up in the stack dump.

Thanks. From your original posting, the bad address for precvframe->u.hdr.pkt is 
a9d797d7. I'm a little bothered by that odd address. I would have expected it to 
be even, at least. The actual definition should be OK with the alignment, but 
there are a number of places where there is a cast. If the alignment of the 
object of the cast is wrong, then that might cause the problem. It will take a 
while to trace back through your call chain to see if any of these are involved 
here.

I will be back to you later.

Larry

Re: kernel page fault in r8712u

[Larry Finger]

On 05/16/2015 12:16 PM, Haggai Eran wrote:
> On 16 May 2015 at 17:57, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> The problem appears to be from r8712u. From the stack dump, the problem
>> happens when r8712_free_recvframe() calls __dev_kfree_skb_any(). A
>> complication is that my copy of the kernel source does not show such a call.
>> :(
>>
>> Please use gdb to help with the debugging. From the main directory of your
>> source, enter the command 'gdb drivers/staging/rtl8712/r8712u.ko'. Once it
>> prompts you, enter 'l *r8712_free_recvframe+0x2c'. The first character is
>> ell, not one. That will show the actual line of code. Please post that info.

Another location needed from gdb is "l *recv_func+0x8c".

Thanks,

Larry

Re: kernel page fault in r8712u

[Haggai Eran]

On 16 May 2015 at 20:54, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> Another location needed from gdb is "l *recv_func+0x8c".

Here it is:
(gdb) l *recv_func+0x8c
0x17094 is in recv_func (drivers/staging/rtl8712/rtl8712_recv.c:1004).
999                     r8712_free_recvframe(orig_prframe, pfree_recv_queue);
1000                    goto _exit_recv_func;
1001            }
1002    _exit_recv_func:
1003            return retval;
1004    }
1005
1006    static int recvbuf2recvframe(struct _adapter *padapter, struct
sk_buff *pskb)
1007    {
1008            u8 *pbuf, shift_sz = 0;

I don't think this means the relevant call is the one at line 999. I
think it is an earlier call, after r8712_validate_recv_frame. Here's
the disassembly:

        /* check the frame crtl field and decache */
        retval = r8712_validate_recv_frame(padapter, prframe);
   17070:       e1a00004        mov     r0, r4
   17074:       e1a01005        mov     r1, r5
   17078:       ebfffffe        bl      17bc0 <r8712_validate_recv_frame>
        if (retval != _SUCCESS) {
   1707c:       e3500001        cmp     r0, #1
                        r8712_free_recvframe(orig_prframe, pfree_recv_queue);
                        goto _exit_recv_func;
                }
        }
        /* check the frame crtl field and decache */
        retval = r8712_validate_recv_frame(padapter, prframe);
   17080:       e1a06000        mov     r6, r0
        if (retval != _SUCCESS) {
   17084:       0a000005        beq     170a0 <recv_func+0x98>
                /* free this recv_frame */
                r8712_free_recvframe(orig_prframe, pfree_recv_queue);
   17088:       e1a00005        mov     r0, r5
   1708c:       e1a01007        mov     r1, r7
   17090:       ebfffffe        bl      166e8 <r8712_free_recvframe>
                r8712_free_recvframe(orig_prframe, pfree_recv_queue);
                goto _exit_recv_func;
        }
_exit_recv_func:
        return retval;
}
   17094:       e1a00006        mov     r0, r6

Haggai

Re: kernel page fault in r8712u

[Arend van Spriel]

On 17-05-15 06:25, Haggai Eran wrote:
> On 16 May 2015 at 20:54, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> Another location needed from gdb is "l *recv_func+0x8c".
>
> Here it is:
> (gdb) l *recv_func+0x8c
> 0x17094 is in recv_func (drivers/staging/rtl8712/rtl8712_recv.c:1004).
> 999                     r8712_free_recvframe(orig_prframe, pfree_recv_queue);
> 1000                    goto _exit_recv_func;
> 1001            }
> 1002    _exit_recv_func:
> 1003            return retval;
> 1004    }
> 1005
> 1006    static int recvbuf2recvframe(struct _adapter *padapter, struct
> sk_buff *pskb)
> 1007    {
> 1008            u8 *pbuf, shift_sz = 0;
>
> I don't think this means the relevant call is the one at line 999. I
> think it is an earlier call, after r8712_validate_recv_frame. Here's
> the disassembly:

can you provide the address of recv_func as well to determine the exact 
location in assembly.

Regards,
Arend

>          /* check the frame crtl field and decache */
>          retval = r8712_validate_recv_frame(padapter, prframe);
>     17070:       e1a00004        mov     r0, r4
>     17074:       e1a01005        mov     r1, r5
>     17078:       ebfffffe        bl      17bc0 <r8712_validate_recv_frame>
>          if (retval != _SUCCESS) {
>     1707c:       e3500001        cmp     r0, #1
>                          r8712_free_recvframe(orig_prframe, pfree_recv_queue);
>                          goto _exit_recv_func;
>                  }
>          }
>          /* check the frame crtl field and decache */
>          retval = r8712_validate_recv_frame(padapter, prframe);
>     17080:       e1a06000        mov     r6, r0
>          if (retval != _SUCCESS) {
>     17084:       0a000005        beq     170a0 <recv_func+0x98>
>                  /* free this recv_frame */
>                  r8712_free_recvframe(orig_prframe, pfree_recv_queue);
>     17088:       e1a00005        mov     r0, r5
>     1708c:       e1a01007        mov     r1, r7
>     17090:       ebfffffe        bl      166e8 <r8712_free_recvframe>
>                  r8712_free_recvframe(orig_prframe, pfree_recv_queue);
>                  goto _exit_recv_func;
>          }
> _exit_recv_func:
>          return retval;
> }
>     17094:       e1a00006        mov     r0, r6
>
> Haggai
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: kernel page fault in r8712u

[Haggai Eran]

On 17 May 2015 at 13:29, Arend van Spriel <aspriel@gmail.com> wrote:
> On 17-05-15 06:25, Haggai Eran wrote:
>>
>> On 16 May 2015 at 20:54, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>>
>>> Another location needed from gdb is "l *recv_func+0x8c".
>>
>>
>> Here it is:
>> (gdb) l *recv_func+0x8c
>> 0x17094 is in recv_func (drivers/staging/rtl8712/rtl8712_recv.c:1004).
>> 999                     r8712_free_recvframe(orig_prframe,
>> pfree_recv_queue);
>> 1000                    goto _exit_recv_func;
>> 1001            }
>> 1002    _exit_recv_func:
>> 1003            return retval;
>> 1004    }
>> 1005
>> 1006    static int recvbuf2recvframe(struct _adapter *padapter, struct
>> sk_buff *pskb)
>> 1007    {
>> 1008            u8 *pbuf, shift_sz = 0;
>>
>> I don't think this means the relevant call is the one at line 999. I
>> think it is an earlier call, after r8712_validate_recv_frame. Here's
>> the disassembly:
>
>
> can you provide the address of recv_func as well to determine the exact
> location in assembly.

Yes, it is in offset 0x17008 in the module:
> 00017008 <recv_func>:

Regards,
Haggai

>
>>          /* check the frame crtl field and decache */
>>          retval = r8712_validate_recv_frame(padapter, prframe);
>>     17070:       e1a00004        mov     r0, r4
>>     17074:       e1a01005        mov     r1, r5
>>     17078:       ebfffffe        bl      17bc0 <r8712_validate_recv_frame>
>>          if (retval != _SUCCESS) {
>>     1707c:       e3500001        cmp     r0, #1
>>                          r8712_free_recvframe(orig_prframe,
>> pfree_recv_queue);
>>                          goto _exit_recv_func;
>>                  }
>>          }
>>          /* check the frame crtl field and decache */
>>          retval = r8712_validate_recv_frame(padapter, prframe);
>>     17080:       e1a06000        mov     r6, r0
>>          if (retval != _SUCCESS) {
>>     17084:       0a000005        beq     170a0 <recv_func+0x98>
>>                  /* free this recv_frame */
>>                  r8712_free_recvframe(orig_prframe, pfree_recv_queue);
>>     17088:       e1a00005        mov     r0, r5
>>     1708c:       e1a01007        mov     r1, r7
>>     17090:       ebfffffe        bl      166e8 <r8712_free_recvframe>
>>                  r8712_free_recvframe(orig_prframe, pfree_recv_queue);
>>                  goto _exit_recv_func;
>>          }
>> _exit_recv_func:
>>          return retval;
>> }
>>     17094:       e1a00006        mov     r0, r6

Re: kernel page fault in r8712u

[Haggai Eran]

I added some debugging prints, trying to see more details about the
packet that fails the r8712_validate_recv_frame. I noticed I'm getting
many packets where recv_decache returns _FAIL. However, the last two
packets before the crash fail for different reasons. The first has the
ver field set to 3 (instead of zero). The second (the one that get's
freed and cause the crash apparently) has an unknown type (12). If I'm
not mistaken, 12 = WIFI_CTRL_TYPE | WIFI_DATA_TYPE. Is that possible?

It could be that the packet headers are garbled though.

Haggai

On 17 May 2015 at 20:20, Haggai Eran <haggai.eran@gmail.com> wrote:
> On 17 May 2015 at 13:29, Arend van Spriel <aspriel@gmail.com> wrote:
>> On 17-05-15 06:25, Haggai Eran wrote:
>>>
>>> On 16 May 2015 at 20:54, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>>>
>>>> Another location needed from gdb is "l *recv_func+0x8c".
>>>
>>>
>>> Here it is:
>>> (gdb) l *recv_func+0x8c
>>> 0x17094 is in recv_func (drivers/staging/rtl8712/rtl8712_recv.c:1004).
>>> 999                     r8712_free_recvframe(orig_prframe,
>>> pfree_recv_queue);
>>> 1000                    goto _exit_recv_func;
>>> 1001            }
>>> 1002    _exit_recv_func:
>>> 1003            return retval;
>>> 1004    }
>>> 1005
>>> 1006    static int recvbuf2recvframe(struct _adapter *padapter, struct
>>> sk_buff *pskb)
>>> 1007    {
>>> 1008            u8 *pbuf, shift_sz = 0;
>>>
>>> I don't think this means the relevant call is the one at line 999. I
>>> think it is an earlier call, after r8712_validate_recv_frame. Here's
>>> the disassembly:
>>
>>
>> can you provide the address of recv_func as well to determine the exact
>> location in assembly.
>
> Yes, it is in offset 0x17008 in the module:
>> 00017008 <recv_func>:
>
> Regards,
> Haggai
>
>>
>>>          /* check the frame crtl field and decache */
>>>          retval = r8712_validate_recv_frame(padapter, prframe);
>>>     17070:       e1a00004        mov     r0, r4
>>>     17074:       e1a01005        mov     r1, r5
>>>     17078:       ebfffffe        bl      17bc0 <r8712_validate_recv_frame>
>>>          if (retval != _SUCCESS) {
>>>     1707c:       e3500001        cmp     r0, #1
>>>                          r8712_free_recvframe(orig_prframe,
>>> pfree_recv_queue);
>>>                          goto _exit_recv_func;
>>>                  }
>>>          }
>>>          /* check the frame crtl field and decache */
>>>          retval = r8712_validate_recv_frame(padapter, prframe);
>>>     17080:       e1a06000        mov     r6, r0
>>>          if (retval != _SUCCESS) {
>>>     17084:       0a000005        beq     170a0 <recv_func+0x98>
>>>                  /* free this recv_frame */
>>>                  r8712_free_recvframe(orig_prframe, pfree_recv_queue);
>>>     17088:       e1a00005        mov     r0, r5
>>>     1708c:       e1a01007        mov     r1, r7
>>>     17090:       ebfffffe        bl      166e8 <r8712_free_recvframe>
>>>                  r8712_free_recvframe(orig_prframe, pfree_recv_queue);
>>>                  goto _exit_recv_func;
>>>          }
>>> _exit_recv_func:
>>>          return retval;
>>> }
>>>     17094:       e1a00006        mov     r0, r6

Re: kernel page fault in r8712u

[Larry Finger]

On 05/17/2015 02:22 PM, Haggai Eran wrote:
> I added some debugging prints, trying to see more details about the
> packet that fails the r8712_validate_recv_frame. I noticed I'm getting
> many packets where recv_decache returns _FAIL. However, the last two
> packets before the crash fail for different reasons. The first has the
> ver field set to 3 (instead of zero). The second (the one that get's
> freed and cause the crash apparently) has an unknown type (12). If I'm
> not mistaken, 12 = WIFI_CTRL_TYPE | WIFI_DATA_TYPE. Is that possible?
>
> It could be that the packet headers are garbled though.

I think the headers are garbled. Did you log the address of the skb at 
precvframe->u.hdr.pkt in r8712_free_recvframe() or orig_prframe->u.hdr.pct in 
recv_func().

I am still dubious of the cast "prframe = (union recv_frame *)pcontext;" in 
recv_func().

Larry

Re: kernel page fault in r8712u

[Haggai Eran]

On 18 May 2015 at 18:31, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 05/17/2015 02:22 PM, Haggai Eran wrote:
>>
>> I added some debugging prints, trying to see more details about the
>> packet that fails the r8712_validate_recv_frame. I noticed I'm getting
>> many packets where recv_decache returns _FAIL. However, the last two
>> packets before the crash fail for different reasons. The first has the
>> ver field set to 3 (instead of zero). The second (the one that get's
>> freed and cause the crash apparently) has an unknown type (12). If I'm
>> not mistaken, 12 = WIFI_CTRL_TYPE | WIFI_DATA_TYPE. Is that possible?
>>
>> It could be that the packet headers are garbled though.
>
>
> I think the headers are garbled. Did you log the address of the skb at
> precvframe->u.hdr.pkt in r8712_free_recvframe() or orig_prframe->u.hdr.pct
> in recv_func().
I haven't. I'll print that.

>
> I am still dubious of the cast "prframe = (union recv_frame *)pcontext;" in
> recv_func().

Why? As far as I can see, recv_func is called only at one place
(r8712_recv_entry), where it is passed a union recv_frame * as the
pcontext parameter.

Haggai

Re: kernel page fault in r8712u

[Haggai Eran]

On 18 May 2015 at 18:31, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 05/17/2015 02:22 PM, Haggai Eran wrote:
>>
>> I added some debugging prints, trying to see more details about the
>> packet that fails the r8712_validate_recv_frame. I noticed I'm getting
>> many packets where recv_decache returns _FAIL. However, the last two
>> packets before the crash fail for different reasons. The first has the
>> ver field set to 3 (instead of zero). The second (the one that get's
>> freed and cause the crash apparently) has an unknown type (12). If I'm
>> not mistaken, 12 = WIFI_CTRL_TYPE | WIFI_DATA_TYPE. Is that possible?
>>
>> It could be that the packet headers are garbled though.
>
>
> I think the headers are garbled. Did you log the address of the skb at
> precvframe->u.hdr.pkt in r8712_free_recvframe() or orig_prframe->u.hdr.pct
> in recv_func().

I added prints of the skb pointer in every call to recv_func. Here are
the results:

...
[  674.111771] recv_func: pcontext = 96335820, prframe->u.hdr.pkt = 9729fb40
[  674.118782] recv_func: pcontext = 963359b8, prframe->u.hdr.pkt = 9729f6c0
[  674.125777] recv_func: pcontext = 96335930, prframe->u.hdr.pkt = 9729f780
[  674.132769] recv_func: pcontext = 963358a8, prframe->u.hdr.pkt = 973d56c0
[  674.139753] recv_func: pcontext = 96335d70, prframe->u.hdr.pkt = 973d5000
[  674.146922] recv_func: pcontext = 963361b0, prframe->u.hdr.pkt = 973d5000
[  674.153961] recv_func: pcontext = 963360a0, prframe->u.hdr.pkt = 973d5000
[  674.161023] recv_func: pcontext = 96336128, prframe->u.hdr.pkt = 973d5000
[  674.168186] recv_func: pcontext = 96336018, prframe->u.hdr.pkt = 973d5000
[  674.175231] recv_func: pcontext = 96335f90, prframe->u.hdr.pkt = 973d5000
[  674.182141] r8712_validate_recv_frame: ver = 1
[  674.186814] recv_func: pcontext = 96335f08, prframe->u.hdr.pkt = 973d5000
[  674.193811] r8712_validate_recv_frame: ver = 1
[  674.198530] recv_func: pcontext = 963363d0, prframe->u.hdr.pkt = 973d5000
[  674.205434] r8712_validate_recv_frame: ver = 3
[  674.210018] Unable to handle kernel NULL pointer dereference at
virtual address 00000001
[  674.218209] pgd = 80004000
[  674.221025] [00000001] *pgd=00000000
[  674.224752] Internal error: Oops: 5 [#1] ARM
[  674.229028] Modules linked in: rfcomm cfg80211 r8712u(C) btusb
bluetooth bcm2708_rng
[  674.236857] CPU: 0 PID: 530 Comm: kworker/0:1 Tainted: G        WC
    4.0.3 #1
[  674.244247] Hardware name: BCM2708
[  674.247663] task: 962cdee0 ti: 960fc000 task.ti: 960fc000
[  674.253082] PC is at put_page+0xc/0x68
[  674.256853] LR is at skb_release_data+0x6c/0xcc
[  674.261388] pc : [<800933e0>]    lr : [<80433fe4>]    psr: 20000113
[  674.261388] sp : 960fdc18  ip : 960fdc28  fp : 960fdc24
[  674.272856] r10: 84d6cc00  r9 : 0000fff8  r8 : 00002f17
[  674.278079] r7 : 973d5000  r6 : 84dc7620  r5 : 84dc7620  r4 : 00000000
[  674.284602] r3 : 00000037  r2 : 00000000  r1 : 00000001  r0 : 00000001
[  674.291127] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment kernel
[  674.298432] Control: 00c5387d  Table: 168a4008  DAC: 00000015
[  674.304179] Process kworker/0:1 (pid: 530, stack limit = 0x960fc188)
[  674.310532] Stack: (0x960fdc18 to 0x960fe000)
[  674.314893] dc00:
    960fdc44 960fdc28
[  674.323076] dc20: 80433fe4 800933e0 973d5000 96309010 96308520
96309010 960fdc5c 960fdc48
[  674.331257] dc40: 8043406c 80433f84 00000001 973d5000 960fdc74
960fdc60 8043413c 80434050
[  674.339437] dc60: 40000113 963363d0 960fdc84 960fdc78 80441c08
80434120 960fdcac 960fdc88
[  674.347618] dc80: 7f10ca70 80441bd0 00000000 96308520 963363d0
00000000 96309010 00002f17
[  674.355798] dca0: 960fdce4 960fdcb0 7f10d3f8 7f10ca50 960fdcd4
960fdcc0 80439aac 96308520
[  674.363978] dcc0: 963363d0 9630a520 00002f80 00002f17 0000fff8
84d6cc00 960fdd04 960fdce8
[  674.372157] dce0: 7f10eb84 7f10d36c 000000d2 963363d0 84dc7626
00000018 960fdd54 960fdd08
[  674.380338] dd00: 7f10c65c 7f10eb5c 96308ff0 963090d4 9729f840
9630b520 96309010 973d5000
[  674.388518] dd20: ffff2f00 00000002 808f4590 96309094 808f458c
8093f820 00000000 96a32900
[  674.396698] dd40: 8093f840 40000000 960fdd7c 960fdd58 8001fbbc
7f10c4b8 0000833e 00000000
[  674.404879] dd60: 00000000 00000102 960fc000 8093f840 960fddcc
960fdd80 8001ffc0 8001fb48
[  674.413058] dd80: 8054e348 80052428 00000001 00000001 04208060
0001b61a 00000009 960fc000
[  674.421237] dda0: 00000000 00000000 80920c94 00000000 00000000
00000000 8003555c 00000000
[  674.429416] ddc0: 960fdde4 960fddd0 80020474 8001fea4 00000000
00000000 960fde0c 960fdde8
[  674.437598] dde0: 80057298 800203bc 960fde20 8054e760 60000013
f200b200 960fde54 972ba1e0
[  674.445777] de00: 960fde1c 960fde10 800081e4 80057224 960fde7c
960fde20 800127f8 800081cc
[  674.453957] de20: 8054e75c 00000001 962cdee0 00000000 808f6668
969021e0 97051140 00000000
[  674.462140] de40: 972ba1e0 8003555c 00000000 960fde7c 960fde58
960fde68 8004b37c 8054e760
[  674.470319] de60: 60000013 ffffffff 00000000 808f6668 960fdeac
960fde80 8003e738 8054e73c
[  674.478499] de80: 00000001 00000000 8003e6cc 960fde98 97239140
962cdee0 808f6668 972ba1e0
[  674.486679] dea0: 960fded4 960fdeb0 80549748 8003e6d8 960fded8
960fc000 808f5834 808f5834
[  674.494860] dec0: 808f5864 00000008 960fdeec 960fded8 80549ad8
80549558 962cdee0 971e55a0
[  674.503039] dee0: 960fdf24 960fdef0 80035590 80549aa0 972c4940
971e55a0 800354cc 00000000
[  674.511220] df00: 972c4940 971e55a0 800354cc 00000000 00000000
00000000 960fdfac 960fdf28
[  674.519401] df20: 8003a080 800354d8 00000000 00000000 960fdf4c
971e55a0 00000000 00000001
[  674.527581] df40: dead4ead ffffffff ffffffff 8093fd70 00000000
00000000 80646d2c 960fdf5c
[  674.535759] df60: 960fdf5c 00000000 00000001 dead4ead ffffffff
ffffffff 8093fd70 00000000
[  674.543939] df80: 00000000 80646d2c 960fdf88 960fdf88 972c4940
80039fa0 00000000 00000000
[  674.552118] dfa0: 00000000 960fdfb0 8000e8f0 80039fac 00000000
00000000 00000000 00000000
[  674.560296] dfc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[  674.568474] dfe0: 00000000 00000000 00000000 00000000 00000013
00000000 00000000 00000000
[  674.576643] Backtrace:
[  674.579129] [<800933d4>] (put_page) from [<80433fe4>]
(skb_release_data+0x6c/0xcc)
[  674.586711] [<80433f78>] (skb_release_data) from [<8043406c>]
(skb_release_all+0x28/0x2c)
[  674.594881]  r7:96309010 r6:96308520 r5:96309010 r4:973d5000
[  674.600599] [<80434044>] (skb_release_all) from [<8043413c>]
(consume_skb+0x28/0x5c)
[  674.608338]  r4:973d5000 r3:00000001
[  674.611961] [<80434114>] (consume_skb) from [<80441c08>]
(__dev_kfree_skb_any+0x44/0x48)
[  674.620045]  r4:963363d0 r3:40000113
[  674.623891] [<80441bc4>] (__dev_kfree_skb_any) from [<7f10ca70>]
(r8712_free_recvframe+0x2c/0x94 [r8712u])
[  674.633827] [<7f10ca44>] (r8712_free_recvframe [r8712u]) from
[<7f10d3f8>] (recv_func+0x98/0x6f0 [r8712u])
[  674.643477]  r8:00002f17 r7:96309010 r6:00000000 r5:963363d0
r4:96308520 r3:00000000
[  674.651563] [<7f10d360>] (recv_func [r8712u]) from [<7f10eb84>]
(r8712_recv_entry+0x34/0x78 [r8712u])
[  674.660780]  r10:84d6cc00 r9:0000fff8 r8:00002f17 r7:00002f80
r6:9630a520 r5:963363d0
[  674.668666]  r4:96308520
[  674.671495] [<7f10eb50>] (r8712_recv_entry [r8712u]) from
[<7f10c65c>] (recv_tasklet+0x1b0/0x324 [r8712u])
[  674.681145]  r6:00000018 r5:84dc7626 r4:963363d0 r3:000000d2
[  674.687002] [<7f10c4ac>] (recv_tasklet [r8712u]) from [<8001fbbc>]
(tasklet_hi_action+0x80/0xdc)
[  674.695785]  r10:40000000 r9:8093f840 r8:96a32900 r7:00000000
r6:8093f820 r5:808f458c
[  674.703670]  r4:96309094
[  674.706228] [<8001fb3c>] (tasklet_hi_action) from [<8001ffc0>]
(__do_softirq+0x128/0x290)
[  674.714399]  r8:8093f840 r7:960fc000 r6:00000102 r5:00000000
r4:00000000 r3:0000833e
[  674.722205] [<8001fe98>] (__do_softirq) from [<80020474>]
(irq_exit+0xc4/0x118)
[  674.729509]  r10:00000000 r9:8003555c r8:00000000 r7:00000000
r6:00000000 r5:80920c94
[  674.737392]  r4:00000000
[  674.739968] [<800203b0>] (irq_exit) from [<80057298>]
(__handle_domain_irq+0x80/0xe0)
[  674.747793]  r4:00000000 r3:00000000
[  674.751406] [<80057218>] (__handle_domain_irq) from [<800081e4>]
(asm_do_IRQ+0x24/0x28)
[  674.759404]  r8:972ba1e0 r7:960fde54 r6:f200b200 r5:60000013
r4:8054e760 r3:960fde20
[  674.767228] [<800081c0>] (asm_do_IRQ) from [<800127f8>] (__irq_svc+0x38/0xb0)
[  674.774361] Exception stack(0x960fde20 to 0x960fde68)
[  674.779421] de20: 8054e75c 00000001 962cdee0 00000000 808f6668
969021e0 97051140 00000000
[  674.787600] de40: 972ba1e0 8003555c 00000000 960fde7c 960fde58
960fde68 8004b37c 8054e760
[  674.795771] de60: 60000013 ffffffff
[  674.799294] [<8054e730>] (_raw_spin_unlock_irq) from [<8003e738>]
(finish_task_switch+0x6c/0x108)
[  674.808157]  r4:808f6668 r3:00000000
[  674.811772] [<8003e6cc>] (finish_task_switch) from [<80549748>]
(__schedule+0x1fc/0x548)
[  674.819856]  r7:972ba1e0 r6:808f6668 r5:962cdee0 r4:97239140
[  674.825572] [<8054954c>] (__schedule) from [<80549ad8>] (schedule+0x44/0x9c)
[  674.832615]  r8:00000008 r7:808f5864 r6:808f5834 r5:808f5834
r4:960fc000 r3:960fded8
[  674.840438] [<80549a94>] (schedule) from [<80035590>]
(worker_thread+0xc4/0x4d0)
[  674.847829]  r4:971e55a0 r3:962cdee0
[  674.851442] [<800354cc>] (worker_thread) from [<8003a080>]
(kthread+0xe0/0x100)
[  674.858747]  r10:00000000 r9:00000000 r8:00000000 r7:800354cc
r6:971e55a0 r5:972c4940
[  674.866630]  r4:00000000
[  674.869192] [<80039fa0>] (kthread) from [<8000e8f0>]
(ret_from_fork+0x14/0x24)
[  674.876409]  r7:00000000 r6:00000000 r5:80039fa0 r4:972c4940
[  674.882121] Code: 8009272c e1a0c00d e92dd800 e24cb004 (e5902000)
[  674.888596] ---[ end trace 8b18691702087335 ]---
[  674.893371] Kernel panic - not syncing: Fatal exception in interrupt
[  674.899744] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

The offsets are a little different, I guess because of the added
prints, and debugging features I enabled in the kernel. One thing I
notice is that the skb at 0x973d5000 gets reused a couple of times
before the crash. Also, this time the pointer being dereferenced is
NULL (0x1).

Haggai

Re: kernel page fault in r8712u

[Larry Finger]

[-- Attachment #1: Type: text/plain, Size: 10869 bytes --]

On 05/18/2015 01:38 PM, Haggai Eran wrote:
> On 18 May 2015 at 18:31, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> On 05/17/2015 02:22 PM, Haggai Eran wrote:
>>>
>>> I added some debugging prints, trying to see more details about the
>>> packet that fails the r8712_validate_recv_frame. I noticed I'm getting
>>> many packets where recv_decache returns _FAIL. However, the last two
>>> packets before the crash fail for different reasons. The first has the
>>> ver field set to 3 (instead of zero). The second (the one that get's
>>> freed and cause the crash apparently) has an unknown type (12). If I'm
>>> not mistaken, 12 = WIFI_CTRL_TYPE | WIFI_DATA_TYPE. Is that possible?
>>>
>>> It could be that the packet headers are garbled though.
>>
>>
>> I think the headers are garbled. Did you log the address of the skb at
>> precvframe->u.hdr.pkt in r8712_free_recvframe() or orig_prframe->u.hdr.pct
>> in recv_func().
>
> I added prints of the skb pointer in every call to recv_func. Here are
> the results:
>
> ...
> [  674.111771] recv_func: pcontext = 96335820, prframe->u.hdr.pkt = 9729fb40
> [  674.118782] recv_func: pcontext = 963359b8, prframe->u.hdr.pkt = 9729f6c0
> [  674.125777] recv_func: pcontext = 96335930, prframe->u.hdr.pkt = 9729f780
> [  674.132769] recv_func: pcontext = 963358a8, prframe->u.hdr.pkt = 973d56c0
> [  674.139753] recv_func: pcontext = 96335d70, prframe->u.hdr.pkt = 973d5000
> [  674.146922] recv_func: pcontext = 963361b0, prframe->u.hdr.pkt = 973d5000
> [  674.153961] recv_func: pcontext = 963360a0, prframe->u.hdr.pkt = 973d5000
> [  674.161023] recv_func: pcontext = 96336128, prframe->u.hdr.pkt = 973d5000
> [  674.168186] recv_func: pcontext = 96336018, prframe->u.hdr.pkt = 973d5000
> [  674.175231] recv_func: pcontext = 96335f90, prframe->u.hdr.pkt = 973d5000
> [  674.182141] r8712_validate_recv_frame: ver = 1
> [  674.186814] recv_func: pcontext = 96335f08, prframe->u.hdr.pkt = 973d5000
> [  674.193811] r8712_validate_recv_frame: ver = 1
> [  674.198530] recv_func: pcontext = 963363d0, prframe->u.hdr.pkt = 973d5000
> [  674.205434] r8712_validate_recv_frame: ver = 3
> [  674.210018] Unable to handle kernel NULL pointer dereference at
> virtual address 00000001
> [  674.218209] pgd = 80004000
> [  674.221025] [00000001] *pgd=00000000
> [  674.224752] Internal error: Oops: 5 [#1] ARM
> [  674.229028] Modules linked in: rfcomm cfg80211 r8712u(C) btusb
> bluetooth bcm2708_rng
> [  674.236857] CPU: 0 PID: 530 Comm: kworker/0:1 Tainted: G        WC
>      4.0.3 #1
> [  674.244247] Hardware name: BCM2708
> [  674.247663] task: 962cdee0 ti: 960fc000 task.ti: 960fc000
> [  674.253082] PC is at put_page+0xc/0x68
> [  674.256853] LR is at skb_release_data+0x6c/0xcc
> [  674.261388] pc : [<800933e0>]    lr : [<80433fe4>]    psr: 20000113
> [  674.261388] sp : 960fdc18  ip : 960fdc28  fp : 960fdc24
> [  674.272856] r10: 84d6cc00  r9 : 0000fff8  r8 : 00002f17
> [  674.278079] r7 : 973d5000  r6 : 84dc7620  r5 : 84dc7620  r4 : 00000000
> [  674.284602] r3 : 00000037  r2 : 00000000  r1 : 00000001  r0 : 00000001
> [  674.291127] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
> Segment kernel
> [  674.298432] Control: 00c5387d  Table: 168a4008  DAC: 00000015
> [  674.304179] Process kworker/0:1 (pid: 530, stack limit = 0x960fc188)
> [  674.310532] Stack: (0x960fdc18 to 0x960fe000)
> [  674.314893] dc00:
>      960fdc44 960fdc28
> [  674.323076] dc20: 80433fe4 800933e0 973d5000 96309010 96308520
> 96309010 960fdc5c 960fdc48
> [  674.331257] dc40: 8043406c 80433f84 00000001 973d5000 960fdc74
> 960fdc60 8043413c 80434050
> [  674.339437] dc60: 40000113 963363d0 960fdc84 960fdc78 80441c08
> 80434120 960fdcac 960fdc88
> [  674.347618] dc80: 7f10ca70 80441bd0 00000000 96308520 963363d0
> 00000000 96309010 00002f17
> [  674.355798] dca0: 960fdce4 960fdcb0 7f10d3f8 7f10ca50 960fdcd4
> 960fdcc0 80439aac 96308520
> [  674.363978] dcc0: 963363d0 9630a520 00002f80 00002f17 0000fff8
> 84d6cc00 960fdd04 960fdce8
> [  674.372157] dce0: 7f10eb84 7f10d36c 000000d2 963363d0 84dc7626
> 00000018 960fdd54 960fdd08
> [  674.380338] dd00: 7f10c65c 7f10eb5c 96308ff0 963090d4 9729f840
> 9630b520 96309010 973d5000
> [  674.388518] dd20: ffff2f00 00000002 808f4590 96309094 808f458c
> 8093f820 00000000 96a32900
> [  674.396698] dd40: 8093f840 40000000 960fdd7c 960fdd58 8001fbbc
> 7f10c4b8 0000833e 00000000
> [  674.404879] dd60: 00000000 00000102 960fc000 8093f840 960fddcc
> 960fdd80 8001ffc0 8001fb48
> [  674.413058] dd80: 8054e348 80052428 00000001 00000001 04208060
> 0001b61a 00000009 960fc000
> [  674.421237] dda0: 00000000 00000000 80920c94 00000000 00000000
> 00000000 8003555c 00000000
> [  674.429416] ddc0: 960fdde4 960fddd0 80020474 8001fea4 00000000
> 00000000 960fde0c 960fdde8
> [  674.437598] dde0: 80057298 800203bc 960fde20 8054e760 60000013
> f200b200 960fde54 972ba1e0
> [  674.445777] de00: 960fde1c 960fde10 800081e4 80057224 960fde7c
> 960fde20 800127f8 800081cc
> [  674.453957] de20: 8054e75c 00000001 962cdee0 00000000 808f6668
> 969021e0 97051140 00000000
> [  674.462140] de40: 972ba1e0 8003555c 00000000 960fde7c 960fde58
> 960fde68 8004b37c 8054e760
> [  674.470319] de60: 60000013 ffffffff 00000000 808f6668 960fdeac
> 960fde80 8003e738 8054e73c
> [  674.478499] de80: 00000001 00000000 8003e6cc 960fde98 97239140
> 962cdee0 808f6668 972ba1e0
> [  674.486679] dea0: 960fded4 960fdeb0 80549748 8003e6d8 960fded8
> 960fc000 808f5834 808f5834
> [  674.494860] dec0: 808f5864 00000008 960fdeec 960fded8 80549ad8
> 80549558 962cdee0 971e55a0
> [  674.503039] dee0: 960fdf24 960fdef0 80035590 80549aa0 972c4940
> 971e55a0 800354cc 00000000
> [  674.511220] df00: 972c4940 971e55a0 800354cc 00000000 00000000
> 00000000 960fdfac 960fdf28
> [  674.519401] df20: 8003a080 800354d8 00000000 00000000 960fdf4c
> 971e55a0 00000000 00000001
> [  674.527581] df40: dead4ead ffffffff ffffffff 8093fd70 00000000
> 00000000 80646d2c 960fdf5c
> [  674.535759] df60: 960fdf5c 00000000 00000001 dead4ead ffffffff
> ffffffff 8093fd70 00000000
> [  674.543939] df80: 00000000 80646d2c 960fdf88 960fdf88 972c4940
> 80039fa0 00000000 00000000
> [  674.552118] dfa0: 00000000 960fdfb0 8000e8f0 80039fac 00000000
> 00000000 00000000 00000000
> [  674.560296] dfc0: 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000
> [  674.568474] dfe0: 00000000 00000000 00000000 00000000 00000013
> 00000000 00000000 00000000
> [  674.576643] Backtrace:
> [  674.579129] [<800933d4>] (put_page) from [<80433fe4>]
> (skb_release_data+0x6c/0xcc)
> [  674.586711] [<80433f78>] (skb_release_data) from [<8043406c>]
> (skb_release_all+0x28/0x2c)
> [  674.594881]  r7:96309010 r6:96308520 r5:96309010 r4:973d5000
> [  674.600599] [<80434044>] (skb_release_all) from [<8043413c>]
> (consume_skb+0x28/0x5c)
> [  674.608338]  r4:973d5000 r3:00000001
> [  674.611961] [<80434114>] (consume_skb) from [<80441c08>]
> (__dev_kfree_skb_any+0x44/0x48)
> [  674.620045]  r4:963363d0 r3:40000113
> [  674.623891] [<80441bc4>] (__dev_kfree_skb_any) from [<7f10ca70>]
> (r8712_free_recvframe+0x2c/0x94 [r8712u])
> [  674.633827] [<7f10ca44>] (r8712_free_recvframe [r8712u]) from
> [<7f10d3f8>] (recv_func+0x98/0x6f0 [r8712u])
> [  674.643477]  r8:00002f17 r7:96309010 r6:00000000 r5:963363d0
> r4:96308520 r3:00000000
> [  674.651563] [<7f10d360>] (recv_func [r8712u]) from [<7f10eb84>]
> (r8712_recv_entry+0x34/0x78 [r8712u])
> [  674.660780]  r10:84d6cc00 r9:0000fff8 r8:00002f17 r7:00002f80
> r6:9630a520 r5:963363d0
> [  674.668666]  r4:96308520
> [  674.671495] [<7f10eb50>] (r8712_recv_entry [r8712u]) from
> [<7f10c65c>] (recv_tasklet+0x1b0/0x324 [r8712u])
> [  674.681145]  r6:00000018 r5:84dc7626 r4:963363d0 r3:000000d2
> [  674.687002] [<7f10c4ac>] (recv_tasklet [r8712u]) from [<8001fbbc>]
> (tasklet_hi_action+0x80/0xdc)
> [  674.695785]  r10:40000000 r9:8093f840 r8:96a32900 r7:00000000
> r6:8093f820 r5:808f458c
> [  674.703670]  r4:96309094
> [  674.706228] [<8001fb3c>] (tasklet_hi_action) from [<8001ffc0>]
> (__do_softirq+0x128/0x290)
> [  674.714399]  r8:8093f840 r7:960fc000 r6:00000102 r5:00000000
> r4:00000000 r3:0000833e
> [  674.722205] [<8001fe98>] (__do_softirq) from [<80020474>]
> (irq_exit+0xc4/0x118)
> [  674.729509]  r10:00000000 r9:8003555c r8:00000000 r7:00000000
> r6:00000000 r5:80920c94
> [  674.737392]  r4:00000000
> [  674.739968] [<800203b0>] (irq_exit) from [<80057298>]
> (__handle_domain_irq+0x80/0xe0)
> [  674.747793]  r4:00000000 r3:00000000
> [  674.751406] [<80057218>] (__handle_domain_irq) from [<800081e4>]
> (asm_do_IRQ+0x24/0x28)
> [  674.759404]  r8:972ba1e0 r7:960fde54 r6:f200b200 r5:60000013
> r4:8054e760 r3:960fde20
> [  674.767228] [<800081c0>] (asm_do_IRQ) from [<800127f8>] (__irq_svc+0x38/0xb0)
> [  674.774361] Exception stack(0x960fde20 to 0x960fde68)
> [  674.779421] de20: 8054e75c 00000001 962cdee0 00000000 808f6668
> 969021e0 97051140 00000000
> [  674.787600] de40: 972ba1e0 8003555c 00000000 960fde7c 960fde58
> 960fde68 8004b37c 8054e760
> [  674.795771] de60: 60000013 ffffffff
> [  674.799294] [<8054e730>] (_raw_spin_unlock_irq) from [<8003e738>]
> (finish_task_switch+0x6c/0x108)
> [  674.808157]  r4:808f6668 r3:00000000
> [  674.811772] [<8003e6cc>] (finish_task_switch) from [<80549748>]
> (__schedule+0x1fc/0x548)
> [  674.819856]  r7:972ba1e0 r6:808f6668 r5:962cdee0 r4:97239140
> [  674.825572] [<8054954c>] (__schedule) from [<80549ad8>] (schedule+0x44/0x9c)
> [  674.832615]  r8:00000008 r7:808f5864 r6:808f5834 r5:808f5834
> r4:960fc000 r3:960fded8
> [  674.840438] [<80549a94>] (schedule) from [<80035590>]
> (worker_thread+0xc4/0x4d0)
> [  674.847829]  r4:971e55a0 r3:962cdee0
> [  674.851442] [<800354cc>] (worker_thread) from [<8003a080>]
> (kthread+0xe0/0x100)
> [  674.858747]  r10:00000000 r9:00000000 r8:00000000 r7:800354cc
> r6:971e55a0 r5:972c4940
> [  674.866630]  r4:00000000
> [  674.869192] [<80039fa0>] (kthread) from [<8000e8f0>]
> (ret_from_fork+0x14/0x24)
> [  674.876409]  r7:00000000 r6:00000000 r5:80039fa0 r4:972c4940
> [  674.882121] Code: 8009272c e1a0c00d e92dd800 e24cb004 (e5902000)
> [  674.888596] ---[ end trace 8b18691702087335 ]---
> [  674.893371] Kernel panic - not syncing: Fatal exception in interrupt
> [  674.899744] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
>
> The offsets are a little different, I guess because of the added
> prints, and debugging features I enabled in the kernel. One thing I
> notice is that the skb at 0x973d5000 gets reused a couple of times
> before the crash. Also, this time the pointer being dereferenced is
> NULL (0x1).

OK, I will have to search further upstream to see how a faulty skb was provided.

I have been testing r8712u on my x86_64 system with no difficulty.

I checked the driver with Smatch and found a couple of array problems. These 
likely won't be the problem, but try the attached patches anyway.

Larry


[-- Attachment #2: 0001-staging-rtl8712-Fix-two-Smatch-errors-in-rtl8712_xmi.patch --]
[-- Type: text/x-patch, Size: 1023 bytes --]

>From 54e0893af88ab802fa1cb4e5a826d89c16dfffbd Mon Sep 17 00:00:00 2001
From: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon, 18 May 2015 23:43:46 -0500
Subject: [PATCH 1/2] staging: rtl8712: Fix two Smatch errors in rtl8712_xmit.h

Smatch reports the following errors:

drivers/staging/rtl8712/rtl871x_xmit.c:971 alloc_hwxmits() error: buffer overflow 'hwxmits' 4 <= 4
drivers/staging/rtl8712/rtl871x_xmit.c:972 alloc_hwxmits() error: buffer overflow 'hwxmits' 4 <= 4

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
 drivers/staging/rtl8712/rtl8712_xmit.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/rtl8712_xmit.h b/drivers/staging/rtl8712/rtl8712_xmit.h
index b50e7a1..a66356d 100644
--- a/drivers/staging/rtl8712/rtl8712_xmit.h
+++ b/drivers/staging/rtl8712/rtl8712_xmit.h
@@ -26,7 +26,7 @@
 #ifndef _RTL8712_XMIT_H_
 #define _RTL8712_XMIT_H_
 
-#define HWXMIT_ENTRY	4
+#define HWXMIT_ENTRY	5
 
 #define VO_QUEUE_INX	0
 #define VI_QUEUE_INX	1
-- 
2.1.4


[-- Attachment #3: 0002-staging-rtl8712-Fix-Smatch-error-in-rtl8712_efuse.c.patch --]
[-- Type: text/x-patch, Size: 1085 bytes --]

>From 7729f6f1c7c6cb49b77b42e89e0e10be3121079b Mon Sep 17 00:00:00 2001
From: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon, 18 May 2015 23:47:22 -0500
Subject: [PATCH 2/2] staging: rtl8712: Fix Smatch error in rtl8712_efuse.c

Smatch reports the following error:

drivers/staging/rtl8712/rtl8712_efuse.c:545 r8712_efuse_map_write() error: buffer overflow 'pktdata' 8 <= 8

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
 drivers/staging/rtl8712/rtl8712_efuse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/rtl8712_efuse.c b/drivers/staging/rtl8712/rtl8712_efuse.c
index d957169..dfe6cd7 100644
--- a/drivers/staging/rtl8712/rtl8712_efuse.c
+++ b/drivers/staging/rtl8712/rtl8712_efuse.c
@@ -495,7 +495,7 @@ u8 r8712_efuse_map_write(struct _adapter *padapter, u16 addr, u16 cnts,
 			 u8 *data)
 {
 	u8 offset, word_en, empty;
-	u8 pktdata[PGPKT_DATA_SIZE], newdata[PGPKT_DATA_SIZE];
+	u8 pktdata[PGPKT_DATA_SIZE + 1], newdata[PGPKT_DATA_SIZE + 1];
 	int i, j, idx;
 
 	if ((addr + cnts) > EFUSE_MAP_MAX_SIZE)
-- 
2.1.4

Re: kernel page fault in r8712u

[Haggai Eran]

On 19 May 2015 at 07:52, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> OK, I will have to search further upstream to see how a faulty skb was
> provided.
>
> I have been testing r8712u on my x86_64 system with no difficulty.
>
> I checked the driver with Smatch and found a couple of array problems. These
> likely won't be the problem, but try the attached patches anyway.

I found one place that might be the cause for the fault. The
recvbuf2recvframe function has a line copying memory between the
incoming pskb and a new allocated skb:

1065                 pkt_copy = netdev_alloc_skb(padapter->pnetdev, alloc_sz);
1066                 if (pkt_copy) {
1067                         precvframe->u.hdr.pkt = pkt_copy;
1068                         skb_reserve(pkt_copy, 4 - ((addr_t)(pkt_copy->data)
1069                                     % 4));
1070                         skb_reserve(pkt_copy, shift_sz);
1071                         memcpy(pkt_copy->data, pbuf, tmp_len);
1072                         precvframe->u.hdr.rx_head =
precvframe->u.hdr.rx_data =
1073                                  precvframe->u.hdr.rx_tail =
pkt_copy->data;
1074                         precvframe->u.hdr.rx_end = pkt_copy->data
+ alloc_sz;

I added a BUG_ON there in case the memcpy overflows
(BUG_ON((pkt_copy->end - pkt_copy->data) < tmp_len)) and it trigerred.
I'm not sure why does the overflow occur though.

Haggai

Re: kernel page fault in r8712u

[Haggai Eran]

On 19 May 2015 at 07:52, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> I checked the driver with Smatch and found a couple of array problems. These
> likely won't be the problem, but try the attached patches anyway.

I tried the patches. The first one prevents the driver from working. I
think the smatch warning may be a false positive, because HWXMIT_ENTRY
is checked specifically for values 4 and 5 in an if statement.

The second patch doesn't hurt, but it didn't solve the issue.