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: <20090303083506.GA5172@liondog.tnic>
Date:	Tue, 3 Mar 2009 09:35:06 +0100
From:	Borislav Petkov <petkovbb@...glemail.com>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...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!

Hi,

> > @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 :) ]

how about something like that:

We map to sg once in ide_issue_pc since all drivers call into that.
We have to exclude ide_tape for now since it doesn't do that and uses
its own io buffers-method. Then, we do for both ide-cd and ide-floppy
blk_rq_bytes(rq) in ide_init_sg_cmd() after I've fixed the partial
completions issue later.

Lightly tested with ide-cd for now.

@Tetsuo: please do test, this should fix your OOPS.

Thanks.

--

diff --git a/drivers/ide/ide-atapi.c b/drivers/ide/ide-atapi.c
index ff6adea..3c7992a 100644
--- a/drivers/ide/ide-atapi.c
+++ b/drivers/ide/ide-atapi.c
@@ -625,7 +625,7 @@ static ide_startstop_t ide_transfer_pc(ide_drive_t *drive)
 
 ide_startstop_t ide_issue_pc(ide_drive_t *drive, struct ide_cmd *cmd)
 {
-	struct ide_atapi_pc *pc;
+	struct ide_atapi_pc *uninitialized_var(pc);
 	ide_hwif_t *hwif = drive->hwif;
 	ide_expiry_t *expiry = NULL;
 	struct request *rq = hwif->rq;
@@ -642,6 +642,7 @@ ide_startstop_t ide_issue_pc(ide_drive_t *drive, struct ide_cmd *cmd)
 
 		if (drive->dma)
 			drive->dma = !ide_dma_prepare(drive, cmd);
+
 	} else {
 		pc = drive->pc;
 
@@ -669,6 +670,17 @@ ide_startstop_t ide_issue_pc(ide_drive_t *drive, struct ide_cmd *cmd)
 						       : WAIT_TAPE_CMD;
 	}
 
+	if (drive->media != ide_tape &&
+	      !drive->dma && (blk_fs_request(rq) || rq->data_len)) {
+		ide_init_sg_cmd(cmd, blk_rq_bytes(rq));
+		ide_map_sg(drive, cmd);
+
+		if (drive->media == ide_floppy) {
+			pc->sg = hwif->sg_table;
+			pc->sg_cnt = cmd->sg_nents;
+		}
+	}
+
 	ide_init_packet_cmd(cmd, tf_flags, bcount, drive->dma);
 
 	(void)do_rw_taskfile(drive, cmd);
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 9e19aec..e7c278c 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -916,10 +916,6 @@ static ide_startstop_t ide_cd_do_request(ide_drive_t *drive, struct request *rq,
 
 	cmd.rq = rq;
 
-	ide_init_sg_cmd(&cmd,
-		blk_fs_request(rq) ? (rq->nr_sectors << 9) : rq->data_len);
-	ide_map_sg(drive, &cmd);
-
 	return ide_issue_pc(drive, &cmd);
 out_end:
 	nsectors = rq->hard_nr_sectors;
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index b7f0206..9a58db3 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -244,7 +244,6 @@ static ide_startstop_t ide_floppy_do_request(ide_drive_t *drive,
 					     struct request *rq, sector_t block)
 {
 	struct ide_disk_obj *floppy = drive->driver_data;
-	ide_hwif_t *hwif = drive->hwif;
 	struct ide_cmd cmd;
 	struct ide_atapi_pc *pc;
 
@@ -292,13 +291,6 @@ static ide_startstop_t ide_floppy_do_request(ide_drive_t *drive,
 		cmd.tf_flags |= IDE_TFLAG_WRITE;
 
 	cmd.rq = rq;
-
-	ide_init_sg_cmd(&cmd, rq->nr_sectors << 9);
-	ide_map_sg(drive, &cmd);
-
-	pc->sg = hwif->sg_table;
-	pc->sg_cnt = cmd.sg_nents;
-
 	pc->rq = rq;
 
 	return ide_floppy_issue_pc(drive, &cmd, pc);

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ