linux-kernel - Re: 2.6.30-rc6: Reported regressions from 2.6.29

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] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 16 May 2009 19:13:59 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Kay Sievers <kay.sievers@...y.org>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Natalie Protasevich <protasnb@...il.com>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: 2.6.30-rc6: Reported regressions from 2.6.29

On Sun, 17 May 2009, Kay Sievers wrote:
> 
> This makes the oops in the driver-core, caused by the rtc driver
> unregister, go away. The original issue is also fixed in the rtc driver
> itself.

I don't think this is sufficient.

> --- a/drivers/base/driver.c
> +++ b/drivers/base/driver.c
> @@ -257,6 +257,8 @@ EXPORT_SYMBOL_GPL(driver_register);
>   */
>  void driver_unregister(struct device_driver *drv)
>  {
> +	if (!drv || !drv->p)
> +		return;
>  	driver_remove_groups(drv, drv->groups);
>  	bus_remove_driver(drv);
>  }

Ok, fine so far, but look at "driver_register()".

It will set drv->p, but then not unset it if it fails! (For a certain 
class of failures)

So for a certain failure pattern, drv->p will point to some stale value. 
Should we not clear drv->p in the "out_unregister" patch?

To confuse the thing more, there are actually "half-way failures" that 
_succeed_ in driver registration, but then return an error code. See that 
whole

	kobject_uevent(&priv->kobj, KOBJ_ADD);
	return error;

case in the "success" path driver_register(). We may return an error 
despite the fact that we actually attached the driver to bus, but 
"add_bind_files()" failed. A caller would be understandable very unhappy.

So I suspect we should do something like the appended (in addition to your 
patch). Comments?

			Linus
---

 drivers/base/bus.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index dc030f1..dcd499d 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -700,8 +700,9 @@ int bus_add_driver(struct device_driver *drv)
 	}

 	kobject_uevent(&priv->kobj, KOBJ_ADD);
-	return error;
+	return 0;
 out_unregister:
+	drv->p = NULL;
 	kobject_put(&priv->kobj);
 out_put_bus:
 	bus_put(bus);
--
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/