From: Dave Hansen <haveblue@us.ibm.com>
To: Greg KH <greg@kroah.com>
Cc: "Artem B. Bityutskiy" <dedekind@infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Bug? Report] kref problem
Date: Thu, 16 Mar 2006 09:31:18 -0800 [thread overview]
Message-ID: <1142530278.10906.27.camel@localhost.localdomain> (raw)
In-Reply-To: <20060316165323.GA10197@kroah.com>
On Thu, 2006-03-16 at 08:53 -0800, Greg KH wrote:
> On Thu, Mar 16, 2006 at 02:41:19PM +0300, Artem B. Bityutskiy wrote:
> > struct my_obj_a
> > {
> > struct kobject kobj;
> > } a;
> >
> > struct my_obj_b
> > {
> > struct kobject kobj;
> > } b;
>
> Don't statically create kobjects, it's not nice. But the real problem
> is below...
This seems to be one of those top ten sysfs snafus. Could we take the
definitions from include/asm-generic/sections.h, and make a kobject
verification function to put in the critical generic kernel functions
that deal with kobjects, like kobject_init()?
Somthing like...
void verify_dynamic_kobject_allocation(struct kobject *kobj)
{
if (kobj >= &_data && kobj < &_edata)
goto warn;
if (kobj >= &_bss_start && kobj < &_bss_end)
goto warn;
...
return;
warn:
printk(KERN_WARN "statically allocated kobject, you suck...\n");
}
I'm not sure that all of the architectures fill in all of the values,
but we could at least support the warnings for the ones that do. That
includes at least i386, so it could be a relatively effective tool.
I'll cook up a real patch in a bit.
-- Dave
next prev parent reply other threads:[~2006-03-16 17:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-16 11:41 [Bug? Report] kref problem Artem B. Bityutskiy
2006-03-16 16:47 ` Greg KH
2006-03-16 16:50 ` Greg KH
2006-03-16 16:50 ` Artem B. Bityutskiy
2006-03-16 16:53 ` Greg KH
2006-03-16 17:07 ` Artem B. Bityutskiy
2006-03-16 17:10 ` Artem B. Bityutskiy
2006-03-16 17:20 ` Greg KH
2006-03-16 18:00 ` Artem B. Bityutskiy
2006-03-16 18:10 ` Greg KH
2006-03-16 17:18 ` Greg KH
2006-03-16 17:31 ` Dave Hansen [this message]
2006-03-16 17:42 ` Greg KH
2006-03-16 17:45 ` Artem B. Bityutskiy
2006-03-16 17:58 ` Greg KH
2006-03-16 18:08 ` Artem B. Bityutskiy
2006-03-16 18:20 ` Greg KH
2006-03-17 9:30 ` Artem B. Bityutskiy
2006-03-17 15:18 ` Greg KH
2006-03-17 16:34 ` Artem B. Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1142530278.10906.27.camel@localhost.localdomain \
--to=haveblue@us.ibm.com \
--cc=dedekind@infradead.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox