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]
Date:	Sat, 15 Jul 2006 12:35:50 +0200
From:	Laurent Riffard <laurent.riffard@...e.fr>
To:	Arjan van de Ven <arjan@...ux.intel.com>
CC:	Peter Osterlund <petero2@...ia.com>, mingo@...e.hu, akpm@...l.org,
	Kernel development list <linux-kernel@...r.kernel.org>,
	axboe@...e.de
Subject: Re: [patch] lockdep: annotate pktcdvd natural device hierarchy

Le 15.07.2006 09:04, Arjan van de Ven a écrit :
>> So the claim from the lockdep code, "BUG: possible circular locking
>> deadlock detected!", is a false alarm.
> 
> ok this patch ought to kill the false positive:
> 
> 
> the pkt_*_dev functions operate on not-this-blockdevice, and that is
> sufficiently checked at setup time. As a result there is a natural
> hierarchy, which needs nesting annotations
> 
> Signed-off-by: Arjan van de Ven <arjan@...ux.intel.com>
> 
> Index: linux-2.6.18-rc1/drivers/block/pktcdvd.c
> ===================================================================
> --- linux-2.6.18-rc1.orig/drivers/block/pktcdvd.c
> +++ linux-2.6.18-rc1/drivers/block/pktcdvd.c
> @@ -2577,19 +2577,19 @@ static int pkt_ctl_ioctl(struct inode *i
>  	case PKT_CTRL_CMD_SETUP:
>  		if (!capable(CAP_SYS_ADMIN))
>  			return -EPERM;
> -		mutex_lock(&ctl_mutex);
> +		mutex_lock_nested(&ctl_mutex, SINGLE_DEPTH_NESTING);
>  		ret = pkt_setup_dev(&ctrl_cmd);
>  		mutex_unlock(&ctl_mutex);
>  		break;
>  	case PKT_CTRL_CMD_TEARDOWN:
>  		if (!capable(CAP_SYS_ADMIN))
>  			return -EPERM;
> -		mutex_lock(&ctl_mutex);
> +		mutex_lock_nested(&ctl_mutex, SINGLE_DEPTH_NESTING);
>  		ret = pkt_remove_dev(&ctrl_cmd);
>  		mutex_unlock(&ctl_mutex);
>  		break;
>  	case PKT_CTRL_CMD_STATUS:
> -		mutex_lock(&ctl_mutex);
> +		mutex_lock_nested(&ctl_mutex, SINGLE_DEPTH_NESTING);
>  		pkt_get_status(&ctrl_cmd);
>  		mutex_unlock(&ctl_mutex);
>  		break;
> 

Thanks Arjan, this seems to solve the initial issue of this thread, 
which was "possible circular locking deadlock detected!" while 
doing "pktsetup dvd /dev/dvd".

So here is the next step :-(. I'm now running 2.6.18-rc1-mm2 and I was able 
to successfully run:
- modprobe ptkcdvd
- pktsetup dvd /dev/dvd

Then I inserted a UDF-formatted CD-RW in the CD/DVD burner and I typed 
this command :
- mount -oro -tauto /dev/pktcdvd/dvd /mnt/cdrom 
The following happened :

pktcdvd: writer pktcdvd0 mapped to hdc

=============================================
[ INFO: possible recursive locking detected ]
---------------------------------------------
mount/1176 is trying to acquire lock:
 (&bdev->bd_mutex){--..}, at: [do_open+107/957] do_open+0x6b/0x3bd
 (&bdev->bd_mutex){--..}, at: [<c0159c10>] do_open+0x6b/0x3bd

but task is already holding lock:
 (&bdev->bd_mutex){--..}, at: [do_open+107/957] do_open+0x6b/0x3bd
 (&bdev->bd_mutex){--..}, at: [<c0159c10>] do_open+0x6b/0x3bd

other info that might help us debug this:
2 locks held by mount/1176:
 #0:  (&bdev->bd_mutex){--..}, at: [do_open+107/957] do_open+0x6b/0x3bd
 #0:  (&bdev->bd_mutex){--..}, at: [<c0159c10>] do_open+0x6b/0x3bd
 #1:  (&ctl_mutex#2){--..}, at: [mutex_lock+33/36] mutex_lock+0x21/0x24
 #1:  (&ctl_mutex#2){--..}, at: [<c0290dca>] mutex_lock+0x21/0x24

stack backtrace:
 [show_trace+13/16] show_trace+0xd/0x10
 [<c0104db5>] show_trace+0xd/0x10
 [dump_stack+25/28] dump_stack+0x19/0x1c
 [<c0104dd1>] dump_stack+0x19/0x1c
 [__lock_acquire+1916/2469] __lock_acquire+0x77c/0x9a5
 [<c012c95a>] __lock_acquire+0x77c/0x9a5
 [lock_acquire+96/128] lock_acquire+0x60/0x80
 [<c012cbe3>] lock_acquire+0x60/0x80
 [mutex_lock_nested+191/512] mutex_lock_nested+0xbf/0x200
 [<c0290e8c>] mutex_lock_nested+0xbf/0x200
 [do_open+107/957] do_open+0x6b/0x3bd
 [<c0159c10>] do_open+0x6b/0x3bd
 [blkdev_get+110/121] blkdev_get+0x6e/0x79
 [<c0159fd0>] blkdev_get+0x6e/0x79
 [<e1138345>] pkt_open+0x99/0xbf4 [pktcdvd]
 [do_open+161/957] do_open+0xa1/0x3bd
 [<c0159c46>] do_open+0xa1/0x3bd
 [blkdev_open+31/72] blkdev_open+0x1f/0x48
 [<c015a10d>] blkdev_open+0x1f/0x48
 [__dentry_open+184/390] __dentry_open+0xb8/0x186
 [<c0151c8f>] __dentry_open+0xb8/0x186
 [nameidata_to_filp+28/46] nameidata_to_filp+0x1c/0x2e
 [<c0151dcb>] nameidata_to_filp+0x1c/0x2e
 [do_filp_open+46/53] do_filp_open+0x2e/0x35
 [<c0151e0b>] do_filp_open+0x2e/0x35
 [do_sys_open+64/187] do_sys_open+0x40/0xbb
 [<c0152ce9>] do_sys_open+0x40/0xbb
 [sys_open+22/24] sys_open+0x16/0x18
 [<c0152d90>] sys_open+0x16/0x18
 [sysenter_past_esp+86/141] sysenter_past_esp+0x56/0x8d
 [<c0102c2d>] sysenter_past_esp+0x56/0x8d
UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'flexbackup', timestamp 2006/03/17 15:29 (1078)

At this point, I must say that something doesn't play nicely with 4K-STACK 
(Lockdep ? UDF ? pktcdvd ?). A 4K-stack kernel got multiple oops after this
message. Only a 8K-STACK kernel is able to survive this info. 

.config and syslog attached.
-- 
laurent

View attachment "config-2.6.18-rc1-mm2" of type "text/plain" (44034 bytes)

View attachment "syslog" of type "text/plain" (36484 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ