* locks inside receive_buf
@ 2011-03-30 12:21 Pavan Savoy
2011-03-31 10:25 ` Alan Cox
0 siblings, 1 reply; 10+ messages in thread
From: Pavan Savoy @ 2011-03-30 12:21 UTC (permalink / raw)
To: linux-kernel, alan
Hi,
Does holding a lock make any sense inside the line discipline's
ops->receive_buf?
I see the locks being held and released - during some calls like
flush_to_ldisc, which end up calling receive_buf....
and yes, I would like to have a lock because, there are other
functions in my ldisc driver executed in process context ...
Is there some hints as to what should be the do's and don'ts inside
the ldisc ops functions ? (say tty_wakeup ...)
regards,
Pavan
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: locks inside receive_buf
2011-03-30 12:21 locks inside receive_buf Pavan Savoy
@ 2011-03-31 10:25 ` Alan Cox
2011-03-31 11:18 ` Pavan Savoy
0 siblings, 1 reply; 10+ messages in thread
From: Alan Cox @ 2011-03-31 10:25 UTC (permalink / raw)
To: Pavan Savoy; +Cc: linux-kernel
On Wed, 30 Mar 2011 17:51:27 +0530
Pavan Savoy <pavan_savoy@sify.com> wrote:
> Hi,
>
> Does holding a lock make any sense inside the line discipline's
> ops->receive_buf?
> I see the locks being held and released - during some calls like
> flush_to_ldisc, which end up calling receive_buf....
>
>
> and yes, I would like to have a lock because, there are other
> functions in my ldisc driver executed in process context ...
> Is there some hints as to what should be the do's and don'ts inside
> the ldisc ops functions ? (say tty_wakeup ...)
It's not well documented no. Your ld->receive_buf is single threaded and
runs from a sleeping context (but please don't sleep too long)
The output path from user space will be in a sleeping context too, but
you can call the write method of the tty your driver is using from
interrupt context or holding a spinlock (eg from timers)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: locks inside receive_buf
2011-03-31 10:25 ` Alan Cox
@ 2011-03-31 11:18 ` Pavan Savoy
2011-03-31 14:33 ` Steven Rostedt
0 siblings, 1 reply; 10+ messages in thread
From: Pavan Savoy @ 2011-03-31 11:18 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
On Thu, Mar 31, 2011 at 3:55 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Wed, 30 Mar 2011 17:51:27 +0530
> Pavan Savoy <pavan_savoy@sify.com> wrote:
>
>> Hi,
>>
>> Does holding a lock make any sense inside the line discipline's
>> ops->receive_buf?
>> I see the locks being held and released - during some calls like
>> flush_to_ldisc, which end up calling receive_buf....
>>
>>
>> and yes, I would like to have a lock because, there are other
>> functions in my ldisc driver executed in process context ...
>> Is there some hints as to what should be the do's and don'ts inside
>> the ldisc ops functions ? (say tty_wakeup ...)
>
> It's not well documented no. Your ld->receive_buf is single threaded and
> runs from a sleeping context (but please don't sleep too long)
Alright, so I see the work gets into the default kthread queue I suppose...?
However, I am quite puzzled by this kind of OOPS (pasted below...)
Where I know the TTY called my receive_buf (which is st_tty_receive) -
which internally calls my parsing function st_int_recv() .....
I was just wondering, whether it is worth making this internal parsing
function a tasklet by itself ?
I kind of do lot of stuff inside the st_int_recv() - including doing a
tty->ops->write....
copy in and out of skb queues - So are all this long enough sleeps?
PC is at st_int_recv+0x2a0/0x354 [st_drv]
LR is at schedule+0x414/0x4e8
pc : [<bf000fc0>] lr : [<c04c3ff0>] psr: 80000013
sp : efc55ed0 ip : efc55dc0 fp : efc55f0c
r10: 00000008 r9 : eec4de60 r8 : 00000004
r7 : 00000000 r6 : 00000007 r5 : ee77bc8f r4 : ef0f3480
r3 : 00000000 r2 : 00000000 r1 : 00000020 r0 : 0000001f
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c53c7d Table: af3a004a DAC: 00000015
<snip...>
Backtrace:
[<bf000d20>] (st_int_recv+0x0/0x354 [st_drv]) from [<bf000170>]
(st_tty_receive+0x70/0x9c [st_drv])
[<bf000100>] (st_tty_receive+0x0/0x9c [st_drv]) from [<c02616b4>]
(flush_to_ldisc+0xfc/0x170)
r6:ef10e8f0 r5:ef10e8a4 r4:ef10e800
[<c02615b8>] (flush_to_ldisc+0x0/0x170) from [<c009bf30>]
(worker_thread+0x154/0x1e0)
[<c009bddc>] (worker_thread+0x0/0x1e0) from [<c009fce0>] (kthread+0x84/0x8c)
[<c009fc5c>] (kthread+0x0/0x8c) from [<c008d6bc>] (do_exit+0x0/0x5f0)
> The output path from user space will be in a sleeping context too, but
> you can call the write method of the tty your driver is using from
> interrupt context or holding a spinlock (eg from timers)
>
>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: locks inside receive_buf
2011-03-31 11:18 ` Pavan Savoy
@ 2011-03-31 14:33 ` Steven Rostedt
2011-04-01 7:12 ` Pavan Savoy
0 siblings, 1 reply; 10+ messages in thread
From: Steven Rostedt @ 2011-03-31 14:33 UTC (permalink / raw)
To: Pavan Savoy; +Cc: Alan Cox, linux-kernel
On Thu, Mar 31, 2011 at 04:48:29PM +0530, Pavan Savoy wrote:
>
> Alright, so I see the work gets into the default kthread queue I suppose...?
> However, I am quite puzzled by this kind of OOPS (pasted below...)
>
> Where I know the TTY called my receive_buf (which is st_tty_receive) -
> which internally calls my parsing function st_int_recv() .....
> I was just wondering, whether it is worth making this internal parsing
> function a tasklet by itself ?
>
> I kind of do lot of stuff inside the st_int_recv() - including doing a
> tty->ops->write....
> copy in and out of skb queues - So are all this long enough sleeps?
>
> PC is at st_int_recv+0x2a0/0x354 [st_drv]
> LR is at schedule+0x414/0x4e8
Um, what was the cause of the oops? You did not include that.
-- Steve
> pc : [<bf000fc0>] lr : [<c04c3ff0>] psr: 80000013
> sp : efc55ed0 ip : efc55dc0 fp : efc55f0c
> r10: 00000008 r9 : eec4de60 r8 : 00000004
> r7 : 00000000 r6 : 00000007 r5 : ee77bc8f r4 : ef0f3480
> r3 : 00000000 r2 : 00000000 r1 : 00000020 r0 : 0000001f
> Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 10c53c7d Table: af3a004a DAC: 00000015
>
> <snip...>
>
> Backtrace:
> [<bf000d20>] (st_int_recv+0x0/0x354 [st_drv]) from [<bf000170>]
> (st_tty_receive+0x70/0x9c [st_drv])
> [<bf000100>] (st_tty_receive+0x0/0x9c [st_drv]) from [<c02616b4>]
> (flush_to_ldisc+0xfc/0x170)
> r6:ef10e8f0 r5:ef10e8a4 r4:ef10e800
> [<c02615b8>] (flush_to_ldisc+0x0/0x170) from [<c009bf30>]
> (worker_thread+0x154/0x1e0)
> [<c009bddc>] (worker_thread+0x0/0x1e0) from [<c009fce0>] (kthread+0x84/0x8c)
> [<c009fc5c>] (kthread+0x0/0x8c) from [<c008d6bc>] (do_exit+0x0/0x5f0)
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: locks inside receive_buf
2011-03-31 14:33 ` Steven Rostedt
@ 2011-04-01 7:12 ` Pavan Savoy
2011-04-01 13:46 ` Steven Rostedt
0 siblings, 1 reply; 10+ messages in thread
From: Pavan Savoy @ 2011-04-01 7:12 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Alan Cox, linux-kernel
On Thu, Mar 31, 2011 at 8:03 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Thu, Mar 31, 2011 at 04:48:29PM +0530, Pavan Savoy wrote:
>>
>> Alright, so I see the work gets into the default kthread queue I suppose...?
>> However, I am quite puzzled by this kind of OOPS (pasted below...)
>>
>> Where I know the TTY called my receive_buf (which is st_tty_receive) -
>> which internally calls my parsing function st_int_recv() .....
>> I was just wondering, whether it is worth making this internal parsing
>> function a tasklet by itself ?
>>
>> I kind of do lot of stuff inside the st_int_recv() - including doing a
>> tty->ops->write....
>> copy in and out of skb queues - So are all this long enough sleeps?
>>
>> PC is at st_int_recv+0x2a0/0x354 [st_drv]
>> LR is at schedule+0x414/0x4e8
>
> Um, what was the cause of the oops? You did not include that.
How do I understand this ? a NULL pointer exception occurred in
function schedule?
Unable to handle kernel NULL pointer dereference at virtual address 0000001a
pgd = c0004000
[0000001a] *pgd=00000000
Internal error: Oops: 17 [#1] PREEMPT SMP
last sysfs file: /sys/devices/virtual/bluetooth/hci0/rfkill0/state
Modules linked in: tiwlan_drv test_drv(P) gps_drv(C) fm_drv(C)
btwilink st_drv [last unloaded: tiwlan_drv]
CPU: 0 Tainted: P WC (2.6.35.7-00242-ga4e3b34-dirty #1)
PC is at st_int_recv+0x2a0/0x354 [st_drv]
LR is at schedule+0x414/0x4e8
pc : [<bf000fc0>] lr : [<c04c3ff0>] psr: 80000013
sp : efc55ed0 ip : efc55dc0 fp : efc55f0c
r10: 00000008 r9 : eec4de60 r8 : 00000004
r7 : 00000000 r6 : 00000007 r5 : ee77bc8f r4 : ef0f3480
r3 : 00000000 r2 : 00000000 r1 : 00000020 r0 : 0000001f
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c53c7d Table: af3a004a DAC: 00000015
LR: 0xc04c3f70:
3f70 e5973160 e0223003 e1b03423 0a000001 e1a00007 ebee318c e59f3130 e597216c
3f90 e593316c e1520003 0a000001 e1a00007 ebee2997 e5970024 e1a01007 e2800103
3fb0 ebee31f8 e59530d4 e1a00005 e3530000 058530d8 05848460 e5951004 e5992004
3fd0 ebee0877 e1a01000 e59f50c4 e5963014 e59f40c0 e7950103 e0840000 ebeef300
3ff0 e5968014 e7953108 e0844003 ea000001 e1a00004 eb000842 e5943484 e3530000
4010 0a00000e e1a00004 eb000982 e5943454 e593302c e5933024 e3530000 e1a05000
4030 0a000001 e1a00004 e12fff33 e1a00004 e1a01005 eb000846 e3a03000 e5843484
4050 e596300c e5933014 e3530000 ba000004 eb0009fe e3500000 b5945454 b285ad06
SP: 0xefc55e50:
ADDRCONF(NETDEV_UP): tiwlan0: link is not ready
5e50 00000000 00000000 60000013 30203430 34302065 20313020 ffffffff efc55ebc
5e70 00000007 00000000 efc55f0c efc55e88 c0045c6c c0045484 0000001f 00000020
5e90 00000000 00000000 ef0f3480 ee77bc8f 00000007 00000000 00000004 eec4de60
5eb0 00000008 efc55f0c efc55dc0 efc55ed0 c04c3ff0 bf000fc0 80000013 ffffffff
5ed0 eec4de60 ef0f34f4 ef0f34e0 ef0f3508 c04c3764 00000007 ee77bc8f ef10e800
5ef0 00000007 60000013 eec4de60 ef10e8c4 efc55f3c efc55f10 bf000170 bf000d2c
5f10 00000001 ee77bc8f 00000007 00000000 efc55f3c ef10e800 ef10e8a4 ef10e8f0
5f30 efc55f74 efc55f40 c02616b4 bf00010c ee77bc8f ee77bd8f efc55f64 c1b5b7c0
IP: 0xefc55d40:
5d40 efc55d7c efc55d60 c004d424 c04c3750 c05bc74a 0000001a 00000017 00000000
5d60 efc55e88 00000000 00000113 00000008 efc55da4 efc55d80 c004d540 c004a5ec
5d80 efc55e88 efc3d5e0 0000001a efc55e88 00000000 00000017 efc55ddc efc55da8
5da0 c004d730 c004d4e0 c0044000 c06a6df4 efc55e04 00000017 c064cde8 0000001a
5dc0 efc55e88 00000004 00000113 00000008 efc55e84 efc55de0 c00454b4 c004d56c
5de0 00000003 0000001c 0000001f 0000001c eec4de60 c06623f8 efc55e1c efc55e08
5e00 c04c42d0 c04c3be8 00000002 00000001 efc55ea4 efc55e20 c008ae24 c04c429c
5e20 efc55f0c 00000004 c0216344 c04c3750 c05d2bf5 bf0021de bf0021e2 60000013
FP: 0xefc55e8c:
5e8c 00000020 00000000 00000000 ef0f3480 ee77bc8f 00000007 00000000 00000004
5eac eec4de60 00000008 efc55f0c efc55dc0 efc55ed0 c04c3ff0 bf000fc0 80000013
5ecc ffffffff eec4de60 ef0f34f4 ef0f34e0 ef0f3508 c04c3764 00000007 ee77bc8f
5eec ef10e800 00000007 60000013 eec4de60 ef10e8c4 efc55f3c efc55f10 bf000170
5f0c bf000d2c 00000001 ee77bc8f 00000007 00000000 efc55f3c ef10e800 ef10e8a4
5f2c ef10e8f0 efc55f74 efc55f40 c02616b4 bf00010c ee77bc8f ee77bd8f efc55f64
5f4c c1b5b7c0 efc54000 c02615b8 c1b5b7d0 c1b5b7c8 ef10e8c8 ef10e8c4 efc55fbc
5f6c efc55f78 c009bf30 c02615c4 efc55f8c 00000000 efc3d5e0 c00a00ac efc55f88
R4: 0xef0f3400:
3400 00000000 00000000 00000000 00000000 eec4de80 00000037 00000000 00000000
3420 00000000 ef0f3480 000a2b0f 0006000f 65642f01 74742f76 00314f79 00000000
3440 00000000 00000000 00000000 00000000 00000100 002dc6c0 00000000 00000000
3460 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3480 00000000 ef10e800 00000000 00000000 00000000 00000000 00000000 00000000
34a0 00000000 00000000 00000000 00000000 00000000 bf018008 00000000 00000000
34c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000004
34e0 ef0f34e0 ef0f34e0 00000000 00000000 00000000 ef0f34f4 ef0f34f4 00000000
R5: 0xee77bc0f:
bc0c 0000007a 00000100 0000007a 0000007a 00000000 00000000 00000000 00000000
bc2c 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bc4c 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bc6c 00000000 00000000 00000000 f0011000 01040e04 04000c52 1901050e 3002000c
bc8c 04323033 0301040e 0000000c 00000000 00000000 00000000 00000000 00000000
bcac 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bccc 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bcec 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bd0c 040503f0 5601040e 0e04000c 0c550105 00000000 00000000 00000000 00000000
R9: 0xeec4dde0:
dde0 006d696b 00200200 00000002 00000000 00000000 00000000 00000000 00000000
de00 6d726966 65726177 00000000 00000000 eec4de10 eec4de10 eec4de18 eec4de18
de20 eec4de20 eec4de20 00000000 0000b918 00000000 00000000 00000000 00000000
de40 eec4de40 eec4de40 00000000 0000b8f0 00000000 00000000 00000000 00000000
de60 bf002f44 00000002 00000002 00000000 00000000 00000000 00000000 00000000
de80 eec4de80 eec4de80 00000000 000ddbc8 00000000 00000000 00000000 00000000
dea0 00000001 00000001 00000000 00000000 ef183c0c ef183c0c efc72338 efc72338
dec0 eec4dec0 eec4dec0 00000000 000ea5c0 00000000 00000000 00000000 00000000
Process events/0 (pid: 7, stack limit = 0xefc542f8)
Stack: (0xefc55ed0 to 0xefc56000)
5ec0: eec4de60 ef0f34f4 ef0f34e0 ef0f3508
5ee0: c04c3764 00000007 ee77bc8f ef10e800 00000007 60000013 eec4de60 ef10e8c4
5f00: efc55f3c efc55f10 bf000170 bf000d2c 00000001 ee77bc8f 00000007 00000000
5f20: efc55f3c ef10e800 ef10e8a4 ef10e8f0 efc55f74 efc55f40 c02616b4 bf00010c
5f40: ee77bc8f ee77bd8f efc55f64 c1b5b7c0 efc54000 c02615b8 c1b5b7d0 c1b5b7c8
5f60: ef10e8c8 ef10e8c4 efc55fbc efc55f78 c009bf30 c02615c4 efc55f8c 00000000
5f80: efc3d5e0 c00a00ac efc55f88 efc55f88 c007d330 efc41f10 efc55fc4 c009bddc
5fa0: c1b5b7c0 00000000 00000000 00000000 efc55ff4 efc55fc0 c009fce0 c009bde8
5fc0: 00000000 00000000 00000000 00000000 efc55fd0 efc55fd0 efc41f10 c009fc5c
5fe0: c008d6bc 00000013 00000000 efc55ff8 c008d6bc c009fc68 00000000 00000000
Backtrace:
[<bf000d20>] (st_int_recv+0x0/0x354 [st_drv]) from [<bf000170>]
(st_tty_receive+0x70/0x9c [st_drv])
[<bf000100>] (st_tty_receive+0x0/0x9c [st_drv]) from [<c02616b4>]
(flush_to_ldisc+0xfc/0x170)
r6:ef10e8f0 r5:ef10e8a4 r4:ef10e800
[<c02615b8>] (flush_to_ldisc+0x0/0x170) from [<c009bf30>]
(worker_thread+0x154/0x1e0)
[<c009bddc>] (worker_thread+0x0/0x1e0) from [<c009fce0>] (kthread+0x84/0x8c)
[<c009fc5c>] (kthread+0x0/0x8c) from [<c008d6bc>] (do_exit+0x0/0x5f0)
r7:00000013 r6:c008d6bc r5:c009fc5c r4:efc41f10
Code: e288a004 e3a01020 e3a02000 e794310a (e1d301ba)
---[ end trace 34f2f99c655b5328 ]---
Kernel panic - not syncing: Fatal exception
> -- Steve
>
>> pc : [<bf000fc0>] lr : [<c04c3ff0>] psr: 80000013
>> sp : efc55ed0 ip : efc55dc0 fp : efc55f0c
>> r10: 00000008 r9 : eec4de60 r8 : 00000004
>> r7 : 00000000 r6 : 00000007 r5 : ee77bc8f r4 : ef0f3480
>> r3 : 00000000 r2 : 00000000 r1 : 00000020 r0 : 0000001f
>> Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
>> Control: 10c53c7d Table: af3a004a DAC: 00000015
>>
>> <snip...>
>>
>> Backtrace:
>> [<bf000d20>] (st_int_recv+0x0/0x354 [st_drv]) from [<bf000170>]
>> (st_tty_receive+0x70/0x9c [st_drv])
>> [<bf000100>] (st_tty_receive+0x0/0x9c [st_drv]) from [<c02616b4>]
>> (flush_to_ldisc+0xfc/0x170)
>> r6:ef10e8f0 r5:ef10e8a4 r4:ef10e800
>> [<c02615b8>] (flush_to_ldisc+0x0/0x170) from [<c009bf30>]
>> (worker_thread+0x154/0x1e0)
>> [<c009bddc>] (worker_thread+0x0/0x1e0) from [<c009fce0>] (kthread+0x84/0x8c)
>> [<c009fc5c>] (kthread+0x0/0x8c) from [<c008d6bc>] (do_exit+0x0/0x5f0)
>>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: locks inside receive_buf
2011-04-01 7:12 ` Pavan Savoy
@ 2011-04-01 13:46 ` Steven Rostedt
2011-04-05 11:13 ` Pavan Savoy
0 siblings, 1 reply; 10+ messages in thread
From: Steven Rostedt @ 2011-04-01 13:46 UTC (permalink / raw)
To: Pavan Savoy; +Cc: Alan Cox, linux-kernel
On Fri, 2011-04-01 at 12:42 +0530, Pavan Savoy wrote:
> On Thu, Mar 31, 2011 at 8:03 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Thu, Mar 31, 2011 at 04:48:29PM +0530, Pavan Savoy wrote:
> >>
> >> Alright, so I see the work gets into the default kthread queue I suppose...?
> >> However, I am quite puzzled by this kind of OOPS (pasted below...)
> >>
> >> Where I know the TTY called my receive_buf (which is st_tty_receive) -
> >> which internally calls my parsing function st_int_recv() .....
> >> I was just wondering, whether it is worth making this internal parsing
> >> function a tasklet by itself ?
> >>
> >> I kind of do lot of stuff inside the st_int_recv() - including doing a
> >> tty->ops->write....
> >> copy in and out of skb queues - So are all this long enough sleeps?
> >>
> >> PC is at st_int_recv+0x2a0/0x354 [st_drv]
> >> LR is at schedule+0x414/0x4e8
> >
> > Um, what was the cause of the oops? You did not include that.
>
> How do I understand this ? a NULL pointer exception occurred in
> function schedule?
It did not happen in the scheduler, it happened in st_int_recv.
>
> Unable to handle kernel NULL pointer dereference at virtual address 0000001a
> pgd = c0004000
> [0000001a] *pgd=00000000
> Internal error: Oops: 17 [#1] PREEMPT SMP
> last sysfs file: /sys/devices/virtual/bluetooth/hci0/rfkill0/state
> Modules linked in: tiwlan_drv test_drv(P) gps_drv(C) fm_drv(C)
> btwilink st_drv [last unloaded: tiwlan_drv]
> CPU: 0 Tainted: P WC (2.6.35.7-00242-ga4e3b34-dirty #1)
> PC is at st_int_recv+0x2a0/0x354 [st_drv]
The program counter is at st_int_recv+0x2a0 when this happened, so that
function is probably where you accessed some structure that was not
initialized.
foo->bar
if foo is NULL, you'll get that error.
> LR is at schedule+0x414/0x4e8
LR is Link Register, or where this function was called from.
Now why is the scheduler calling your function, I have no idea.
> pc : [<bf000fc0>] lr : [<c04c3ff0>] psr: 80000013
> sp : efc55ed0 ip : efc55dc0 fp : efc55f0c
> r10: 00000008 r9 : eec4de60 r8 : 00000004
> r7 : 00000000 r6 : 00000007 r5 : ee77bc8f r4 : ef0f3480
> r3 : 00000000 r2 : 00000000 r1 : 00000020 r0 : 0000001f
> Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 10c53c7d Table: af3a004a DAC: 00000015
>
[ snip ]
> Backtrace:
> [<bf000d20>] (st_int_recv+0x0/0x354 [st_drv]) from [<bf000170>]
> (st_tty_receive+0x70/0x9c [st_drv])
> [<bf000100>] (st_tty_receive+0x0/0x9c [st_drv]) from [<c02616b4>]
> (flush_to_ldisc+0xfc/0x170)
> r6:ef10e8f0 r5:ef10e8a4 r4:ef10e800
> [<c02615b8>] (flush_to_ldisc+0x0/0x170) from [<c009bf30>]
> (worker_thread+0x154/0x1e0)
> [<c009bddc>] (worker_thread+0x0/0x1e0) from [<c009fce0>] (kthread+0x84/0x8c)
> [<c009fc5c>] (kthread+0x0/0x8c) from [<c008d6bc>] (do_exit+0x0/0x5f0)
> r7:00000013 r6:c008d6bc r5:c009fc5c r4:efc41f10
> Code: e288a004 e3a01020 e3a02000 e794310a (e1d301ba)
> ---[ end trace 34f2f99c655b5328 ]---
> Kernel panic - not syncing: Fatal exception
The backtrace does not even show the scheduler, so that may just be due
to some other kind of corruption.
Looks like something is not right with the st_drv code.
-- Steve
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: locks inside receive_buf
2011-04-01 13:46 ` Steven Rostedt
@ 2011-04-05 11:13 ` Pavan Savoy
2011-04-05 13:04 ` Steven Rostedt
0 siblings, 1 reply; 10+ messages in thread
From: Pavan Savoy @ 2011-04-05 11:13 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Alan Cox, linux-kernel
On Fri, Apr 1, 2011 at 7:16 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 2011-04-01 at 12:42 +0530, Pavan Savoy wrote:
>> On Thu, Mar 31, 2011 at 8:03 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>> > On Thu, Mar 31, 2011 at 04:48:29PM +0530, Pavan Savoy wrote:
>> >>
>> >> Alright, so I see the work gets into the default kthread queue I suppose...?
>> >> However, I am quite puzzled by this kind of OOPS (pasted below...)
>> >>
>> >> Where I know the TTY called my receive_buf (which is st_tty_receive) -
>> >> which internally calls my parsing function st_int_recv() .....
>> >> I was just wondering, whether it is worth making this internal parsing
>> >> function a tasklet by itself ?
>> >>
>> >> I kind of do lot of stuff inside the st_int_recv() - including doing a
>> >> tty->ops->write....
>> >> copy in and out of skb queues - So are all this long enough sleeps?
>> >>
>> >> PC is at st_int_recv+0x2a0/0x354 [st_drv]
>> >> LR is at schedule+0x414/0x4e8
>> >
>> > Um, what was the cause of the oops? You did not include that.
>>
>> How do I understand this ? a NULL pointer exception occurred in
>> function schedule?
>
> It did not happen in the scheduler, it happened in st_int_recv.
>
>>
>> Unable to handle kernel NULL pointer dereference at virtual address 0000001a
>> pgd = c0004000
>> [0000001a] *pgd=00000000
>> Internal error: Oops: 17 [#1] PREEMPT SMP
>> last sysfs file: /sys/devices/virtual/bluetooth/hci0/rfkill0/state
>> Modules linked in: tiwlan_drv test_drv(P) gps_drv(C) fm_drv(C)
>> btwilink st_drv [last unloaded: tiwlan_drv]
>> CPU: 0 Tainted: P WC (2.6.35.7-00242-ga4e3b34-dirty #1)
>> PC is at st_int_recv+0x2a0/0x354 [st_drv]
>
> The program counter is at st_int_recv+0x2a0 when this happened, so that
> function is probably where you accessed some structure that was not
> initialized.
>
> foo->bar
>
> if foo is NULL, you'll get that error.
>
>> LR is at schedule+0x414/0x4e8
>
> LR is Link Register, or where this function was called from.
>
> Now why is the scheduler calling your function, I have no idea.
Well this is exactly the problem I have and hence the question
regarding sleep in tty's receive_buf function.
the function called st_recv or st_int_recv() is basically my line
discipline's receive_buf function - which happens like zillions of
times properly with tty->disc_data being populated with what I
need....
However on a corner case - when I perform some operation - which has
absolutely NO relation to TTY (at most may be console is using 1 uart)
- Everything breaks loose...
If I bump into a NULL pointer it is because the tty->disc_data is NULL ....
However my check for tty->disc_data being NULL also is fine - i.e when
I do get this error - my disc_data is NOT null ... But not sure what
(which data) is NULL ??
So now back to the question - What cannot I do inside tty's receive_buf ?
>> pc : [<bf000fc0>] lr : [<c04c3ff0>] psr: 80000013
>> sp : efc55ed0 ip : efc55dc0 fp : efc55f0c
>> r10: 00000008 r9 : eec4de60 r8 : 00000004
>> r7 : 00000000 r6 : 00000007 r5 : ee77bc8f r4 : ef0f3480
>> r3 : 00000000 r2 : 00000000 r1 : 00000020 r0 : 0000001f
>> Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
>> Control: 10c53c7d Table: af3a004a DAC: 00000015
>>
>
> [ snip ]
>
>> Backtrace:
>> [<bf000d20>] (st_int_recv+0x0/0x354 [st_drv]) from [<bf000170>]
>> (st_tty_receive+0x70/0x9c [st_drv])
>> [<bf000100>] (st_tty_receive+0x0/0x9c [st_drv]) from [<c02616b4>]
>> (flush_to_ldisc+0xfc/0x170)
>> r6:ef10e8f0 r5:ef10e8a4 r4:ef10e800
>> [<c02615b8>] (flush_to_ldisc+0x0/0x170) from [<c009bf30>]
>> (worker_thread+0x154/0x1e0)
>> [<c009bddc>] (worker_thread+0x0/0x1e0) from [<c009fce0>] (kthread+0x84/0x8c)
>> [<c009fc5c>] (kthread+0x0/0x8c) from [<c008d6bc>] (do_exit+0x0/0x5f0)
>> r7:00000013 r6:c008d6bc r5:c009fc5c r4:efc41f10
>> Code: e288a004 e3a01020 e3a02000 e794310a (e1d301ba)
>> ---[ end trace 34f2f99c655b5328 ]---
>> Kernel panic - not syncing: Fatal exception
>
> The backtrace does not even show the scheduler, so that may just be due
> to some other kind of corruption.
>
> Looks like something is not right with the st_drv code.
>
> -- Steve
>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: locks inside receive_buf
2011-04-05 11:13 ` Pavan Savoy
@ 2011-04-05 13:04 ` Steven Rostedt
2011-04-06 8:56 ` Pavan Savoy
0 siblings, 1 reply; 10+ messages in thread
From: Steven Rostedt @ 2011-04-05 13:04 UTC (permalink / raw)
To: Pavan Savoy; +Cc: Alan Cox, linux-kernel
On Tue, 2011-04-05 at 16:43 +0530, Pavan Savoy wrote:
> > The program counter is at st_int_recv+0x2a0 when this happened, so that
> > function is probably where you accessed some structure that was not
> > initialized.
> >
> > foo->bar
> >
> > if foo is NULL, you'll get that error.
> >
> >> LR is at schedule+0x414/0x4e8
> >
> > LR is Link Register, or where this function was called from.
> >
> > Now why is the scheduler calling your function, I have no idea.
>
> Well this is exactly the problem I have and hence the question
> regarding sleep in tty's receive_buf function.
>
> the function called st_recv or st_int_recv() is basically my line
> discipline's receive_buf function - which happens like zillions of
> times properly with tty->disc_data being populated with what I
> need....
>
> However on a corner case - when I perform some operation - which has
> absolutely NO relation to TTY (at most may be console is using 1 uart)
> - Everything breaks loose...
Well, if this corner case that you perform causes the corruption, I
think they are related. What corner case do you do?
>
> If I bump into a NULL pointer it is because the tty->disc_data is NULL ....
> However my check for tty->disc_data being NULL also is fine - i.e when
> I do get this error - my disc_data is NOT null ... But not sure what
> (which data) is NULL ??
How are you checking for NULL?
if (data == NULL)
may not work as the error shows:
"Unable to handle kernel NULL pointer dereference at virtual address 0000001a"
Where data (or what ever it was using) was 0x1a not 0. We consider NULL
anything less that a page size. Because of something just like this. You
have a structure pointer that is NULL, accessing the element may not be
NULL.
>
> So now back to the question - What cannot I do inside tty's receive_buf ?
I don't know, but it may not be the issue. Something else may be broken.
Perhaps you can't schedule, which means you can't use something like a
mutex. But if that was the issue, the scheduler itself would give you a
nasty warning that you are scheduling in non-schedulable context.
-- Steve
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: locks inside receive_buf
2011-04-05 13:04 ` Steven Rostedt
@ 2011-04-06 8:56 ` Pavan Savoy
2011-05-17 11:30 ` Pavan Savoy
0 siblings, 1 reply; 10+ messages in thread
From: Pavan Savoy @ 2011-04-06 8:56 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Alan Cox, linux-kernel
On Tue, Apr 5, 2011 at 6:34 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Tue, 2011-04-05 at 16:43 +0530, Pavan Savoy wrote:
>
>> > The program counter is at st_int_recv+0x2a0 when this happened, so that
>> > function is probably where you accessed some structure that was not
>> > initialized.
>> >
>> > foo->bar
>> >
>> > if foo is NULL, you'll get that error.
>> >
>> >> LR is at schedule+0x414/0x4e8
>> >
>> > LR is Link Register, or where this function was called from.
>> >
>> > Now why is the scheduler calling your function, I have no idea.
>>
>> Well this is exactly the problem I have and hence the question
>> regarding sleep in tty's receive_buf function.
>>
>> the function called st_recv or st_int_recv() is basically my line
>> discipline's receive_buf function - which happens like zillions of
>> times properly with tty->disc_data being populated with what I
>> need....
>>
>> However on a corner case - when I perform some operation - which has
>> absolutely NO relation to TTY (at most may be console is using 1 uart)
>> - Everything breaks loose...
>
> Well, if this corner case that you perform causes the corruption, I
> think they are related. What corner case do you do?
corner case meaning - doing something totally un-related to this driver ...
like turning the WLAN driver On/Off....
>> If I bump into a NULL pointer it is because the tty->disc_data is NULL ....
>> However my check for tty->disc_data being NULL also is fine - i.e when
>> I do get this error - my disc_data is NOT null ... But not sure what
>> (which data) is NULL ??
>
> How are you checking for NULL?
>
> if (data == NULL)
>
> may not work as the error shows:
Nope, I thought of that, SO now I check for the last member of the
structure to be NULL...
Imagining I got the wrong disc_data in the TTY during crash ...
so I check for (st_gdata->tty == NULL)
where my tty is the last member of the structure
struct st_data_s {
....
....
struct tty_struct *tty;
} st_gdata;
> "Unable to handle kernel NULL pointer dereference at virtual address 0000001a"
>
> Where data (or what ever it was using) was 0x1a not 0. We consider NULL
> anything less that a page size. Because of something just like this. You
> have a structure pointer that is NULL, accessing the element may not be
> NULL.
>
>>
>> So now back to the question - What cannot I do inside tty's receive_buf ?
>
> I don't know, but it may not be the issue. Something else may be broken.
>
> Perhaps you can't schedule, which means you can't use something like a
> mutex. But if that was the issue, the scheduler itself would give you a
> nasty warning that you are scheduling in non-schedulable context.
I did another thing, I faked a NULL pointer exception in my function
st_int_recv() - to check for the LR and PC and the trace as to how
they would look,
so the trace told me right things, (I set st_gdata NULL and tried to
access st_gdata->lock inside the spin_lock_irqsave routine inside the
function st_int_recv() ... )
[<c04c605c>] (__raw_spin_lock_irqsave+0x0/0xa4) from [<c04c6110>]
(_raw_spin_lock_irqsave+0x10/0x14)
r5:ee510000 r4:eeb1fd19
[<c04c6100>] (_raw_spin_lock_irqsave+0x0/0x14) from [<bf000c40>]
(st_int_recv+0x3c/0x308 [st_drv])
[<bf000c04>] (st_int_recv+0x0/0x308 [st_drv]) from [<bf000148>]
(st_tty_receive+0x5c/0x78 [st_drv])
[<bf0000ec>] (st_tty_receive+0x0/0x78 [st_drv]) from [<c026104c>]
(flush_to_ldisc+0xfc/0x170)
r7:00000003 r6:ee5100f0 r5:ee5100a4 r4:ee510000
[<c0260f50>] (flush_to_ldisc+0x0/0x170) from [<c009c3cc>]
(worker_thread+0x154/0x1e0)
[<c009c278>] (worker_thread+0x0/0x1e0) from [<c00a017c>] (kthread+0x84/0x8c)
[<c00a00f8>] (kthread+0x0/0x8c) from [<c008db58>] (do_exit+0x0/0x5f0)
and the
PC is at __raw_spin_lock_irqsave+0x34/0xa4
LR is at _raw_spin_lock_irqsave+0x10/0x14
suggest that the st_int_recv() is being called from
_raw_spin_lock_irqsave and the exception occured a few lines inside
the st_int_recv() before in and around the code
[<c04c605c>] (__raw_spin_lock_irqsave+0x0/0xa4) from [<c04c6110>]
(_raw_spin_lock_irqsave+0x10/0x14)
r5:ee510000 r4:eeb1fd19
[<c04c6100>] (_raw_spin_lock_irqsave+0x0/0x14) from [<bf000c40>]
(st_int_recv+0x3c/0x308 [st_drv])
[<bf000c04>] (st_int_recv+0x0/0x308
But what I don't understand is the older log which I sent, where the
PC is at st_int_recv+0x284/0x314 [st_drv]
LR is at _raw_spin_lock_irqsave+0x10/0x14
which suggests that the function - st_int_recv() is about to be called
- But NOT yet called...
and so the doubt as to something is going wrong in the TTY layer and
not exactly inside my function...
> -- Steve
>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: locks inside receive_buf
2011-04-06 8:56 ` Pavan Savoy
@ 2011-05-17 11:30 ` Pavan Savoy
0 siblings, 0 replies; 10+ messages in thread
From: Pavan Savoy @ 2011-05-17 11:30 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Alan Cox, linux-kernel
<snip....>
Well apparently I can't sleep long enough, as in from inside the
tty_receive() I cannot do a tty->ops->write and wait for receive() -
since there is 1 receive_buf for 1 tty ....
Well I do have a requirement, where I must send some data from inside
the receive_buf function of a line discipline driver wait for a
certain kind of response and then proceed doing something else.
scheduling a work upon the default worker thread also doesn't seem to
be helping and the tty_receive() handler is called only after the wait
inside the work struct handler is done...
So any suggestions?
should I create a new worker thread ? or any thing simpler ?
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-05-17 11:30 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-30 12:21 locks inside receive_buf Pavan Savoy
2011-03-31 10:25 ` Alan Cox
2011-03-31 11:18 ` Pavan Savoy
2011-03-31 14:33 ` Steven Rostedt
2011-04-01 7:12 ` Pavan Savoy
2011-04-01 13:46 ` Steven Rostedt
2011-04-05 11:13 ` Pavan Savoy
2011-04-05 13:04 ` Steven Rostedt
2011-04-06 8:56 ` Pavan Savoy
2011-05-17 11:30 ` Pavan Savoy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).