[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1fc351dd-a213-3310-7611-6b8c60c209cf@kernel.dk>
Date: Tue, 7 Jan 2020 14:00:56 -0700
From: Jens Axboe <axboe@...nel.dk>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org
Cc: stable@...r.kernel.org, Chris Mason <clm@...com>,
Ming Lei <ming.lei@...hat.com>
Subject: Re: [PATCH 5.4 100/191] block: fix splitting segments on boundary
masks
On 1/7/20 1:53 PM, Greg Kroah-Hartman wrote:
> From: Ming Lei <ming.lei@...hat.com>
>
> commit 429120f3df2dba2bf3a4a19f4212a53ecefc7102 upstream.
>
> We ran into a problem with a mpt3sas based controller, where we would
> see random (and hard to reproduce) file corruption). The issue seemed
> specific to this controller, but wasn't specific to the file system.
> After a lot of debugging, we find out that it's caused by segments
> spanning a 4G memory boundary. This shouldn't happen, as the default
> setting for segment boundary masks is 4G.
>
> Turns out there are two issues in get_max_segment_size():
>
> 1) The default segment boundary mask is bypassed
>
> 2) The segment start address isn't taken into account when checking
> segment boundary limit
>
> Fix these two issues by removing the bypass of the segment boundary
> check even if the mask is set to the default value, and taking into
> account the actual start address of the request when checking if a
> segment needs splitting.
Greg, there's a problem with this one on ARM. Should be resolved
shortly, but probably best to defer this one until the next 5.4
stable release.
I'll ping you with both patches once the dust has settled.
--
Jens Axboe
Powered by blists - more mailing lists