On Thu, Mar 22, 2012 at 7:39 AM, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, Mar 21, 2012 at 11:32:14PM -0700, Dan Williams wrote:
[..]
>> diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
>> index 7fdf6a7..86521ee 100644
>> --- a/fs/sysfs/dir.c
>> +++ b/fs/sysfs/dir.c
>> @@ -714,6 +714,9 @@ int sysfs_create_dir(struct kobject * kobj)
>> else
>> parent_sd = &sysfs_root;
>>
>> + if (!parent_sd)
>> + return -ENOENT;
>> +
>> if (sysfs_ns_type(parent_sd))
>> ns = kobj->ktype->namespace(kobj);
>> type = sysfs_read_ns_type(kobj);
>
> So what happens if this is true? Does this patch fix the oops?
This patch downgrades the oops by turning it into a device_add()
failure, but the patches that *fix* this warning are here [1] and here
[2].
> What kernels should this be applied to where this problem has been seen?
I assume this has been a latent problem ever since scsi async scanning
was added (2.6.20-rc2), but it's a rare corner case to unplug devices
during the initial scan.
>> diff --git a/lib/kobject.c b/lib/kobject.c
>> index c33d7a1..e5f86c0 100644
>> --- a/lib/kobject.c
>> +++ b/lib/kobject.c
>> @@ -192,13 +192,14 @@ static int kobject_add_internal(struct kobject *kobj)
>>
>> /* be noisy on error issues */
>> if (error == -EEXIST)
>> - printk(KERN_ERR "%s failed for %s with "
>> + pr_err("%s failed for %s with "
>> "-EEXIST, don't try to register things with "
>> "the same name in the same directory.\n",
>> __func__, kobject_name(kobj));
>> else
>> - printk(KERN_ERR "%s failed for %s (%d)\n",
>> - __func__, kobject_name(kobj), error);
>> + pr_err("%s failed for %s (error: %d parent: %s)\n",
>> + __func__, kobject_name(kobj), error,
>> + parent ? kobject_name(parent) : "'none'");
>> dump_stack();
>> } else
>> kobj->state_in_sysfs = 1;
>
> These changes have nothing to do with the above fix, so why include them
> here?
It wasn't until I realized which 'parent' and which 'child' were
interacting that I was able to identify the real fixes. Since it was
helpful for the scsi/sas case, I decided to leave the more informative
warning for the next person that gets to debug a similar failure.
> And note, I hate pr_err(), what's wrong with printk() in this instance?
This is a bit circuitous, but extending the warning to include the
'parent' and 'child' pushed up against 80 columns and since this
routine has a pr_debug() a few lines up I thought a pr_ conversion was
acceptable. The pr_err() conversion of the EEXIST case just came
along for the ride to keep the print style consistent (at least in
this routine).
--
Dan
[1]: http://marc.info/?l=linux-scsi&m=133239707903443&w=2
[2]: http://marc.info/?l=linux-scsi&m=133239709603452&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
