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:	Wed, 29 Oct 2014 17:36:57 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Jeff Epler <jepler@...ythonic.net>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>,
	"open list:PCI SUBSYSTEM" <linux-pci@...r.kernel.org>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: incompatible pci sysfs change since 3.12 (5136b2da770d)

On Wed, Oct 29, 2014 at 07:22:58PM -0500, Jeff Epler wrote:
> Hi.
> 
> I am an author of LinuxCNC, a GPL'd CNC control for Linux.
> 
> Recently we added support for userspace PCI drivers.  This worked with
> kernel 3.2 but doesn't with kernel 3.16.  The software fails early with
>     Failed to open "/sys/devices/pci0000:00/.../enable" (Permission denied)
> 
> This appears to be because our software relies on the documented
> "enable" sysfs file for pci devices (Documentation/filesystem/sysfs-pci.txt)
> which was (unintentionally?) changed to "enabled" in the above-named
> patch:
> 
> 5136b2da770d PCI: convert bus code to use dev_groups
> ...
> +static DEVICE_ATTR_RW(enabled);
> ...
> -   __ATTR(enable, 0600, is_enabled_show, is_enabled_store),
> 
> Are we in the LinuxCNC project wrong in thinking that stuff in /sys (and
> not /sys/debug) is supposed to be a durable API/interface for userspace
> to the kernel?  (It must be a low-usage API if it went unnoticed for a
> year :-/)

Ugh, that's my fault, I made a typo and should not have renamed the
sysfs file, very sorry about that.

I'll work on making up a patch to fix this and get it into the stable
kernels so that you don't have to have a work-around for very long.

> We'll have to work around it by modifying our software (since we'd like
> to work with the kernels people already have) in any case.
> 
> Even if it is not going to be changed compatibly with older kernels, it
> seems like the documentation should be updated!

I'll fix it up, this was just a bug, my apologies.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ