linux-kernel - Re: [PATCH 04/26] sysfs: sysfs_remove_dir stop checking for bogus cases.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 03 Jun 2009 17:41:21 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Greg KH <greg@...ah.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-kernel@...r.kernel.org, Tejun Heo <tj@...nel.org>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	linux-fsdevel@...r.kernel.org, Kay Sievers <kay.sievers@...y.org>,
	"Eric W. Biederman" <ebiederm@...stanetworks.com>
Subject: Re: [PATCH 04/26] sysfs: sysfs_remove_dir stop checking for bogus cases.

Greg KH <greg@...ah.com> writes:

> On Fri, May 29, 2009 at 01:19:14PM -0700, Eric W. Biederman wrote:
>> From: Eric W. Biederman <ebiederm@...ssion.com>
>> 
>> kobj->sd can not be NULL in sysfs_remove_dir.
>> 
>> sysfs_remove_dir is only called from kobject_add (to clean up after failure)
>> and from kobject_del at the end of a kobject's life.  In both cases kobject_add
>> has already called sysfs_create_dir successfully.  The only writers of
>> kobj->sd are sysfs_create_dir on sucess and sysfs_remove_dir when it clears
>> the kobj just before deleting the directory.
>> 
>> Which means at the time sysfs_remove_dir is called kobj->sd will be
>> valid.
>
> Yeah, we would hope so.
>
> But as we have been forced to add many checks like this into the driver
> core to handle those "no one could ever call this" type problems that
> have been springing up over time, I am hesitant to remove this check.
>
> Why do you want to remove it, what is the problem here you are trying to
> solve?

I'm cleaning up and simplifying the code.

In this particular instance the check is actually wrong.  There is no
valid code path that depends on that behavior.   Which means the test
is both useless and actively obscures the code.

Making it a BUG_ON would be valid.

The other side of it is I realized I had been running for months without
that check.  I had deleted it as an oversight.  Then when the code churn
was small enough and Tejun asked me about it.  I split this hunk out
into it's own separate patch.  As I figured  it deserved it's own patch
so the change could stand out and be reviewed.  Since my review of the code
path showed no valid use case I kept it.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/