lkml.org 
[lkml]   [2009]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: post 2.6.28 regression: device_initialize() now sleeps, and may fail without recovery strategy
On Fri, Jan 09, 2009 at 07:35:42PM +0100, Stefan Richter wrote:
> >From commit 2831fe6f9cc4e16c103504ee09a47a084297c0f3, "driver core:
> create a private portion of struct device":
>
> void device_initialize(struct device *dev)
> {
> + dev->p = kzalloc(sizeof(*dev->p), GFP_KERNEL);
> + if (!dev->p) {
> + WARN_ON(1);
> + return;
> + }
> + dev->p->device = dev;
> dev->kobj.kset = devices_kset;
> kobject_init(&dev->kobj, &device_ktype);
>
>
> First of all, this prevents initialization of struct device in atomic
> contexts, such as drivers/firewire/fw-device.c::fw_node_event.

Ick, sorry, I didn't think that any callers ever did this.

> This is a bug in current mainline.
>
> We can fix the bug by changing firewire-core, but
> a) it'd be more than a one-liner,
> b) who knows which other subsystems are affected.

I agree.

I originally looked at changing this to be at device_add time, but I
think there are some code paths that do device_initialize and then do
some operations on the device before calling device_add. But I could be
wrong, let me do some testing first before forcing you to make that big
change to the firewire core.

> Next, the above code is bogus. In 2.6.28, device_initialize() could
> never fail and was thus safe to use as a void-valued function.
>
> How does driver core handle dev->p == NULL in subsequent usages of dev now?

It dies a flaming horrible death, pretty much like the whole rest of the
system if allocating such a small ammount of memory is causing failures
:)

Give me a few hours to test here, your change might not be necessary...

thanks,

greg k-h


\
 
 \ /
  Last update: 2009-01-09 22:01    [W:0.129 / U:0.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site