From: Guenter Roeck <linux@roeck-us.net>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: linux-watchdog@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Wim Van Sebroeck <wim@iguana.be>,
Catalin Marinas <catalin.marinas@arm.com>,
Maxime Ripard <maxime.ripard@free-electrons.com>,
Will Deacon <will.deacon@arm.com>, Arnd Bergmann <arnd@arndb.de>,
Heiko Stuebner <heiko@sntech.de>,
Russell King <linux@arm.linux.org.uk>,
Jonas Jensen <jonas.jensen@gmail.com>,
Randy Dunlap <rdunlap@infradead.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/6] watchdog: Add API to trigger reboots
Date: Thu, 15 May 2014 14:47:43 -0700 [thread overview]
Message-ID: <20140515214743.GA15577@roeck-us.net> (raw)
In-Reply-To: <20140515215020.38f03ab1@alan.etchedpixels.co.uk>
On Thu, May 15, 2014 at 09:50:20PM +0100, One Thousand Gnomes wrote:
> > +void watchdog_do_reboot(void)
> > +{
> > + if (wdd_reboot_dev)
> > + wdd_reboot_dev->ops->reboot(wdd_reboot_dev);
> > +}
> > +EXPORT_SYMBOL(watchdog_do_reboot);
>
> Crashes and burns if you are unloading a watchdog just as you try to
> reboot. Yes its wildly unlikely but it's still conceptually wrong.
>
Possibly, but how is it different to the code it replaces ?
> >
> > + if (wdd->ops->reboot)
> > + wdd_reboot_dev = wdd;
> > +
>
> Two parallel registers from different bus types, parallel
> register/unregister ?
>
Sorry, you lost me. What different bus types ?
> This feels to me like a backward step. We've gone from various device
> bits leaking into the core code (where they can work all the time) to
> various core code leaking into the devices which is asking for init order
> problems and other races.
>
> Given we are talking about stuff of the order of 10-20 instructions I
> think duplication is not only the lesser evil it's also smaller, more
> reliable and easier to maintain.
>
> IMHO this is a solution looking for a problem.
>
Really ? To me it seems to be much cleaner than setting the pointer to
arm_pm_restart directly from individual watchdog drivers. Also, and I was
told that other HW may benefit from it as well.
Do I understand it correctly that you prefer watchdog drivers to set
arm_pm_restart directly ? Maybe you can explain a bit why you believe
that to be a superior solution.
In addition to that, while I could obviously add some locking around access to
wdd_reboot_dev, existing code doesn't lock any changes to arm_pm_restart. I am
somewhat at loss why setting or clearing arm_pm_restart is less of a problem
that setting wdd_reboot_dev.
Thanks,
Guenter
WARNING: multiple messages have this Message-ID (diff)
From: linux@roeck-us.net (Guenter Roeck)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/6] watchdog: Add API to trigger reboots
Date: Thu, 15 May 2014 14:47:43 -0700 [thread overview]
Message-ID: <20140515214743.GA15577@roeck-us.net> (raw)
In-Reply-To: <20140515215020.38f03ab1@alan.etchedpixels.co.uk>
On Thu, May 15, 2014 at 09:50:20PM +0100, One Thousand Gnomes wrote:
> > +void watchdog_do_reboot(void)
> > +{
> > + if (wdd_reboot_dev)
> > + wdd_reboot_dev->ops->reboot(wdd_reboot_dev);
> > +}
> > +EXPORT_SYMBOL(watchdog_do_reboot);
>
> Crashes and burns if you are unloading a watchdog just as you try to
> reboot. Yes its wildly unlikely but it's still conceptually wrong.
>
Possibly, but how is it different to the code it replaces ?
> >
> > + if (wdd->ops->reboot)
> > + wdd_reboot_dev = wdd;
> > +
>
> Two parallel registers from different bus types, parallel
> register/unregister ?
>
Sorry, you lost me. What different bus types ?
> This feels to me like a backward step. We've gone from various device
> bits leaking into the core code (where they can work all the time) to
> various core code leaking into the devices which is asking for init order
> problems and other races.
>
> Given we are talking about stuff of the order of 10-20 instructions I
> think duplication is not only the lesser evil it's also smaller, more
> reliable and easier to maintain.
>
> IMHO this is a solution looking for a problem.
>
Really ? To me it seems to be much cleaner than setting the pointer to
arm_pm_restart directly from individual watchdog drivers. Also, and I was
told that other HW may benefit from it as well.
Do I understand it correctly that you prefer watchdog drivers to set
arm_pm_restart directly ? Maybe you can explain a bit why you believe
that to be a superior solution.
In addition to that, while I could obviously add some locking around access to
wdd_reboot_dev, existing code doesn't lock any changes to arm_pm_restart. I am
somewhat at loss why setting or clearing arm_pm_restart is less of a problem
that setting wdd_reboot_dev.
Thanks,
Guenter
next prev parent reply other threads:[~2014-05-15 21:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-15 20:38 [PATCH v3 0/6] watchdog: Add reboot API Guenter Roeck
2014-05-15 20:38 ` Guenter Roeck
2014-05-15 20:38 ` [PATCH v3 1/6] watchdog: Add API to trigger reboots Guenter Roeck
2014-05-15 20:38 ` Guenter Roeck
2014-05-15 20:50 ` One Thousand Gnomes
2014-05-15 20:50 ` One Thousand Gnomes
2014-05-15 21:47 ` Guenter Roeck [this message]
2014-05-15 21:47 ` Guenter Roeck
2014-05-16 1:22 ` [PATCH v4 " Guenter Roeck
2014-05-16 1:22 ` Guenter Roeck
2014-05-15 20:38 ` [PATCH v3 2/6] watchdog: Document reboot API Guenter Roeck
2014-05-15 20:38 ` Guenter Roeck
2014-05-15 20:38 ` [PATCH v3 3/6] arm64: Support reboot through watchdog subsystem Guenter Roeck
2014-05-15 20:38 ` Guenter Roeck
2014-05-15 20:38 ` [PATCH v3 4/6] arm: " Guenter Roeck
2014-05-15 20:38 ` Guenter Roeck
2014-05-15 20:38 ` [PATCH v3 5/6] watchdog: moxart: Register reboot handler with " Guenter Roeck
2014-05-15 20:38 ` Guenter Roeck
2014-05-15 20:38 ` [PATCH v3 6/6] watchdog: sunxi: " Guenter Roeck
2014-05-15 20:38 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140515214743.GA15577@roeck-us.net \
--to=linux@roeck-us.net \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=heiko@sntech.de \
--cc=jonas.jensen@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=maxime.ripard@free-electrons.com \
--cc=rdunlap@infradead.org \
--cc=will.deacon@arm.com \
--cc=wim@iguana.be \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.