[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080421.133940.52972455.davem@davemloft.net>
Date: Mon, 21 Apr 2008 13:39:40 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: torvalds@...ux-foundation.org
Cc: rjw@...k.pl, linux-kernel@...r.kernel.org, mingo@...e.hu,
akpm@...ux-foundation.org, linux-ext4@...r.kernel.org,
herbert@...dor.apana.org.au, paulmck@...ibm.com,
jirislaby@...il.com
Subject: Re: 2.6.25-git2: BUG: unable to handle kernel paging request at
ffffffffffffffff
From: Linus Torvalds <torvalds@...ux-foundation.org>
Date: Mon, 21 Apr 2008 09:54:07 -0700 (PDT)
> What I find interesting is that at least for me, I have the SLAB bucket
> size for nf_conntrack_expect being 208 bytes. And the *biggest* merge by
> far after 2.6.25 so far has been networking (and conntrack in particular)
>
> Is that a smoking gun? Not necessarily. But it *is* intriguing. But there
> are other possible clashes (the 192-byte bucket has several different
> suspects, and not all of them are in networking).1
I think you might be onto something here.
The "mask" member of struct nf_conntrack_expect could be reasonably
all 1's like the value reported in the crash that begins this
thread.
Do we know the offset within the object at which this all 1's
value is found?
My rough calculations show that on 32-bit that expect->mask member is
at offset 56 and on 64-bit it should be at offset 72. Does that
match up to the offset of the filp or whatever bit being corrupted?
I'll scan through the netfilter changesets in post 2.6.25 to see if
anything stands out.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists