[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200108015915.GA28075@ming.t460p>
Date: Wed, 8 Jan 2020 09:59:15 +0800
From: Ming Lei <ming.lei@...hat.com>
To: Jens Axboe <axboe@...nel.dk>
Cc: Guenter Roeck <linux@...ck-us.net>, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, Chris Mason <clm@...com>
Subject: Re: [PATCH] block: fix splitting segments
On Tue, Jan 07, 2020 at 03:32:58PM -0700, Jens Axboe wrote:
> On 1/7/20 3:30 PM, Ming Lei wrote:
> > On Tue, Jan 07, 2020 at 10:11:45AM -0800, Guenter Roeck wrote:
> >> On Tue, Jan 07, 2020 at 11:23:39PM +0800, Ming Lei wrote:
> >>> On Tue, Jan 07, 2020 at 04:47:08AM -0800, Guenter Roeck wrote:
> >>>> Hi,
> >>>>
> >>>> On Sun, Dec 29, 2019 at 10:32:30AM +0800, Ming Lei wrote:
> >>>>> There are two issues in get_max_segment_size():
> >>>>>
> >>>>> 1) the default segment boudary mask is bypassed, and some devices still
> >>>>> require segment to not cross the default 4G boundary
> >>>>>
> >>>>> 2) the segment start address isn't taken into account when checking
> >>>>> segment boundary limit
> >>>>>
> >>>>> Fixes the two issues.
> >>>>>
> >>>>> Fixes: dcebd755926b ("block: use bio_for_each_bvec() to compute multi-page bvec count")
> >>>>> Signed-off-by: Ming Lei <ming.lei@...hat.com>
> >>>>
> >>>> This patch, pushed into mainline as "block: fix splitting segments on
> >>>> boundary masks", results in the following crash when booting 'versatilepb'
> >>>> in qemu from disk. Bisect log is attached. Detailed log is at
> >>>> https://kerneltests.org/builders/qemu-arm-master/builds/1410/steps/qemubuildcommand/logs/stdio
> >>>>
> >>>> Guenter
> >>>>
> >>>> ---
> >>>> Crash:
> >>>>
> >>>> kernel BUG at block/bio.c:1885!
> >>>> Internal error: Oops - BUG: 0 [#1] ARM
> >>>
> >>> Please apply the following debug patch, and post the log.
> >>>
> >>
> >> Here you are:
> >>
> >> max_sectors 2560 max_segs 96 max_seg_size 65536 mask ffffffff
> >> c738da80: 8c80/0 2416 28672, 0
> >> total sectors 56
> >>
> >> (I replaced %p with %px).
> >>
> >
> > Please try the following patch and see if it makes a difference.
> > If not, replace trace_printk with printk in previous debug patch,
> > and apply the debug patch only & post the log.
>
> If it is a 32-bit issue, then we should use a 64-bit type to make
> this nicer than ULL. But it seems reasonable that it could be!
oops, just saw this email after sending out the patch.
Do you need V2 to change ULL to u64?
Thanks,
Ming
Powered by blists - more mailing lists