From: eran liberty <eran.liberty@gmail.com>
To: Greg KH <gregkh@suse.de>
Cc: balajirrao@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: kobjects: mark cleaned up kobjects as unitialized
Date: Wed, 25 Nov 2009 16:27:59 +0200 [thread overview]
Message-ID: <ffc2b1d40911250627q6c7e459v89a580d793b24fcf@mail.gmail.com> (raw)
In-Reply-To: <20091125123534.GA17486@suse.de>
Hi Greg,
On Wed, Nov 25, 2009 at 2:35 PM, Greg KH <gregkh@suse.de> wrote:
> On Wed, Nov 25, 2009 at 11:27:58AM +0200, eran liberty wrote:
>> Hi Greg & Balaji,
>>
>> After diving into the LDKM and failed to spot the point where you
>> actually un-initialize the 'state_initialized' of a kobject... and
>> since I have statically allocated object which trip over this very
>> same trap...
>
> Ah, there's your problem, don't statically allocate a kobject. Fix that
> and your issue goes away, right?
right... but... I want to :).
Is there a Linux directive saying 'thus shall not statically allocate
(or reuse in any other way) kobjects"?
>
>> Google-ing for others who fell into this trap, I found your thread/patch at:
>> http://lkml.org/lkml/2008/3/8/155
>> and
>> http://lkml.indiana.edu/hypermail/linux/kernel/0902.0/01969.html
>>
>> I noticed this patch did not make it into the mainline.
>>
>> Is this patch still valid?
Why was your proposed patch not merged?
Is there some logic behind not having it?
>> Is there some other, better way to do it by the book?
>
> Do not statically allocate a kobject.
>
>> Right now I by-pass the problem by memset-ing the whole object after I
>> release it... but I feel this is a bit brutal.
Assuming I will keep it static and clear the status_initialize bit (by
memset-ing the whole object) after the kobject was released... am I
doing something wrong? should i expect other bad phenomena?
>
> You should be freeing your memory in your release function.
>
Should I free the object itself in release() function?
In OO-like thinking I would expect release() to be a cleanup function
for the device to be used, while the kfree() be done by the same
object which did the kmalloc()
> Do you have a pointer to your code somewhere?
>
I will pack something and send you (i dont think Mr. vger will
tolerate attachments :) )
but basically you can demonstrate the problem with this simple code:
struct device dev;
while(1) {
dev->release = dummy_release_function_that_does_nothing;
device_register(&dev); /* will fail on second iteration without the
memset!! ?? */
device_unregister(&dev);
memset(&dev,0,sizeof(struct device)); /* should be unnecessary */
}
> thanks,
>
> greg k-h
>
thanks,
-- Liberty
next prev parent reply other threads:[~2009-11-25 14:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-25 9:27 eran liberty
2009-11-25 12:35 ` Greg KH
2009-11-25 14:27 ` eran liberty [this message]
2009-11-25 15:27 ` Greg KH
2009-11-25 15:41 ` Greg KH
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=ffc2b1d40911250627q6c7e459v89a580d793b24fcf@mail.gmail.com \
--to=eran.liberty@gmail.com \
--cc=balajirrao@gmail.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®