linux-kernel - Re: [PATCH 2/2] watchdog: core: Fix watchdog_init

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]

Date:	Tue, 26 Nov 2013 11:51:49 -0800
From:	Guenter Roeck <linux@...ck-us.net>
To:	Doug Anderson <dianders@...omium.org>
CC:	Wim Van Sebroeck <wim@...ana.be>,
	Fabio Porcedda <fabio.porcedda@...il.com>,
	Sachin Kamat <sachin.kamat@...aro.org>,
	linux-watchdog@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] watchdog: core: Fix watchdog_init_timeout() when
 invalid param / valid dt

On 11/26/2013 11:23 AM, Doug Anderson wrote:
> Guenter,
>
> Thanks for your reviews!
>
> On Tue, Nov 26, 2013 at 10:58 AM, Guenter Roeck <linux@...ck-us.net> wrote:
>> On 11/26/2013 10:22 AM, Doug Anderson wrote:
>>>
>>> There was a minor bug in watchdog_init_timeout() where it would return
>>> an error code if someone specified an invalid parameter on the
>>> command line but then there was a valid parameter in the device tree
>>> as "timeout-sec".
>>>
>>> Signed-off-by: Doug Anderson <dianders@...omium.org>
>>
>>
>> I thought that was on purpose.
>>
>> Problem as I see it is that users would expect the timeout to be set to
>> the provided parameter, which would be silently ignored and replaced
>> by timeout-sec if the parameter is wrong and timeout-sec is specified.
>> Seems to me that the user should be informed about the problem,
>> and not be permitted to provide invalid parameters.
>
> Wow, really?  ...so it's on purpose that the function will properly
> read the device tree entry and fill it in but still return an error?
>
I said "I thought ...", which wasn't meant to imply that I know.
Maybe Wim should comment and provide directions.

> I guess that can make some sense (treating device tree as an extension
> of the "default"), though it's non-obvious enough to me that it feels
> like it deserves some documentation.  I'd also question the value of
> the return code from this function anyway.  I'd vote for:
>
> 1. If param is non-zero and invalid, dev_warn() in this function.
>
> 2. If "timeout-sec" is specified in device tree and invalid,
> dev_warn() in this function.
>
Makes sense to me. Again up to Wim to provide direction.

> Function doesn't need to return an error code.  ...or if we keep it
> then nobody should be looking at it.  They should be putting their
> default in "timeout" before calling the function and trusting that the
> function will do the right thing and update it as needed.
>
>
> In practice only one caller ever checks this result in the code I'm
> looking at (at91sam9_wdt) and it's a little confusing what that's
> trying to do.  It does look like it would be broken by my suggestions
> above.  I guess it's trying to do:
> 1. device tree first (always passes 0 as the "param")
> 2. a value based on the patting heartbeat second.
> 3. the value WDT_HEARTBEAT third (starts in ->timeout)
>
I thought the idea was to give drivers the ability to handle errors
this way. Notice the "thought" ... I may be wrong.

>
> In any case I'm OK with just dropping this patch.  The code looked
> wrong and so I thought I'd fix it up, but I have no real need to see
> it land (we don't use kernel parameters for things like this) in
> Chrome OS.  I'm also happy to spin it if there is some interest.
>

It is really be up to Wim to decide what to do, so I'll defer to him.

Thanks,
Guenter

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