linux-kernel - Re: [PATCH] SCSI IOCTL: Check for device deletion [was Re: __elv_add

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] [day] [month] [year] [list]
Message-ID: <4DEF1BCA.4030507@secunet.com>
Date:	Wed, 08 Jun 2011 08:50:50 +0200
From:	Torsten Hilbrich <torsten.hilbrich@...unet.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	Jens Axboe <jaxboe@...ionio.com>,
	Parag Warudkar <parag.lkml@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	Linux SCSI List <linux-scsi@...r.kernel.org>
Subject: Re: [PATCH] SCSI IOCTL: Check for device deletion [was Re:  __elv_add_request
 OOPS]

Am 27.05.2011 22:21, schrieb James Bottomley:

> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 58584dc..44e8ca3 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -297,7 +297,7 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget,
>  		kfree(sdev);
>  		goto out;
>  	}
> -
> +	blk_get_queue(sdev->request_queue);
>  	sdev->request_queue->queuedata = sdev;
>  	scsi_adjust_queue_depth(sdev, 0, sdev->host->cmd_per_lun);
>  
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index e639125..e0bd3f7 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -322,6 +322,7 @@ static void scsi_device_dev_release_usercontext(struct work_struct *work)
>  		kfree(evt);
>  	}
>  
> +	blk_put_queue(sdev->request_queue);
>  	/* NULL queue means the device can't be used */
>  	sdev->request_queue = NULL;

I did some testing with this patch (using 3.0rc2 for reproducing it upstream, but the same behaviour
with 2.6.39 and e73e079bf128d68284efedeba1fbbc18d78610f9 applied).

ext2 and ext3 FS on the USB sticks are working fine, however I get the following oops when performing
the same test with the CDROM part of a sandisk cruzer:

general protection fault: 0000 [#1] SMP 
CPU 1 
Modules linked in:

Pid: 1978, comm: umount Not tainted 3.0.0-rc2 #41 LENOVO 20077KG/20077KG
RIP: 0010:[<ffffffff81244590>]  [<ffffffff81244590>] elv_may_queue+0x10/0x20
RSP: 0018:ffff88007be17aa8  EFLAGS: 00010097
RAX: 6b6b6b6b6b6b6b6b RBX: ffff88007bc628c0 RCX: 0000000000000010
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88007bc628c0
RBP: ffff88007be17aa8 R08: 0000000000000000 R09: ffff88007bc6f340
R10: ffff88007be17d08 R11: ffff88007be061c8 R12: 0000000000000000
R13: 0000000000000001 R14: 0000000000000000 R15: ffff88007bc6f340
FS:  00007f5f4ba89740(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5f4b12a355 CR3: 000000007be2f000 CR4: 00000000000006a0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process umount (pid: 1978, threadinfo ffff88007be16000, task ffff88007cceb7b0)
Stack:
 ffff88007be17b08 ffffffff8124b3ce ffff88007d19f5f8 ffff88007bd90188
 ffff880000000010 ffffffff810f52a6 ffff88007be17b08 ffff88007bc628c0
 0000000000000000 0000000000000010 ffff88007be17d08 ffff88007bc6f340
Call Trace:
 [<ffffffff8124b3ce>] get_request+0x3e/0x380
 [<ffffffff810f52a6>] ? kfree_debugcheck+0x16/0x40
 [<ffffffff8124b739>] get_request_wait+0x29/0x190
 [<ffffffff8124bc0d>] blk_get_request+0x6d/0x80
 [<ffffffff8149a258>] scsi_execute+0x48/0x160
 [<ffffffff8149a491>] ? scsi_execute_req+0x61/0x110
 [<ffffffff8149a4d7>] scsi_execute_req+0xa7/0x110
 [<ffffffff81493e0d>] T.752+0x4d/0x110
 [<ffffffff810f5d68>] ? cache_free_debugcheck+0x198/0x250
 [<ffffffff81493f36>] scsi_set_medium_removal+0x66/0x90
 [<ffffffff81135c6a>] ? fsnotify_clear_marks_by_inode+0x2a/0xf0
 [<ffffffff814d4670>] sr_lock_door+0x20/0x30
 [<ffffffff816d05a7>] cdrom_release+0x137/0x250
 [<ffffffff810f5d68>] ? cache_free_debugcheck+0x198/0x250
 [<ffffffff811de45c>] ? isofs_destroy_inode+0x1c/0x20
 [<ffffffff814d3a08>] sr_block_release+0x38/0x60
 [<ffffffff81130cac>] __blkdev_put+0x16c/0x1b0
 [<ffffffff81130d21>] blkdev_put+0x31/0x130
 [<ffffffff810ffc3d>] kill_block_super+0x4d/0x80
 [<ffffffff811003d5>] deactivate_locked_super+0x45/0x60
 [<ffffffff8110100a>] deactivate_super+0x4a/0x70
 [<ffffffff8111a98a>] mntput_no_expire+0x12a/0x1a0
 [<ffffffff8111afb8>] sys_umount+0x78/0x3b0
 [<ffffffff819cd3ab>] system_call_fastpath+0x16/0x1b
Code: 66 66 66 90 48 8b 47 18 48 8b 00 48 8b 40 68 48 85 c0 74 05 48 89 f7 ff d0 c9 c3 55 48 89 e5 66 66 66 66 90 48 8b 47 18 48 8b 00 
 8b 50 70 31 c0 48 85 d2 74 02 ff d2 c9 c3 90 55 48 89 e5 66 
RIP  [<ffffffff81244590>] elv_may_queue+0x10/0x20
 RSP <ffff88007be17aa8>
---[ end trace a59ceb38f50c5e0c ]---

Steps to reproduce:

1. mount /dev/sr0 /mnt # Mount fails
2. umount /mnt # Message about not being mounted
3. mount /dev/sr0 /mnt # [sr0] messages appears in kernel log
4. remove USB stick # USB disconnect message
5. umount /mnt # above error message

I mount the /dev/sr0 in /mnt and remove it before calling umount. I had to repeat the mount as it seemed to fail the first time (calling umount /mnt in-between). The second mount succeeded with some errors reported by the sr0.

Full logs attached as text file.

	Torsten


View attachment "screenlog.0" of type "text/plain" (51967 bytes)