kernel/linux.git/drivers/ide/ide-cd.c, branch v4.14.85

cdrom: do not call check_disk_change() inside cdrom_open()

2018-05-30T05:52:34+00:00

[ Upstream commit 2bbea6e117357d17842114c65e9a9cf2d13ae8a3 ] when mounting an ISO filesystem sometimes (very rarely) the system hangs because of a race condition between two tasks. PID: 6766 TASK: ffff88007b2a6dd0 CPU: 0 COMMAND: "mount" #0 [ffff880078447ae0] __schedule at ffffffff8168d605 #1 [ffff880078447b48] schedule_preempt_disabled at ffffffff8168ed49 #2 [ffff880078447b58] __mutex_lock_slowpath at ffffffff8168c995 #3 [ffff880078447bb8] mutex_lock at ffffffff8168bdef #4 [ffff880078447bd0] sr_block_ioctl at ffffffffa00b6818 [sr_mod] #5 [ffff880078447c10] blkdev_ioctl at ffffffff812fea50 #6 [ffff880078447c70] ioctl_by_bdev at ffffffff8123a8b3 #7 [ffff880078447c90] isofs_fill_super at ffffffffa04fb1e1 [isofs] #8 [ffff880078447da8] mount_bdev at ffffffff81202570 #9 [ffff880078447e18] isofs_mount at ffffffffa04f9828 [isofs] #10 [ffff880078447e28] mount_fs at ffffffff81202d09 #11 [ffff880078447e70] vfs_kern_mount at ffffffff8121ea8f #12 [ffff880078447ea8] do_mount at ffffffff81220fee #13 [ffff880078447f28] sys_mount at ffffffff812218d6 #14 [ffff880078447f80] system_call_fastpath at ffffffff81698c49 RIP: 00007fd9ea914e9a RSP: 00007ffd5d9bf648 RFLAGS: 00010246 RAX: 00000000000000a5 RBX: ffffffff81698c49 RCX: 0000000000000010 RDX: 00007fd9ec2bc210 RSI: 00007fd9ec2bc290 RDI: 00007fd9ec2bcf30 RBP: 0000000000000000 R8: 0000000000000000 R9: 0000000000000010 R10: 00000000c0ed0001 R11: 0000000000000206 R12: 00007fd9ec2bc040 R13: 00007fd9eb6b2380 R14: 00007fd9ec2bc210 R15: 00007fd9ec2bcf30 ORIG_RAX: 00000000000000a5 CS: 0033 SS: 002b This task was trying to mount the cdrom. It allocated and configured a super_block struct and owned the write-lock for the super_block->s_umount rwsem. While exclusively owning the s_umount lock, it called sr_block_ioctl and waited to acquire the global sr_mutex lock. PID: 6785 TASK: ffff880078720fb0 CPU: 0 COMMAND: "systemd-udevd" #0 [ffff880078417898] __schedule at ffffffff8168d605 #1 [ffff880078417900] schedule at ffffffff8168dc59 #2 [ffff880078417910] rwsem_down_read_failed at ffffffff8168f605 #3 [ffff880078417980] call_rwsem_down_read_failed at ffffffff81328838 #4 [ffff8800784179d0] down_read at ffffffff8168cde0 #5 [ffff8800784179e8] get_super at ffffffff81201cc7 #6 [ffff880078417a10] __invalidate_device at ffffffff8123a8de #7 [ffff880078417a40] flush_disk at ffffffff8123a94b #8 [ffff880078417a88] check_disk_change at ffffffff8123ab50 #9 [ffff880078417ab0] cdrom_open at ffffffffa00a29e1 [cdrom] #10 [ffff880078417b68] sr_block_open at ffffffffa00b6f9b [sr_mod] #11 [ffff880078417b98] __blkdev_get at ffffffff8123ba86 #12 [ffff880078417bf0] blkdev_get at ffffffff8123bd65 #13 [ffff880078417c78] blkdev_open at ffffffff8123bf9b #14 [ffff880078417c90] do_dentry_open at ffffffff811fc7f7 #15 [ffff880078417cd8] vfs_open at ffffffff811fc9cf #16 [ffff880078417d00] do_last at ffffffff8120d53d #17 [ffff880078417db0] path_openat at ffffffff8120e6b2 #18 [ffff880078417e48] do_filp_open at ffffffff8121082b #19 [ffff880078417f18] do_sys_open at ffffffff811fdd33 #20 [ffff880078417f70] sys_open at ffffffff811fde4e #21 [ffff880078417f80] system_call_fastpath at ffffffff81698c49 RIP: 00007f29438b0c20 RSP: 00007ffc76624b78 RFLAGS: 00010246 RAX: 0000000000000002 RBX: ffffffff81698c49 RCX: 0000000000000000 RDX: 00007f2944a5fa70 RSI: 00000000000a0800 RDI: 00007f2944a5fa70 RBP: 00007f2944a5f540 R8: 0000000000000000 R9: 0000000000000020 R10: 00007f2943614c40 R11: 0000000000000246 R12: ffffffff811fde4e R13: ffff880078417f78 R14: 000000000000000c R15: 00007f2944a4b010 ORIG_RAX: 0000000000000002 CS: 0033 SS: 002b This task tried to open the cdrom device, the sr_block_open function acquired the global sr_mutex lock. The call to check_disk_change() then saw an event flag indicating a possible media change and tried to flush any cached data for the device. As part of the flush, it tried to acquire the super_block->s_umount lock associated with the cdrom device. This was the same super_block as created and locked by the previous task. The first task acquires the s_umount lock and then the sr_mutex_lock; the second task acquires the sr_mutex_lock and then the s_umount lock. This patch fixes the issue by moving check_disk_change() out of cdrom_open() and let the caller take care of it. Signed-off-by: Maurizio Lombardi Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drivers/ide-cd: Handle missing driver data during status check gracefully

2017-11-07T17:12:04+00:00

The 0day bot reports the below failure which happens occasionally, with their randconfig testing (once every ~100 boots). The Code points at the private pointer ->driver_data being NULL, which hints at a race of sorts where the private driver_data descriptor has disappeared by the time we get to run the workqueue. So let's check that pointer before we continue with issuing the command to the drive. This fix is of the brown paper bag nature but considering that IDE is long deprecated, let's do that so that random testing which happens to enable CONFIG_IDE during randconfig builds, doesn't fail because of this. Besides, failing the TEST_UNIT_READY command because the drive private data is gone is something which we could simply do anyway, to denote that there was a problem communicating with the device. BUG: unable to handle kernel NULL pointer dereference at 000001c0 IP: cdrom_check_status *pde = 00000000 Oops: 0000 [#1] SMP CPU: 1 PID: 155 Comm: kworker/1:2 Not tainted 4.14.0-rc8 #127 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 Workqueue: events_freezable_power_ disk_events_workfn task: 4fe90980 task.stack: 507ac000 EIP: cdrom_check_status+0x2c/0x90 EFLAGS: 00210246 CPU: 1 EAX: 00000000 EBX: 4fefec00 ECX: 00000000 EDX: 00000000 ESI: 00000003 EDI: ffffffff EBP: 467a9340 ESP: 507aded0 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 CR0: 80050033 CR2: 000001c0 CR3: 06e0f000 CR4: 00000690 Call Trace: ? ide_cdrom_check_events_real ? cdrom_check_events ? disk_check_events ? process_one_work ? process_one_work ? worker_thread ? kthread ? process_one_work ? __kthread_create_on_node ? ret_from_fork Code: 53 83 ec 14 89 c3 89 d1 be 03 00 00 00 65 a1 14 00 00 00 89 44 24 10 31 c0 8b 43 18 c7 44 24 04 00 00 00 00 c7 04 24 00 00 00 00 <8a> 80 c0 01 00 00 c7 44 24 08 00 00 00 00 83 e0 03 c7 44 24 0c EIP: cdrom_check_status+0x2c/0x90 SS:ESP: 0068:507aded0 CR2: 00000000000001c0 ---[ end trace 2410e586dd8f88b2 ]--- Reported-and-tested-by: Fengguang Wu Signed-off-by: Borislav Petkov Cc: "David S. Miller" Cc: Jens Axboe Cc: Bart Van Assche Signed-off-by: Linus Torvalds

ide:ide-cd: fix kernel panic resulting from missing scsi_req_init

2017-11-01T14:21:58+00:00

Since we split the scsi_request out of struct request, while the standard prep_rq_fn builds 10 byte cmds, it missed to invoke scsi_req_init() to initialize certain fields of a scsi_request structure (.__cmd[], .cmd, .cmd_len and .sense_len but no other members of struct scsi_request). An example panic on virtual machines (qemu/virtualbox) to boot from IDE cdrom: ... [ 8.754381] Call Trace: [ 8.755419] blk_peek_request+0x182/0x2e0 [ 8.755863] blk_fetch_request+0x1c/0x40 [ 8.756148] ? ktime_get+0x40/0xa0 [ 8.756385] do_ide_request+0x37d/0x660 [ 8.756704] ? cfq_group_service_tree_add+0x98/0xc0 [ 8.757011] ? cfq_service_tree_add+0x1e5/0x2c0 [ 8.757313] ? ktime_get+0x40/0xa0 [ 8.757544] __blk_run_queue+0x3d/0x60 [ 8.757837] queue_unplugged+0x2f/0xc0 [ 8.758088] blk_flush_plug_list+0x1f4/0x240 [ 8.758362] blk_finish_plug+0x2c/0x40 ... [ 8.770906] RIP: ide_cdrom_prep_fn+0x63/0x180 RSP: ffff92aec018bae8 [ 8.772329] ---[ end trace 6408481e551a85c9 ]--- ... Fixes: 82ed4db499b8 ("block: split scsi_request out of struct request") Signed-off-by: Hongxu Jia Signed-off-by: Jens Axboe

block: Make most scsi_req_init() calls implicit

2017-06-21T01:27:14+00:00

Instead of explicitly calling scsi_req_init() after blk_get_request(), call that function from inside blk_get_request(). Add an .initialize_rq_fn() callback function to the block drivers that need it. Merge the IDE .init_rq_fn() function into .initialize_rq_fn() because it is too small to keep it as a separate function. Keep the scsi_req_init() call in ide_prep_sense() because it follows a blk_rq_init() call. References: commit 82ed4db499b8 ("block: split scsi_request out of struct request") Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: Omar Sandoval Cc: Nicholas Bellinger Signed-off-by: Jens Axboe

block: introduce new block status code type

2017-06-09T15:27:32+00:00

Currently we use nornal Linux errno values in the block layer, and while we accept any error a few have overloaded magic meanings. This patch instead introduces a new blk_status_t value that holds block layer specific status codes and explicitly explains their meaning. Helpers to convert from and to the previous special meanings are provided for now, but I suspect we want to get rid of them in the long run - those drivers that have a errno input (e.g. networking) usually get errnos that don't know about the special block layer overloads, and similarly returning them to userspace will usually return somethings that strictly speaking isn't correct for file system operations, but that's left as an exercise for later. For now the set of errors is a very limited set that closely corresponds to the previous overloaded errno values, but there is some low hanging fruite to improve it. blk_status_t (ab)uses the sparse __bitwise annotations to allow for sparse typechecking, so that we can easily catch places passing the wrong values. Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe

scsi: introduce a result field in struct scsi_request

2017-04-20T18:16:10+00:00

This passes on the scsi_cmnd result field to users of passthrough requests. Currently we abuse req->errors for this purpose, but that field will go away in its current form. Note that the old IDE code abuses the errors field in very creative ways and stores all kinds of different values in it. I didn't dare to touch this magic, so the abuses are brought forward 1:1. Signed-off-by: Christoph Hellwig Reviewed-by: Martin K. Petersen Reviewed-by: Bart Van Assche Signed-off-by: Jens Axboe

block: remove the blk_execute_rq return value

2017-04-20T18:16:10+00:00

The function only returns -EIO if rq->errors is non-zero, which is not very useful and lets a large number of callers ignore the return value. Just let the callers figure out their error themselves. Signed-off-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Reviewed-by: Bart Van Assche Signed-off-by: Jens Axboe

sched/headers: Prepare for new header dependencies before moving code to

2017-03-02T07:42:36+00:00

We are going to split out of , which will have to be picked up from other headers and a couple of .c files. Create a trivial placeholder file that just maps to to make this patch obviously correct and bisectable. Include the new header in the files that are going to need it. Acked-by: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar

Merge branch 'for-4.11/next' into for-4.11/linus-merge

2017-02-17T21:08:19+00:00

Signed-off-by: Jens Axboe

cdrom: Make device operations read-only

2017-02-14T15:29:56+00:00

Since function tables are a common target for attackers, it's best to keep them in read-only memory. As such, this makes the CDROM device ops tables const. This drops additionally n_minors, since it isn't used meaningfully, and sets the only user of cdrom_dummy_generic_packet explicitly so the variables can all be const. Inspired by similar changes in grsecurity/PaX. Signed-off-by: Kees Cook Acked-by: David S. Miller Signed-off-by: Jens Axboe