linux-kernel - Re: Why is device_create_file __must

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 9 Oct 2006 22:04:53 -0700
From:	Greg KH <greg@...ah.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	Paul Mackerras <paulus@...ba.org>, linux-kernel@...r.kernel.org
Subject: Re: Why is device_create_file __must_check?

On Mon, Oct 09, 2006 at 09:49:36PM -0700, Andrew Morton wrote:
> On Tue, 10 Oct 2006 14:32:33 +1000
> Paul Mackerras <paulus@...ba.org> wrote:
> 
> > I am seeing a bunch of warnings about not checking the return value
> > from device_create_file() for code like this (from
> > arch/powerpc/kernel/pci_64.c):
> > 
> > static ssize_t pci_show_devspec(struct device *dev,
> > 		struct device_attribute *attr, char *buf)
> > {
> > 	struct pci_dev *pdev;
> > 	struct device_node *np;
> > 
> > 	pdev = to_pci_dev (dev);
> > 	np = pci_device_to_OF_node(pdev);
> > 	if (np == NULL || np->full_name == NULL)
> > 		return 0;
> > 	return sprintf(buf, "%s", np->full_name);
> > }
> > static DEVICE_ATTR(devspec, S_IRUGO, pci_show_devspec, NULL);
> > 
> > void pcibios_add_platform_entries(struct pci_dev *pdev)
> > {
> > 	device_create_file(&pdev->dev, &dev_attr_devspec);
> > }
> > 
> > What bad thing could happen if device_create_file fails, other than
> > that the "devspec" file doesn't appear in sysfs?
> 
> There are no super-strong reasons here, but if device_create_file() fails
> then the required control files aren't there and the subsystem isn't
> working as intended.  If it's in a module then we should fail the modprobe. 
> If it's a bootup thing then best we can do is to panic.  Or at least log
> the event.
> 
> The most common cause of this is a programming error: we tried to create
> the same entry twice.   We want to know about that.

Exactly, that's the most common cause here (different programmers trying
to create the same file in the same place.)  That needs to error out so
that it is caught properly.

thanks,

greg k-h
-
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/