linux-kernel - Re: [PATCH RFC] i2c: octeon: allow receiving of signals.

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: <20150611135519.GA28420@opentech.at>
Date:	Thu, 11 Jun 2015 15:55:19 +0200
From:	Nicholas Mc Guire <der.herr@...r.at>
To:	Wolfram Sang <wsa@...-dreams.de>
Cc:	Nicholas Mc Guire <hofrat@...dl.org>, linux-i2c@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] i2c: octeon: allow receiving of signals.

On Thu, 11 Jun 2015, Wolfram Sang wrote:

> On Thu, Jun 11, 2015 at 03:23:52PM +0200, Nicholas Mc Guire wrote:
> > Change wait_event_timeout() to wait_event_interruptible_timeout() allowing
> > signals to be received while waiting on event (task state set to 
> > TASK_INTERRUPTIBLE) as the dev_dbg() string indicates that signals
> > are expected to be possible. While at it fix the type to long (as returned
> > by schedule_timeout(). 
> > 
> > Signed-off-by: Nicholas Mc Guire <hofrat@...dl.org>
> > ---
> > 
> > From the dev_dbg string "wait interrupted" it seems that interrupts are
> > expected to be on - so most likely this should be
> > wait_event_interruptible_timeout() and not wait_event_timeout() as the
> > later return >= 0 always and sets the task state to TASK_UNINTERRUPTIBLE.
> > Someone that knows the details of this driver needs to confirm this though.
> 
> Use 'git log drivers/i2c/busses/i2c-octeon.c' and you will find commit
> 2637e5fd232d421b680757944f613d4b1a36ae26 which disabled the signals.
> For further digging, you could do
> 'git log --grep="interruptible" drivers/i2c/busses' to find that signals
> cause a lot of problems with i2c transactions.
> 
> Summary: The code still handling signal code simply needs to go.
>
thanks - the output of 'git log --grep="interruptible" drivers/i2c/busses' 
really make it very clear - sorry for the noise - I had only been looking at
the code of this driver to figure out how to resolve the obvious API
inconsistency but did not check the broader scope.

will fix it up and resend.

thx!
hofrat
--
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/