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]
Message-ID: <CAD=FV=W0Op73P2f5KSWhOG+34N8OyeKUzS17ot3BTtzULApv8A@mail.gmail.com>
Date:	Tue, 26 Nov 2013 11:23:13 -0800
From:	Doug Anderson <dianders@...omium.org>
To:	Guenter Roeck <linux@...ck-us.net>
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

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

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)


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.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ