linux-kernel - Re: linux-next-20090225: ide-cd triggers BUG at arch/x86/mm/ioremap.c:80!

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:	Mon, 2 Mar 2009 16:27:23 +0100
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	petkovbb@...il.com
Cc:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	linux-kernel@...r.kernel.org
Subject: Re: linux-next-20090225: ide-cd triggers BUG at arch/x86/mm/ioremap.c:80!

On Monday 02 March 2009, Borislav Petkov wrote:
> Hi,
> 
> > Borislav Petkov wrote:
> >> Can you also apply the following patch and send us the output?
> > I applied the patch after "git bisect reset" since I couldn't apply from this
> > state.
> >
> > [    3.419143] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> > [    3.424508] ide_generic: please use "probe_mask=0x3f" module parameter for probing all legacy ISA IDE ports
> > [    3.429658] ide-gd driver 1.18
> > [    3.433879] ide-cd driver 5.00
> > [    3.440135] mapping rq to sg: dev hda: type=a, flags=82640
> > [    3.441873]   sector 4294967295, nr/cnr 0/0
> > [    3.445288]   bio (null), biotail (null), buffer (null), data f700fbc4, len 24
> > [    3.452602] ide-cd: hda: ATAPI 1X CD-ROM drive, 32kB Cache
> > [    3.456659] Uniform CD-ROM driver Revision: 3.20
> > [    3.460913] mapping rq to sg: dev hda: type=a, flags=8a640
> > [    3.464697]   sector 4294967295, nr/cnr 0/0
> > [    3.465881]   bio (null), biotail (null), buffer (null), data (null), len 0
> > [    3.472354] Pid: 1, comm: swapper Not tainted 2.6.29-rc6-next-20090227-dirty #10
> > [    3.476790] Call Trace:
> > [    3.477860]  [<c02ef9bd>] ide_cd_do_request+0x12d/0x170
> > [    3.480496]  [<c02e1d28>] start_request+0xa8/0x160
> > [    3.481883]  [<c015d92b>] ? trace_hardirqs_on+0xb/0x10
> > [    3.485680]  [<c02e1f7b>] do_ide_request+0x16b/0x250
> > [    3.489231]  [<c025e5a5>] ? blk_remove_plug+0x75/0xf0
> > [    3.492817]  [<c025f770>] blk_start_queueing+0x20/0x30
> > [    3.495475]  [<c025d2be>] elv_insert+0x17e/0x1b0
> > [    3.497088]  [<c025e458>] ? blk_plug_device+0x88/0x120
> > [    3.499681]  [<c025d372>] __elv_add_request+0x82/0xc0
> > [    3.501428]  [<c0263ad0>] blk_execute_rq_nowait+0x60/0xb0
> > [    3.504214]  [<c0263bb6>] blk_execute_rq+0x96/0xd0
> > [    3.505802]  [<c0263a40>] ? blk_end_sync_rq+0x0/0x30
> > [    3.508392]  [<c025f59c>] ? get_request_wait+0x2c/0x160
> > [    3.509883]  [<c0160429>] ? __lock_acquired+0x109/0x1c0
> > [    3.512691]  [<c025f6f4>] ? blk_get_request+0x24/0x80
> > [    3.515239]  [<c02ef196>] ide_cd_queue_pc+0xb6/0x140
> 
> ok, if I read the stack dump correctly, we map an rq with rq->data = NULL to an
> sg. Code path starts at cdrom_check_status() and actually, we don't need a
> buffer here since we send a TEST_UNIT_READY and we're only interested in the
> sense returned. And this won't trigger if we haven't enabled
> CONFIG_DEBUG_VIRTUAL. Yep, I know that this is a dirty hack but it fixes it
> here. Tetsuo, does the following fix your problem?
> 
> diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
> index 481fb1b..e6ac4cc 100644
> --- a/drivers/ide/ide-io.c
> +++ b/drivers/ide/ide-io.c
> @@ -238,6 +238,8 @@ void ide_map_sg(ide_drive_t *drive, struct ide_cmd *cmd)
>  		sg_init_one(sg, rq->buffer, rq->nr_sectors * SECTOR_SIZE);
>  		cmd->sg_nents = 1;
>  	} else if (!rq->bio) {
> +		if (!rq->data)
> +			rq->data = &rq->data;
>  		sg_init_one(sg, rq->data, rq->data_len);
>  		cmd->sg_nents = 1;
>  	} else
> 
> @Bart: I'm open for suggestions wrt to a more elegant solution :).

Seems like we should check for blk_fs_request(fs) || rq->data_len
instead of unconditionally sg mapping all requests in ->do_request.

[ Sigh, I thought it is harmless to always call sg_init_one()...
  probably because it was true back when I added this helper :) ]

Thanks,
Bart
--
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/