linux-kernel - RE: [PATCH] gpio/gpio-sysfs: Try to export busy GPIO line leads to wrong GPIO line exporting

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]

Message-ID: <74CDBE0F657A3D45AFBB94109FB122FF1740805E7F@HQMAIL01.nvidia.com>
Date:	Tue, 15 Nov 2011 13:14:25 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Denis Kuzmenko <linux@...onet.org.ua>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] gpio/gpio-sysfs: Try to export busy GPIO line leads to
 wrong GPIO line exporting

Denis Kuzmenko wrote at Tuesday, November 15, 2011 1:24 PM:
> On 11/15/2011 01:14 AM, Denis Kuzmenko wrote:
> > On 11/14/2011 10:45 PM, Stephen Warren wrote:
> >> Denis Kuzmenko wrote at Saturday, November 12, 2011 6:31 PM:
> >
> > Looks like userspace doesn't retries write. Here is trace:
> >
> > open("/sys/class/gpio/export", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
> > ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbef76c64) = -1 ENOTTY (Inappropriate ioctl for device)
> > brk(0x30e000)                           = 0x30e000
> > write(3, "37\n", 3)                     = -1 EBUSY (Device or resource busy)
> > close(3)                                = 0
> > exit(0)                                 = ?
> >
> > this was made by simple self-written program:
> > 	fopen("/sys/class/gpio/export", "w"); fprintf(fp, "37\n");
> 
> That was userspace - problem in not reproducible with a code above.
> The only way I know to reproduce is:
> echo 37 > /sys/class/gpio/export
> 
> Traces are generated:
> 
...
> stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=21200, ...}) = 0

Hmmm. I'd be tempted to look at the stdio implementation in uClibc first, or
possibly the shell you're running.

> write(1, "37\n", 3)                     = -1 EBUSY (Device or resource busy)
> write(1, "3", 1)                        = -1 EBUSY (Device or resource busy)
> write(1, "3", 1)                        = -1 EBUSY (Device or resource busy)

My ARM system running some random build of Debian Wheezy doesn't repro
that; I see the first write() fail, and then no more writes are attempted.

For the record, I tried GPIO 570 (an invalid value), and got back
-EINVAL, and GPIO 57 (a valid but already requested GPIO) and got back
-EBUSY. Both had the same behavior.

-- 
nvpublic

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