BUG: sleeping function called from invalid context

Hi all,

While trying to use the LRADC and touchscreen functionality on imx28, I've run into this problem:

udevd[523]: starting version 171

BUG: sleeping function called from invalid context at kernel/mutex.c:271
in_atomic(): 1, irqs_disabled(): 128, pid: 523, name: udevd
no locks held by udevd/523.
irq event stamp: 956
hardirqs last ?enabled at (956): [<c032e56c>]
_raw_write_unlock_irqrestore+0x3c/0x68
hardirqs last disabled at (955): [<c032e6ec>]
_raw_write_lock_irqsave+0x1c/0x58
softirqs last ?enabled at (843): [<c0025c78>] irq_exit+0x54/0xb0
softirqs last disabled at (792): [<c0025c78>] irq_exit+0x54/0xb0
[<c0013238>] (unwind_backtrace+0x0/0xe0) from [<c032d198>]
(mutex_lock_nested+0x24/0x31c)
[<c032d198>] (mutex_lock_nested+0x24/0x31c) from [<c0017570>]
(clk_enable+0x20/0x48)
[<c0017570>] (clk_enable+0x20/0x48) from [<c023173c>]
(pl011_console_write+0x20/0x78)
[<c023173c>] (pl011_console_write+0x20/0x78) from [<c0020780>]
(__call_console_drivers+0x84/0x9c)
[<c0020780>] (__call_console_drivers+0x84/0x9c) from [<c0020ba0>]
(console_unlock+0xfc/0x1ec)
[<c0020ba0>] (console_unlock+0xfc/0x1ec) from [<c0021150>]
(vprintk+0x3b0/0x440)
[<c0021150>] (vprintk+0x3b0/0x440) from [<c032b4d4>] (printk+0x18/0x24)
[<c032b4d4>] (printk+0x18/0x24) from [<c0233a5c>] (kmsg_writev+0xd8/0xfc)
[<c0233a5c>] (kmsg_writev+0xd8/0xfc) from [<c008f58c>]
(do_sync_write+0x98/0xd4)
[<c008f58c>] (do_sync_write+0x98/0xd4) from [<c008fe98>]
(vfs_write+0xc8/0x138)
[<c008fe98>] (vfs_write+0xc8/0x138) from [<c00900e0>] (sys_write+0x3c/0x68)
[<c00900e0>] (sys_write+0x3c/0x68) from [<c000e180>]
(ret_fast_syscall+0x0/0x38)

It seems that the printk calls cause the problem (it's not just with udev, seems to have the problem with all printk calls). The touchscreen works perfectly and I'd like to submit a patch which supports it, but I keep getting the same messages. What can cause the problem, why is it an atomic context within the udevd?

Looks like the same error I faced before:
http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2

Quoted 36 lines · Peter Rusko

While trying to use the LRADC and touchscreen functionality on imx28, I've run into this problem:

udevd[523]: starting version 171

BUG: sleeping function called from invalid context at kernel/mutex.c:271
in_atomic(): 1, irqs_disabled(): 128, pid: 523, name: udevd
no locks held by udevd/523.
irq event stamp: 956
hardirqs last ?enabled at (956): [<c032e56c>]
_raw_write_unlock_irqrestore+0x3c/0x68
hardirqs last disabled at (955): [<c032e6ec>]
_raw_write_lock_irqsave+0x1c/0x58
softirqs last ?enabled at (843): [<c0025c78>] irq_exit+0x54/0xb0
softirqs last disabled at (792): [<c0025c78>] irq_exit+0x54/0xb0
[<c0013238>] (unwind_backtrace+0x0/0xe0) from [<c032d198>]
(mutex_lock_nested+0x24/0x31c)
[<c032d198>] (mutex_lock_nested+0x24/0x31c) from [<c0017570>]
(clk_enable+0x20/0x48)
[<c0017570>] (clk_enable+0x20/0x48) from [<c023173c>]
(pl011_console_write+0x20/0x78)
[<c023173c>] (pl011_console_write+0x20/0x78) from [<c0020780>]
(__call_console_drivers+0x84/0x9c)
[<c0020780>] (__call_console_drivers+0x84/0x9c) from [<c0020ba0>]
(console_unlock+0xfc/0x1ec)
[<c0020ba0>] (console_unlock+0xfc/0x1ec) from [<c0021150>]
(vprintk+0x3b0/0x440)
[<c0021150>] (vprintk+0x3b0/0x440) from [<c032b4d4>] (printk+0x18/0x24)
[<c032b4d4>] (printk+0x18/0x24) from [<c0233a5c>] (kmsg_writev+0xd8/0xfc)
[<c0233a5c>] (kmsg_writev+0xd8/0xfc) from [<c008f58c>]
(do_sync_write+0x98/0xd4)
[<c008f58c>] (do_sync_write+0x98/0xd4) from [<c008fe98>]
(vfs_write+0xc8/0x138)
[<c008fe98>] (vfs_write+0xc8/0x138) from [<c00900e0>] (sys_write+0x3c/0x68)
[<c00900e0>] (sys_write+0x3c/0x68) from [<c000e180>]
(ret_fast_syscall+0x0/0x38)

Quoted 5 lines

It seems that the printk calls cause the problem (it's not just with udev, seems to have the problem with all printk calls). The touchscreen works perfectly and I'd like to submit a patch which supports it, but I keep getting the same messages. What can cause the problem, why is it an atomic context within the udevd?

Looks like the same error I faced before:
http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2

Hello,

Quoted 2 lines · Fabio Estevam

Looks like the same error I faced before:
http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2

which resulted in some concerns about locking correctness. On i.MX28 we usually use

	http://thread.gmane.org/gmane.linux.ports.arm.kernel/100744/focus=100746

(though this patch wasn't accepted either. The right fix is to convert mxs to the upcoming clk framework, which didn't land into mainline yet.)

Quoted 5 lines · Uwe Kleine-K?nig

Hello,

Quoted 2 lines · Fabio Estevam

Looks like the same error I faced before:
http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2

Quoted 7 lines

which resulted in some concerns about locking correctness. On i.MX28 we usually use

	http://thread.gmane.org/gmane.linux.ports.arm.kernel/100744/focus=100746

(though this patch wasn't accepted either. The right fix is to convert mxs to the upcoming clk framework, which didn't land into mainline yet.)

Irrespective of the clk framework. If you convert to the clk_prepare() methodology, then you fix this bug. You can do this as a two-step thing. First, convert _all_ your drivers to issue the correct clk_prepare() and clk_unprepare() calls at the appropriate time. Once that's all done, convert your clk API implementation to doing the sleeping parts of your existing clk_enable() in clk_prepare() and leave the non-sleeping parts in clk_enable(). (Ditto for clk_disable() vs clk_unprepare().)

You'll need to do most of the driver work _before_ the clk framework lands, because it becomes mandatory for your drivers to call clk_prepare() with that.

Plus, on the implementation side, you'll already have done the work to separate the two for the clk framework, which in theory should mean that its easier to convert.

So really, there's no excuse not to fix this for the imx/mxwhatever SoCs today - the clk framework is totally irrelevant as far as this goes.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 8 lines · Uwe Kleine-K?nig

Hello,

Quoted 2 lines · Fabio Estevam

Looks like the same error I faced before:
http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2

which resulted in some concerns about locking correctness. On i.MX28 we usually use

Quoted 4 lines

	http://thread.gmane.org/gmane.linux.ports.arm.kernel/100744/focus=100746

(though this patch wasn't accepted either. The right fix is to convert mxs to the upcoming clk framework, which didn't land into mainline yet.)

Irrespective of the clk framework. If you convert to the clk_prepare() methodology, then you fix this bug. You can do this as a two-step thing.

[..]

So really, there's no excuse not to fix this for the imx/mxwhatever SoCs today - the clk framework is totally irrelevant as far as this goes.

Quoted 2 lines · Russell King - ARM Linux

So really, there's no excuse not to fix this for the imx/mxwhatever SoCs today - the clk framework is totally irrelevant as far as this goes.

I think doing the clk_prepare seperation and converting to the clk framework in one step will be easier.

From a point of view of being able to separate the changes so there isn't

Quoted 3 lines · Uwe Kleine-K?nig

Quoted 2 lines · Russell King - ARM Linux

So really, there's no excuse not to fix this for the imx/mxwhatever SoCs today - the clk framework is totally irrelevant as far as this goes.

Quoted 2 lines

I think doing the clk_prepare seperation and converting to the clk framework in one step will be easier.

From a point of view of being able to separate the changes so there isn't a flag day, you're wrong. clk_prepare() is already present in the kernel as dummy functions, and all you need to do at this point is arrange for the drivers to make the appropriate calls. There's no need to write one line of code behind clk_prepare() at the current time.

If you then want to provide a clk_prepare() implementation, then you need to select CONFIG_HAVE_CLK_PREPARE to prevent the dummy function being used.

Quoted 7 lines · Russell King - ARM Linux

Quoted 5 lines · Uwe Kleine-K?nig

Quoted 2 lines · Russell King - ARM Linux

So really, there's no excuse not to fix this for the imx/mxwhatever SoCs today - the clk framework is totally irrelevant as far as this goes.

I think doing the clk_prepare seperation and converting to the clk framework in one step will be easier.

Quoted 5 lines

From a point of view of being able to separate the changes so there isn't a flag day, you're wrong. clk_prepare() is already present in the kernel as dummy functions, and all you need to do at this point is arrange for the drivers to make the appropriate calls. There's no need to write one line of code behind clk_prepare() at the current time.

Yeah, but adding clk_prepare to the serial driver doesn't help me to get rid of the BUG reported in this thread without giving it some meaning in the platform, right?

Quoted 8 lines · Uwe Kleine-K?nig

Quoted 7 lines · Russell King - ARM Linux

Quoted 5 lines · Uwe Kleine-K?nig

Quoted 2 lines · Russell King - ARM Linux

So really, there's no excuse not to fix this for the imx/mxwhatever SoCs today - the clk framework is totally irrelevant as far as this goes.

I think doing the clk_prepare seperation and converting to the clk framework in one step will be easier.

Quoted 8 lines

Quoted 5 lines

From a point of view of being able to separate the changes so there isn't a flag day, you're wrong. clk_prepare() is already present in the kernel as dummy functions, and all you need to do at this point is arrange for the drivers to make the appropriate calls. There's no need to write one line of code behind clk_prepare() at the current time.

Yeah, but adding clk_prepare to the serial driver doesn't help me to get rid of the BUG reported in this thread without giving it some meaning in the platform, right?

So, let's be honest about why this bug isn't being fixed then. Your attitude to this problem is ignore it and to do nothing, rather than trying to fix it via a perfectly good transition path provided for you.

Okay, now we can see clearly why the bug is still there. Thanks.

Given such an attitude, remind me why I should care whether iMX breaks while we do the consolidation and cleanup work to core code, such as the recent restart changes.