linux-kernel - Re: 2.6.33-rc8-rt1 on Beagle

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100301150657.GG16049@pengutronix.de>
Date:	Mon, 1 Mar 2010 16:06:57 +0100
From:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
To:	"Chatterjee, Amit" <amit.chatterjee@...com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	rt-users <linux-rt-users@...r.kernel.org>,
	linux-omap@...r.kernel.org, linux-mmc@...r.kernel.org
Subject: Re: 2.6.33-rc8-rt1 on Beagle

Hello,

On Thu, Feb 25, 2010 at 04:36:23PM +0530, Chatterjee, Amit wrote:
> Migrated to 2.6.33-rc8-rt2 but still am facing the same issue.
> 
> Regards,
> Amit
> 
> -----Original Message-----
> From: linux-rt-users-owner@...r.kernel.org [mailto:linux-rt-users-owner@...r.kernel.org] On Behalf Of Chatterjee, Amit
> Sent: Wednesday, February 24, 2010 5:50 PM
> To: LKML; rt-users
> Subject: 2.6.33-rc8-rt1 on Beagle
> 
> Hi,
> 	I am facing NULL pointer deference error with beagle board. The bootargs used are -
> 
> setenv bootargs 'console=ttyS2,115200n8 root=/dev/mmcblk0p2 rootwait rootfstype=ext3 omapfb.mode=dvi:800x600MR-24@60 omapdss.def_disp=dvi omapfb.vram=0:8M,1:2M,2:4M mem=216M'
> setenv bootcmd 'mmc init;fatload mmc 0 0x80200000 uImage;bootm 0x80200000'
> 
> The crash log is as follows -
> 
> Waiting for root device /dev/mmcblk0p2...
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = c0004000
> [00000000] *pgd=00000000
> Internal error: Oops: 805 [#1] PREEMPT
> last sysfs file:
> Modules linked in:
> CPU: 0    Not tainted  (2.6.33-rc8-rt1 #3)
> PC is at rt_spin_lock_slowlock+0x64/0x220
This corresponds to:

	BUG_ON(rt_mutex_owner(lock) == current);

in rt_spin_lock_slowlock.  If you had CONFIG_BUG_VERBOSE this would have
been more obvious.

> LR is at rt_spin_lock_slowlock+0x24/0x220
> pc : [<c029f85c>]    lr : [<c029f81c>]    psr: 60000093
> sp : cd1a1ed8  ip : cd1a1f08  fp : 00000053
> r10: cd3bc664  r9 : c039c8c4  r8 : cd3bc400
> r7 : cd1a0000  r6 : cd3bc664  r5 : 60000013  r4 : cd3bc664
> r3 : 00000000  r2 : cd3fb480  r1 : 00000000  r0 : cd1a1ed8
> Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> Control: 10c5387d  Table: 80004019  DAC: 00000017
> Process irq/83-mmc0 (pid: 355, stack limit = 0xcd1a02e8)
> Stack: (0xcd1a1ed8 to 0xcd1a2000)
> 1ec0:                                                       00000001 00000006
> 1ee0: cd070040 c0397f48 00000001 cd3fb480 ffffffff 00000002 cd3bc664 60000013
> 1f00: 00000000 cd1a0000 00000000 c029f9f0 00000000 cd3bc600 cd0c3ef4 cd3bc664
> 1f20: 00000000 cd3bc400 cd3bc664 c0213850 cd0c2000 cd0c201c cd3fb480 00000017
> 1f40: 00000000 cd3bc600 00000000 00018000 00000001 00000000 cd3bc664 c020bb94
> 1f60: cd0c3f24 c02145fc c039c880 cd3d07c0 cd1a0000 cd3d07e4 08000000 c039c8c4
> 1f80: c039c8dc c00768e8 cd3d07c0 00000032 cd1a1f88 cd021e58 cd1a1fbc c0076828
> 1fa0: cd3d07c0 00000000 00000000 00000000 00000000 c0060ae8 00000000 00000000
> 1fc0: cd1a1fc0 cd1a1fc0 cd1a1fc8 cd1a1fc8 00000000 00000000 cd1a1fd8 cd1a1fd8
> 1fe0: 00000000 00000000 00000000 00000000 00000000 c0028ec4 107fcd00 0a33ef94
> [<c029f85c>] (rt_spin_lock_slowlock+0x64/0x220) from [<c0213850>] (omap_hsmmc_request+0x44/0x400)
> [<c0213850>] (omap_hsmmc_request+0x44/0x400) from [<c020bb94>] (mmc_request_done+0x64/0x90)
> [<c020bb94>] (mmc_request_done+0x64/0x90) from [<c02145fc>] (omap_hsmmc_irq+0x364/0x46c)
> [<c02145fc>] (omap_hsmmc_irq+0x364/0x46c) from [<c00768e8>] (irq_thread+0xc0/0x208)
> [<c00768e8>] (irq_thread+0xc0/0x208) from [<c0060ae8>] (kthread+0x78/0x80)
> [<c0060ae8>] (kthread+0x78/0x80) from [<c0028ec4>] (kernel_thread_exit+0x0/0x8)
> Code: e597300c e1520003 1a000002 e3a03000 (e5833000)

I assume the problem is that the function omap_hsmmc_request tries to be
clever in a non-rt compatible way:
	
	/*
	 * Prevent races with the interrupt handler because of unexpected
	 * interrupts, but not if we are already in interrupt context i.e.
	 * retries.
	 */
	if (!in_interrupt()) {
		spin_lock_irqsave(&host->irq_lock, host->flags);

But looking at the backtrace in this context in_interrupt() would be
true in !PREEMPT_RT.

You might want to report that to the author(s) of
drivers/mmc/host/omap_hsmmc.c.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/