From: Greg KH <greg@kroah.com>
To: Dave Hansen <haveblue@us.ibm.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:42:54 -0800 [thread overview]
Message-ID: <20060316174254.GA6698@kroah.com> (raw)
In-Reply-To: <1142530278.10906.27.camel@localhost.localdomain>
On Thu, Mar 16, 2006 at 09:31:18AM -0800, Dave Hansen wrote:
> 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()?
I wish. The main offender of this is the kernel core code itself, with
the decl_subsys and struct bus stuff. If you provide some nice fuctions
to fix those up to be dynamic, then I would have no problem with the
function you have below.
> 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.
That would be fun to play with, I'd appreciate it. If nothing else,
I'll add it to my tree for future use.
thanks,
greg k-h
next prev parent reply other threads:[~2006-03-16 17:43 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
2006-03-16 17:42 ` Greg KH [this message]
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=20060316174254.GA6698@kroah.com \
--to=greg@kroah.com \
--cc=dedekind@infradead.org \
--cc=haveblue@us.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.