linux-kernel - Re: block: Always check queue limits for cloned requests

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: <20151130141141.6ce3fadb@tom-T450>
Date:	Mon, 30 Nov 2015 14:11:41 +0800
From:	Ming Lei <tom.leiming@...il.com>
To:	Markus Trippelsdorf <markus@...ppelsdorf.de>
Cc:	Mike Snitzer <snitzer@...hat.com>, Hannes Reinecke <hare@...e.de>,
	Jens Axboe <axboe@...com>, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org, Christoph Hellwig <hch@....de>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Ewan Milne <emilne@...hat.com>, Jeff Moyer <jmoyer@...hat.com>,
	Ming Lei <tom.leiming@...il.com>
Subject: Re: block: Always check queue limits for cloned requests

On Sun, 29 Nov 2015 18:05:06 +0100
Markus Trippelsdorf <markus@...ppelsdorf.de> wrote:

> On 2015.11.29 at 11:49 -0500, Mike Snitzer wrote:
> > On Sun, Nov 29 2015 at 11:15am -0500,
> > Markus Trippelsdorf <markus@...ppelsdorf.de> wrote:
> > 
> > > On 2015.11.29 at 16:43 +0100, Hannes Reinecke wrote:
> > > > On 11/29/2015 12:49 PM, Markus Trippelsdorf wrote:
> > > > > 
> > > > > I'm still seeing the issue (BUG at drivers/scsi/scsi_lib.c:1096!) even
> > > > > with this patch applied.
> > > > > 
> > > > > markus@x4 linux % git describe
> > > > > v4.4-rc2-215-g081f3698e606
> > > > > 
> > > > Can you generate a crashdump?
> > > > I would need to cross-check with the other dumps I'm having to figure
> > > > out if this really is the same issue.
> > > > There have been other reports (and fixes) which show we're fighting
> > > > several distinct issues here.
> > > 
> > > Unfortunately no. The crash happens on the disk where I store my log
> > > files. And after it happened the magic SysRq keys don't work anymore.
> > > 
> > > The crash only happens on my spinning rust drive that uses the cfq
> > > scheduler. The SSDs (deadline) are fine.
> > > 
> > > The BUG happens reproducibly when building http://www.sagemath.org/ on
> > > that drive.
> > 
> > Are you using DM multipath?  If unsure, please let us know which
> > device(s) map to the "spinning rust drive", and provide output from:
> > lsblk
> 
> No, I'm not using DM multipath. 


OK, I guess it is still one block merge issue, care to test the
following patch?

The patch can address one issue when bio->bi_seg_front_size
is set as too small mistakenly, then fewer physical segment may
be figured out.

---
>From 7aa725205f400ee6823a0d19bf9f41a2464725ce Mon Sep 17 00:00:00 2001
From: Ming Lei <ming.lei@...onical.com>
Date: Mon, 30 Nov 2015 13:10:12 +0800
Subject: [PATCH] blk-merge: fix computing bio->bi_seg_front_size in case of
 single segment

When bio has only one physical segment, we should set bio's
bi_seg_front_size as the real(final) size of the single segment.

Fixes: 02e707424c2ea(blk-merge: fix blk_bio_segment_split)
Reported-by: Markus Trippelsdorf <markus@...ppelsdorf.de>
Signed-off-by: Ming Lei <ming.lei@...onical.com>
---
 block/blk-merge.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index 41a55ba..e01405a 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -103,6 +103,9 @@ static struct bio *blk_bio_segment_split(struct request_queue *q,
 			bvprv = bv;
 			bvprvp = &bvprv;
 			sectors += bv.bv_len >> 9;
+
+			if (nsegs == 1 && seg_size > front_seg_size)
+				front_seg_size = seg_size;
 			continue;
 		}
 new_segment:
-- 
1.9.1









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