lkml.org 
[lkml]   [2013]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [3.10] Oopses in kmem_cache_allocate() via prepare_creds()
From
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


\
 
 \ /
  Last update: 2013-11-30 18:41    [W:0.240 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site