On Sat, Nov 30, 2013 at 09:25:33AM -0800, Linus Torvalds wrote: > On Sat, Nov 30, 2013 at 1:43 AM, Simon Kirby <s...@hostway.ca> wrote: > > > 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.
*head smack* Too much 8-bit AVR coding... Makes sense now: uid=107(nagios) gid=109(nagios) groups=109(nagios) Well, the chances of atomic_inc intentionally incrementing 0x6b6b6b6b are probably pretty rare. I'll try that. Simon- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/