From: Greg KH <greg@kroah.com>
To: Chuck Ebbert <76306.1226@compuserve.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] kobject: don't oops on null kobject.name
Date: Fri, 13 Jan 2006 19:44:04 -0800 [thread overview]
Message-ID: <20060114034404.GA23061@kroah.com> (raw)
In-Reply-To: <200601132209_MC3-1-B5D3-F9A9@compuserve.com>
On Fri, Jan 13, 2006 at 10:07:33PM -0500, Chuck Ebbert wrote:
> In-Reply-To: <20060114000246.GA7549@kroah.com>
>
> On Fri, 13 Jan 2006, Greg KH wrote:
>
> > Hm, I looked at the only user of kobjects in the kernel that I know of
> > that doesn't use sysfs (the cdev code) and even it sets the kobject name
> > to something sane, so I think we should be safe with this.
>
> Well, something is still wrong.
>
> I applied your patch to prevent registration of objects with null names on
> top of my patch, then applied this to see if my test still triggered, and
> the message was printed:
What was the message? What traceback?
So, I think the point is that it isn't a kobject_add() issue, right?
>
>
> --- 2.6.15a.orig/lib/kobject.c
> +++ 2.6.15a/lib/kobject.c
> @@ -72,8 +72,10 @@ static int get_kobj_path_length(struct k
> * Add 1 to strlen for leading '/' of each level.
> */
> do {
> - if (kobject_name(parent) == NULL)
> + if (kobject_name(parent) == NULL) {
> + printk("get_kobj_path_length: encountered NULL name\n");
> return 0;
> + }
> length += strlen(kobject_name(parent)) + 1;
> parent = parent->parent;
> } while (parent);
>
>
> To reproduce:
>
> Start with vanilla 2.6.15 and apply the three patches, which I called:
>
> kobject_dont_register_null_name.patch <- my original
> kobject_handle_null_object_name.patch <- Greg's
> kobject_debug_null_path.patch <- included above
>
> On a machine with an ATAPI CD-ROM, boot with "hdx=ide-scsi" where
> hdx is the CD-ROM's drivename. Then try to mount a CD:
>
> mount -t iso9660 /dev/hdx /mnt/cdrom
>
> Note that hdx is being controlled by ide-scsi so this should fail. You
> will see the message from my new patch print in the kernel log.
>
> NOTE: This won't happen on 2.6.15-current because
> fs/super.c::kill_block_super() no longer calls kobject_uevent().
So everything's fixed and we don't have to worry about it anymore :)
Seriously, I agree, we still need to fix it for -stable.
thanks,
greg k-h
next prev parent reply other threads:[~2006-01-14 3:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-14 3:07 [patch] kobject: don't oops on null kobject.name Chuck Ebbert
2006-01-14 3:44 ` Greg KH [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-02-06 20:29 [PATCH] SPI: spi_butterfly, restore lost deltas Greg KH
2006-02-06 20:29 ` [PATCH] kobject: don't oops on null kobject.name Greg KH
2006-01-14 16:18 [patch] " Chuck Ebbert
2006-01-14 3:07 Chuck Ebbert
2006-01-13 1:02 Chuck Ebbert
2006-01-13 22:30 ` Andrew Morton
2006-01-13 22:55 ` Greg KH
2006-01-13 23:12 ` Andrew Morton
2006-01-14 0:02 ` 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=20060114034404.GA23061@kroah.com \
--to=greg@kroah.com \
--cc=76306.1226@compuserve.com \
--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 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.