Linux PARISC architecture development
 help / color / mirror / Atom feed
From: John David Anglin <dave.anglin@bell.net>
To: Ming Lei <tom.leiming@gmail.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Helge Deller <deller@gmx.de>,
	linux-block@vger.kernel.org,
	Linux SCSI List <linux-scsi@vger.kernel.org>,
	linux-parisc List <linux-parisc@vger.kernel.org>,
	Kent Overstreet <kent.overstreet@gmail.com>
Subject: Re: [BUG] "block: make generic_make_request handle arbitrarily sized bios" breaks boot on parisc-linux
Date: Wed, 9 Mar 2016 10:15:54 -0500	[thread overview]
Message-ID: <56E03E2A.5020208@bell.net> (raw)
In-Reply-To: <CACVXFVN4pj2fTrP7Lzqkw4QJHESuMBOYvg+0LbwXErSAy0yP=g@mail.gmail.com>

On 2016-03-09 9:43 AM, Ming Lei wrote:
>> We've provided all the information you asked for, what's the next step
>> >on this, or do we have to unwind the bio splitting code with reverts
>> >until it starts working?
> John, Helge, and I did discuss the problem for a while privately, and looks
> it is related with compiler.  Last time, I sent one patch which can make the
> issue disappear, but the main change is just invovled with the below:
>
>   struct bio_vec {
>       struct page    *bv_page;
> -    unsigned int    bv_len;
> +    unsigned int    bv_seg:8;
> +    unsigned int    bv_len:24;
>       unsigned int    bv_offset;
>   };
>
> Maybe John and Helge have some update recently?
>
> The logic in blk_bio_segment_split() is correct, and it does respect the max
> segment size limit.
Helge has found that tagging blk_bio_segment_split() with "__attribute__ 
((optimize("O0")))"
makes the issue disappear.  The bug remains if one just adds bv_len to 
the struct without the
bit fields.  Maybe problem is evident from following output which I sent 
to Ming and Helge
last weekend?

blk_rq_map_sg: merge bug: 3 2, extra_len 0, dma_drain 0
check_bvec: dump bvec for 000000007e4efdc0(f:24490000, t:1)
             0: 0 4096 246503 000000007e4a4f00(0, 94208, 1)
             1: 0 4096 246504 000000007e4a4f00(0, 94208, 1)
             2: 0 4096 246505 000000007e4a4f00(0, 94208, 1)
             3: 0 4096 246506 000000007e4a4f00(0, 94208, 1)
             4: 0 4096 246538 000000007e4a4f00(0, 94208, 2)
             5: 0 4096 246539 000000007e4a4f00(0, 94208, 2)
             6: 0 4096 246540 000000007e4a4f00(0, 94208, 2)
             7: 0 4096 246541 000000007e4a4f00(0, 94208, 2)
             8: 0 4096 246542 000000007e4a4f00(0, 94208, 2)
             9: 0 4096 246543 000000007e4a4f00(0, 94208, 2)
            10: 0 4096 246544 000000007e4a4f00(0, 94208, 2)
            11: 0 4096 246545 000000007e4a4f00(0, 94208, 2)
            12: 0 4096 246546 000000007e4a4f00(0, 94208, 2)
            13: 0 4096 246547 000000007e4a4f00(0, 94208, 2)
            14: 0 4096 246548 000000007e4a4f00(0, 94208, 2)
            15: 0 4096 246549 000000007e4a4f00(0, 94208, 2)
            16: 0 4096 246550 000000007e4a4f00(0, 94208, 2)
            17: 0 4096 246551 000000007e4a4f00(0, 94208, 2)
            18: 0 4096 246552 000000007e4a4f00(0, 94208, 2)
            19: 0 4096 246553 000000007e4a4f00(0, 94208, 2)
            20: 0 4096 246554 000000007e4a4f00(0, 94208, 2)
            21: 0 4096 246555 000000007e4a4f00(0, 94208, 2)
            22: 0 4096 246556 000000007e4a4f00(0, 94208, 2)
Kernel panic - not syncing: bad block merge

It seems segment 1 is too small and segment 2 too big?

The general plan is to disable inlining (maybe move 
blk_bio_segment_split() to a separate
function) to try to figure out what is miscompiled.

As you say, this is probably a GCC bug.  However, it's likely a 
middle-end or optimization
bug in the common GCC code.

Dave

-- 
John David Anglin  dave.anglin@bell.net


  reply	other threads:[~2016-03-09 15:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-24  2:28 [BUG] "block: make generic_make_request handle arbitrarily sized bios" breaks boot on parisc-linux John David Anglin
2016-02-24  7:59 ` Ming Lei
2016-02-24 21:36   ` Helge Deller
2016-02-24 23:28     ` John David Anglin
2016-02-25  3:38       ` Ming Lei
2016-02-25 10:10         ` Aw: " Helge Deller
2016-03-09 12:55         ` James Bottomley
2016-03-09 14:43           ` Ming Lei
2016-03-09 15:15             ` John David Anglin [this message]
2016-03-09 15:51               ` Ming Lei
2016-03-09 21:20               ` Helge Deller
2016-03-10  0:16                 ` James Bottomley
2016-03-10  7:04                 ` Rolf Eike Beer
2016-03-20 18:12                   ` Helge Deller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56E03E2A.5020208@bell.net \
    --to=dave.anglin@bell.net \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=deller@gmx.de \
    --cc=kent.overstreet@gmail.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=tom.leiming@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox