linux-kernel - Re: [PATCH] Staging: comedi: add timeouts to while loops in s626.c

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:	Mon, 3 Mar 2014 14:05:30 +0000
From:	Ian Abbott <abbotti@....co.uk>
To:	Chase Southwood <chase.southwood@...oo.com>,
	Ian Abbott <ian.abbott@....co.uk>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC:	"hsweeten@...ionengravers.com" <hsweeten@...ionengravers.com>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Staging: comedi: add timeouts to while loops in s626.c

On 2014-03-01 05:48, Chase Southwood wrote:
> On Friday, February 28, 2014 11:26 AM, Ian Abbott <abbotti@....co.uk> wrote:
>> On 2014-02-28 07:35, Chase Southwood wrote:
>>> And finally, are timeouts here even necessary or helpful, or are there
>>> any better ways to do it?
>>
>> In the case of s626_send_dac(), it doesn't seem to be used in any
>> critical sections, so it could make use of Hartley's comedi_timeout().
>>
>> Some of the timeout errors could be propagated, especially for
>> s626_send_dac() which is only reachable from very few paths.
>>
>
> Awesome, I'll swap all of my timeouts out for comedi_timeout() in s626_send_dac().
> As for propagating the timeout errors, could you please clarify that a bit further?  Both of the functions
> which I add timeouts inside of in this patch return void, and so in their current state they cannot return any error
> values.  Would you like them (or at least s626_send_dac()) to instead return an error upon timeout/or success on success,
> or am I just totally misunderstanding your meaning of propagate here?

s626_send_dac() could be changed to return an int value 0 on success or 
-ETIMEDOUT on timeout.  s626_set_dac() and s626_write_trim_dac() could 
be changed to return an int - just return the result of s626_send_dac(). 
  Similarly, the result of those functions could be either propagated 
upwards.  This could all be done in a separate patch (or patches).

>> There are other infinite loops involving calls to the s626_mc_test()
>> function, but those could be dealt with by other patches.
>
> Yeah, I saw those...I'll whip up a patch for them, just wanted to verify that everything looks pretty good here
> before I started on that.  I'll have that right out!

Yes, anything is an improvement on an infinite loop waiting for the 
hardware to do something!

-- 
-=( Ian Abbott @ MEV Ltd.    E-mail: <abbotti@....co.uk>        )=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587         )=-
--
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/