linux-kernel - Re: [Alsa-devel] [PATCH] Driver core: Don't ignore error returns from probing

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:	Fri, 6 Oct 2006 14:12:49 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Cornelia Huck <cornelia.huck@...ibm.com>
cc:	Jaroslav Kysela <perex@...e.cz>, Andrew Morton <akpm@...l.org>,
	ALSA development <alsa-devel@...a-project.org>,
	Takashi Iwai <tiwai@...e.de>, Greg KH <gregkh@...e.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Jiri Kosina <jikos@...os.cz>,
	Castet Matthieu <castet.matthieu@...e.fr>
Subject: Re: [Alsa-devel] [PATCH] Driver core: Don't ignore error returns
 from probing

On Fri, 6 Oct 2006, Cornelia Huck wrote:

> On Fri, 6 Oct 2006 11:41:05 +0200 (CEST),
> Jaroslav Kysela <perex@...e.cz> wrote:
> 
> > > Hm, I don't think we should call device_release_driver if
> > > bus_attach_device failed (and I think calling bus_remove_device if
> > > bus_attach_device failed is unintuitive). I did a patch that added a
> > > function which undid just the things bus_add_device did (here:
> > > http://marc.theaimsgroup.com/?l=linux-kernel&m=115816560424389&w=2),
> > > which unfortunately got lost somewhere... (I'll rebase and resend.)

I'm still not sure why bus_attach_device() was split off from 
bus_add_device() in the first place.  Was it just so that the 
kobject_uevent() call could go in between?

Is there any reason they couldn't be recombined into a single function?

> > Yes, but it might be better to check dev->is_registered flag in 
> > bus_remove_device() before device_release_driver() call to save some code, 
> > rather than reuse most of code in bus_delete_device().

Agreed; I don't like the duplication of code.  It's wasteful and 
error-prone (somebody might change one routine and not the other).

> If we undid things (symlinks et al.) in the order we added them, we can
> factor out bus_delete_device() from bus_remove_device() and avoid both
> code duplication and calling bus_remove_device() if bus_attach_device()
> failed. Something like the patch below (untested).

This looks okay, but it would be better if bus_remove_device() did not
directly call bus_delete_device().  Just add an extra call inside
device_del(), so that everything remains symmetrical.

While I'm harping on style issues, you should also capitalize AttachError
so that it matches the form of the other statement labels nearby.  And in
bus_remove_device() you should put all the code inside the "if" block
instead of returning when dev->bus isn't set, just as the neighboring
subroutines do.

Alan Stern

-
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/