linux-kernel - Re: Strange block/scsi/workqueue issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 Apr 2011 17:04:26 +0100
From:	Steven Whitehouse <swhiteho@...hat.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org,
	Jens Axboe <jaxboe@...ionio.com>
Subject: Re: Strange block/scsi/workqueue issue

Hi,

On Tue, 2011-04-12 at 10:14 -0500, James Bottomley wrote:
> On Tue, 2011-04-12 at 15:06 +0100, Steven Whitehouse wrote:
> > Messages attached - getting closer I think, but still not quite there.
> > It is very odd that so far (at least I've seen no other reports) that I
> > seem to be the only one who hits this. I wonder what is different about
> > my kernel/hardware...
> 
> 
> > csi: killing requests for dead queue
> > scsi: killing requests for dead queue
> > BUG: unable to handle kernel scsi: killing requests for dead queue
> > NULL pointer dereference at 0000000000000028
> > IP: [<ffffffff813b34ed>] blk_peek_request+0x1ad/0x220
> 
> Hmm, I don't see where this is ... it's a null pointer deref offset by
> 0x28 bytes ... but I can't see where ... can you resolve this to a line?
> 
> James
> 
> 

So assuming I've calculated this correctly, it should be just about....

/home/steve/linux-2.6/include/linux/rcupdate.h:677
    6de8:       a8 08                   test   $0x8,%al
    6dea:       0f 84 65 ff ff ff       je     6d55 <blk_peek_request+0xf5>
    6df0:       e8 00 00 00 00          callq  6df5 <blk_peek_request+0x195>
                        6df1: R_X86_64_PC32     preempt_schedule-0x4
    6df5:       e9 5b ff ff ff          jmpq   6d55 <blk_peek_request+0xf5>
    6dfa:       66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)
__elv_next_request():
/home/steve/linux-2.6/block/blk.h:65
                if (!list_empty(&q->queue_head)) {
                        rq = list_entry_rq(q->queue_head.next);
                        return rq;
                }

                if (!q->elevator->ops->elevator_dispatch_fn(q, 0))
    6e00:       49 8b 44 24 18          mov    0x18(%r12),%rax
    6e05:       31 f6                   xor    %esi,%esi
    6e07:       48 8b 00                mov    (%rax),%rax
    6e0a:       4c 89 e7                mov    %r12,%rdi                              <---- here!
    6e0d:       ff 50 28                callq  *0x28(%rax)
    6e10:       85 c0                   test   %eax,%eax
    6e12:       0f 85 f4 fe ff ff       jne    6d0c <blk_peek_request+0xac>
    6e18:       45 31 ed                xor    %r13d,%r13d
    6e1b:       e9 70 ff ff ff          jmpq   6d90 <blk_peek_request+0x130>
blk_peek_request():
/home/steve/linux-2.6/block/blk-core.c:1912
                                 * so that we don't add it again
                                 */

The offset I got was 6e0d, but I guess thats the start of the following instruction
by the time the fault is logged. Also I've attached my current .config just in case
that might be a help is reproducing it,

Steve.


View attachment "test.config" of type "text/x-mpsub" (87255 bytes)