linux-kernel - Re: [PATCH v4 04/11] watchdog: add support for sl28cpld watchdog

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: <450ce146-bf9a-130a-78e5-4bcabf1b7063@roeck-us.net>
Date:   Fri, 5 Jun 2020 09:34:35 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Michael Walle <michael@...le.cc>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-hwmon@...r.kernel.org, linux-pwm@...r.kernel.org,
        linux-watchdog@...r.kernel.org,
        linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Rob Herring <robh+dt@...nel.org>,
        Jean Delvare <jdelvare@...e.com>,
        Lee Jones <lee.jones@...aro.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
        Wim Van Sebroeck <wim@...ux-watchdog.org>,
        Shawn Guo <shawnguo@...nel.org>, Li Yang <leoyang.li@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Marc Zyngier <maz@...nel.org>, Mark Brown <broonie@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v4 04/11] watchdog: add support for sl28cpld watchdog

On 6/5/20 9:04 AM, Andy Shevchenko wrote:
> On Fri, Jun 5, 2020 at 6:05 PM Guenter Roeck <linux@...ck-us.net> wrote:
>> On Fri, Jun 05, 2020 at 05:09:11PM +0300, Andy Shevchenko wrote:
>>> On Fri, Jun 05, 2020 at 06:52:00AM -0700, Guenter Roeck wrote:
>>>> On 6/5/20 3:50 AM, Andy Shevchenko wrote:
>>>>> On Fri, Jun 5, 2020 at 1:24 PM Michael Walle <michael@...le.cc> wrote:
>>>>>> Am 2020-06-05 10:14, schrieb Andy Shevchenko:
>>>>>>> On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@...le.cc> wrote:
>>>
>>> ...
>>>
>>>>>>>> +static bool nowayout = WATCHDOG_NOWAYOUT;
>>>>>>>> +module_param(nowayout, bool, 0);
>>>>>>>> +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started
>>>>>>>> (default="
>>>>>>>> +                               __MODULE_STRING(WATCHDOG_NOWAYOUT)
>>>>>>>> ")");
>>>>>>>> +
>>>>>>>> +static int timeout;
>>>>>>>> +module_param(timeout, int, 0);
>>>>>>>> +MODULE_PARM_DESC(timeout, "Initial watchdog timeout in seconds");
>>>>>>>
>>>>>>> Guenter ACKed this, but I'm wondering why we still need module
>>>>>>> parameters...
>>>>>>
>>>>>> How would a user change the nowayout or the timeout? For the latter
>>>>>> there is
>>>>>> a device tree entry, but thats not easy changable by the user.
>>>>>
>>>>> Yes, it's more question to VIm and Guenter than to you.
>>>>>
>>>>
>>>> Has support for providing module parameters with the kernel command line
>>>> been discontinued/deprecated, or did it run out of favor ? Sorry if I
>>>> missed that.
>>>
>>> Latter according to Greg KH. One of the (plenty) examples [1].
>>>
>>> [1]: https://www.mail-archive.com/driverdev-devel@linuxdriverproject.org/msg96495.html
>>>
>> What is the suggested replacement ?
> 
> In some mails he suggested to use sysfs.
> 

Using sysfs specifically to defeat "nowayout" would defeat
its purpose, which is specifically to disable the possibility
to stop the watchdog. Using a module parameter (or rather boot
time parameter) is a bit different since that has to be done
consciously and is only valid for a given boot. The same is
true for the timeout parameter. If one can wait for sysfs (or
userspace) to be active, one can as well use the watchdog
daemon to update the timeout. The use case for the module
/ command line parameter or sysfs based timeout is to be
able to set it _before_ userspace is active.

So sysfs is not really an alternative.

Guenter