What happened to this patch? (Re: [BUG] panic after umount (biscted))

What happened to this patch? (Re: [BUG] panic after umount (biscted))

[Theodore Ts'o]

I was going through my set of kernel patches that I've cherry picked on
LKML for my private kernel, and I noticed this hasn't gotten merged into
mainline yet.   The original thread was here:

	 http://lkml.org/lkml/2007/10/27/61

and addressed a panic after a umount reported by Sebastian Siewior.  Was
this addressed in some other way?

          					- Ted


diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 61fdaf0..4042269 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1115,6 +1115,8 @@ static int scsi_init_io(struct scsi_cmnd *cmd)
 	 * kmapping pages)
 	 */
 	cmd->use_sg = req->nr_phys_segments;
+	if (!cmd->use_sg)
+		return 0;
 
 	/*
 	 * If sg table allocation fails, requeue request later.
@@ -1191,7 +1193,7 @@ int scsi_setup_blk_pc_cmnd(struct scsi_device *sdev, struct request *req)
 	if (req->bio) {
 		int ret;
 
-		BUG_ON(!req->nr_phys_segments);
+		BUG_ON(!req->nr_phys_segments && req->bio->bi_size);
 
 		ret = scsi_init_io(cmd);
 		if (unlikely(ret))
@@ -1236,9 +1238,11 @@ int scsi_setup_fs_cmnd(struct scsi_device *sdev, struct request *req)
 	if (ret != BLKPREP_OK)
 		return ret;
 	/*
-	 * Filesystem requests must transfer data.
+	 * Filesystem requests must transfer data, unless it's an empty
+	 * barrier.
 	 */
-	BUG_ON(!req->nr_phys_segments);
+	if (!req->nr_phys_segments && !bio_empty_barrier(req->bio))
+		blk_dump_rq_flags(req, "scsi");
 
 	cmd = scsi_get_cmd_from_req(sdev, req);
 	if (unlikely(!cmd))

Re: What happened to this patch? (Re: [BUG] panic after umount (biscted))

[Jens Axboe]

On Thu, Dec 13 2007, Theodore Ts'o wrote:
> 
> I was going through my set of kernel patches that I've cherry picked on
> LKML for my private kernel, and I noticed this hasn't gotten merged into
> mainline yet.   The original thread was here:
> 
> 	 http://lkml.org/lkml/2007/10/27/61
> 
> and addressed a panic after a umount reported by Sebastian Siewior.  Was
> this addressed in some other way?

Yes, the below wasn't a proposal for inclusion, the problem got fixed
differently by commit 51fd77bd9f512ab6cc9df0733ba1caaab89eb957

-- 
Jens Axboe