Messages in this thread | | | Date | Sat, 30 Nov 2013 09:25:33 -0800 | Subject | Re: [3.10] Oopses in kmem_cache_allocate() via prepare_creds() | From | Linus Torvalds <> |
| |
On Sat, Nov 30, 2013 at 1:43 AM, Simon Kirby <sim@hostway.ca> wrote: > On Tue, Nov 26, 2013 at 03:16:09PM -0800, Linus Torvalds wrote: >> >> The pipe-info structure isn't using its own slab cache, it's just >> using "kmalloc()". So it by definition will merge with all other >> kmalloc() allocations of the same size (or, to be exact, of "similar >> enough size to hit the same size bucket"). In your case it's the >> 192-byte-sized bucket. > > I turned on kmalloc-192 tracing to find what else is using it: struct > nfs_fh, struct bio, and struct cred. Poking around those, struct bio has > bi_cnt, but it is way down in the struct. struct cred has "usage", but it > comes first. Hmm. Nevertheless, I set: > > CONFIG_DEBUG_MUTEXES=y > CONFIG_DEBUG_LIST=y > CONFIG_DEBUG_CREDENTIALS=y > > And tried: > > diff --git a/include/linux/cred.h b/include/linux/cred.h > index 04421e8..2646fe9 100644 > --- a/include/linux/cred.h > +++ b/include/linux/cred.h > @@ -205,7 +205,9 @@ static inline void validate_process_creds(void) > */ > static inline struct cred *get_new_cred(struct cred *cred) > { > - atomic_inc(&cred->usage); > + if (atomic_inc_return(&cred->usage) == 0x6c) { > + WARN_ON(cred->uid == 0x6b);
Oh, damn, I thought you had found it, and got very excited and already wrote a long email about things I wanted you to try. And then I started looking closer...
That test is wrong. Both of those fields are 32-bit, so testing them against 0x6b/0x6c is bogus: you're just catching real cases. The reason it catches omreport is presumably because omreport runs as some special user that happens to have uid 107 (on my machine that happens to be qemu). And having a usage count of 108 isn't particularly strange either - creds get a lot of re-use.
So close. It *might* still be one of those cases, but it doesn't really sound very likely. "bi_cnt" is deep inside the struct bio, and "usage" is at offset 0, not offset 4. And the ns_fh isn't very interesting.
Linus
| |