linux-kernel - Re: Locking in the (now generic) GPIO infrastructure?

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 Jun 2008 11:28:58 +0100
From:	Ben Dooks <ben-linux@...ff.org>
To:	Leon Woestenberg <leon.woestenberg@...il.com>
Cc:	LAK <linux-arm-kernel@...ts.arm.linux.org.uk>,
	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: Locking in the (now generic) GPIO infrastructure?

On Wed, Jun 04, 2008 at 01:00:19PM +0200, Leon Woestenberg wrote:
> Hello,
> 
> compare void gpio_line_set() in
> 
> arch/arm/plat-iop/gpio.c:
> void gpio_line_set(int line, int value)
> {
> 	unsigned long flags;
> 
> 	local_irq_save(flags);
> 	if (value == GPIO_LOW) {
> 		*IOP3XX_GPOD &= ~(1 << line);
> 	} else if (value == GPIO_HIGH) {
> 		*IOP3XX_GPOD |= 1 << line;
> 	}
> 	local_irq_restore(flags);
> }
> 
> with
> 
> include/asm-arm/arch-ixp4xx/platform.h:
> static inline void gpio_line_set(u8 line, int value)
> {
> 	if (value == IXP4XX_GPIO_HIGH)
> 	    *IXP4XX_GPIO_GPOUTR |= (1 << line);
> 	else if (value == IXP4XX_GPIO_LOW)
> 	    *IXP4XX_GPIO_GPOUTR &= ~(1 << line);
> }

Yes, that looks rather buggy to me, and also sub-optimal to boot. The
u8 line should be changed to just 'unsigned' having the compiler truncate
to 8bit isn't useful when then used with a shift.

static inline void gpio_line_set(unsigned line, int value)
{
	unsigned long flags;
	unsigned regval;

	local_irq_save(flags);

	regval = *IXP4XX_GPIO_GPOUTR;

	if (value == IXP4XX_GPIO_HIGH)
		regval |= (1 << line);
	else if (value == IXP4XX_GPIO_LOW)
	   	regval &= ~(1 << line);

	*IXP4XX_GPIO_GPOUTR = regval;
	local_irq_restore(flags);
}
 
> Under a Linux kernel where multiple drivers are accessing GPIO, the
> latter does not seem safe against preemption (assuming the memory
> read-modify-write is not atomic).
> 
> Shouldn't GPIO access be protected against concurrent access here?
> 
> Documentation/gpio.txt does not really mention the locking mechanism
> assumed to modify GPIO lines.

I think it depends on whether gpiolib is being used or not, there may
be some locking in there.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

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