linux-kernel - Re: I2C: Fix i2c fail problem when a process is terminated by a signal on octeon in 3.8

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>] [day] [month] [year] [list]

Message-ID: <512D4042.7060303@caviumnetworks.com>
Date:	Tue, 26 Feb 2013 15:07:46 -0800
From:	David Daney <ddaney@...iumnetworks.com>
To:	<eunb.song@...sung.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"david.daney@...ium.com" <david.daney@...ium.com>
Subject: Re: I2C: Fix i2c fail problem when a process is terminated by a signal
 on octeon in 3.8

On 02/26/2013 12:54 PM, 송은봉 wrote:
> I've been debugging the abnormal operation of i2c on octeon.
> If a process is terminated by signal in the middle of i2c operation,
> next i2c read operation which is done by another process was failed.
> So i changed to ignore signal in the middle of i2c operation.
> After that the problem was not reproduced.
> 

This is a known issue.  However I don't think the solution you have is
correct...

> Signed-off-by: EunBong Song <eunb.song@...sung.com 
> <mailto:eunb.song@...sung.com>>
> 
> diff -up drivers/i2c/busses/i2c-octeon.c{.orig,}
> --- drivers/i2c/busses/i2c-octeon.c.orig 2013-02-21 08:09:03.168018843 -0800
> +++ drivers/i2c/busses/i2c-octeon.c 2013-02-21 08:09:38.344018898 -0800
> @@ -183,7 +183,7 @@ static irqreturn_t octeon_i2c_isr(int ir
>    struct octeon_i2c *i2c = dev_id;
> 
>    octeon_i2c_int_disable(i2c);
> - wake_up_interruptible(&i2c->queue);
> + wake_up(&i2c->queue);
> 
>    return IRQ_HANDLED;
>   }
> @@ -206,7 +206,7 @@ static int octeon_i2c_wait(struct octeon
> 
>    octeon_i2c_int_enable(i2c);
> 
> - result = wait_event_interruptible_timeout(i2c->queue,
> + result = wait_event_timeout(i2c->queue,

If the wait is not interruptible, I think you will not be able to 'kill
-9' a userspace process blocked here.

>           octeon_i2c_test_iflg(i2c),
>           i2c->adap.timeout);
> 

The real solution is to move processing of the I2C protocol to a kernel
thread and communicate between the this thread and userspace via a
command queue mechanism, much like the way it is done in the mmc/host
driver infrastructure.

David Daney



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