Bug 664592

(In reply to comment #0)
I was able to reproduce this on another system, will look into it.

Hi Mike, Steve,
it's very likely that this is caused by the latest patchset - update to 3.6.22 ported to RHEL5. Please look at this issue.

Created attachment 471810 [details]
fix panic in blk_rq_bytes

When the tur is sent down then in blk_rq_byte is the rq->bio = null, this causes a null pointer dereference here int nr_sectors = bio_sectors(rq->bio);

Let me know if the patch is ok for you.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Tomas, your patch attachment 471810 [details] looks fine.  For comparison, here is what we have in our CVS for the driver which we build for RHEL5 for the blk_rq_bytes function:

/**
 * blk_rq_bytes - Returns bytes left to complete in the entire request
 * @rq: the request being processed
 * this function is copied from later kernels (2.6.29-ish), where it is
 * normally defined in blk/blk-core.c
 * Slightly modified for older kernels.
 **/
static unsigned int blk_rq_bytes(struct request *rq)
{
        int nr_sectors;

        if (blk_fs_request(rq))  {
                BUG_ON(!rq->bio);
                nr_sectors = bio_sectors(rq->bio);
                return nr_sectors << 9;
        }

        return rq->data_len;
}

-- steve

(In reply to comment #7)
> Tomas, your patch attachment 471810 [details] looks fine.
Thanks Steve.
In our git the blk_rq_bytes is called only when blk_pc_request(rq) is true
so the branch 
>         if (blk_fs_request(rq))  {
>                 BUG_ON(!rq->bio);
>                 nr_sectors = bio_sectors(rq->bio);
>                 return nr_sectors << 9;
>         }
is never taken.

Maybe I could misuse the opportunity :) - could you review also the 
https://bugzilla.redhat.com/attachment.cgi?id=467508
in
https://bugzilla.redhat.com/show_bug.cgi?id=635143#c28
?

(In reply to comment #8)
> (In reply to comment #7)
> > Tomas, your patch attachment 471810 [details] looks fine.
> Thanks Steve.
> In our git the blk_rq_bytes is called only when blk_pc_request(rq) is true
> so the branch 
> >         if (blk_fs_request(rq))  {
> >                 BUG_ON(!rq->bio);
> >                 nr_sectors = bio_sectors(rq->bio);
> >                 return nr_sectors << 9;
> >         }
> is never taken.

Hmm.  This appears to be true in our driver as well.  Good catch.  Not that it hurts much as it is.  The compiler might even be smart enough to figure that out, since blk_rq_bytes is only called in one place that I see and so probably gets inlined, and those blk_xx_request() are macros iirc (that got removed in later kernels for some reason)... but might be a long shot for it to be that smart.

> 
> Maybe I could misuse the opportunity :) - could you review also the 
> https://bugzilla.redhat.com/attachment.cgi?id=467508
> in
> https://bugzilla.redhat.com/show_bug.cgi?id=635143#c28
> ?

Ok, will take a look.

-- steve

in kernel-2.6.18-241.el5
You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5

Detailed testing feedback is always welcomed.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Using the cciss driver, when a TUR (Test Unit Ready) was executed, the rq->bio pointer in the blk_rq_bytes function was of value null, which resulted in a null pointer dereference, and, consequently, kernel panic occurred. With this update, the rq->bio pointer is used only when the blk_fs_request(rq) condition is true, thus, kernel panic no longer occurs.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-1065.html