On 27.11.2019 21:30, Greg Kroah-Hartman wrote:
From: Jianchao Wang <jianchao.w.wang@xxxxxxxxxx>
[ Upstream commit 69840466086d2248898020a08dda52732686c4e6 ]
There are two cases when handle DISCARD merge.
If max_discard_segments == 1, the bios/requests need to be contiguous
to merge. If max_discard_segments > 1, it takes every bio as a range
and different range needn't to be contiguous.
But now, attempt_merge screws this up. It always consider contiguity
for DISCARD for the case max_discard_segments > 1 and cannot merge
contiguous DISCARD for the case max_discard_segments == 1, because
rq_attempt_discard_merge always returns false in this case.
This patch fixes both of the two cases above.
Reviewed-by: Christoph Hellwig <hch@xxxxxx>
Reviewed-by: Ming Lei <ming.lei@xxxxxxxxxx>
Signed-off-by: Jianchao Wang <jianchao.w.wang@xxxxxxxxxx>
Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
4.19.87, 4.19.88, 4.19.89 all lock up frequently on some of my systems.
The same systems run 5.4.3 fine, so the newer trees are probably OK.
Reverting this commit on top of 4.19.87 makes everything stable.
To trigger it all I have to do is re-rsyncing a directory tree with some
changed files churn, it will usually crash in 10 to 30 minutes.
The systems crashing has ext4 filesystem on a two ssd md raid1 mounted
with the mount option discard. If mounting it without discard, the
crashes no longer seem to occur.
No oops/panic made it to the ipmi console. I suspect the console is just
misbehaving and it didnt really livelock. At one point one line of the
crash made it to the console (kernel BUG at block/blk-core.c:1776), and
it was enough to pinpoint this commit. Note that the line number might
be off, as I was attempting a bisect at the time.
This commit also made it to 4.14.x, but I have not tested it.
