From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
To: Alexandre Courbot <gnurou@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Alexandre Courbot <acourbot@nvidia.com>,
Grant Likely <grant.likely@linaro.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH] gpiolib: Replace WARN_ON with WARN_ON_ONCE
Date: Mon, 2 Dec 2013 07:02:30 -0300 [thread overview]
Message-ID: <20131202100229.GA2466@localhost> (raw)
In-Reply-To: <CAAVeFu+Kn5Fad7rtgDfWYeX=xAvYhvAHQRom9a=qogUPreDdgg@mail.gmail.com>
On Sun, Dec 01, 2013 at 12:07:26PM +0900, Alexandre Courbot wrote:
> On Fri, Nov 29, 2013 at 9:27 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Thu, Nov 28, 2013 at 8:16 PM, Ezequiel Garcia
> > <ezequiel.garcia@free-electrons.com> wrote:
> >> Hi Linus,
> >> On Sun, Nov 24, 2013 at 09:37:45AM -0300, Ezequiel Garcia wrote:
> >>> These warnings can be very spammy, since they could be called from
> >>> kernel threads. Use WARN_ON_ONCE, which is enough to warn developers
> >>> about the 'can_sleep' usage.
> >>>
> >>> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> > (...)
> >> Any comments on this?
> >
> > I'm a bit hesitant because I don't know the conventions for WARN_ON_ONCE()
> > vs WARN_ON().
> >
> > I'd like some wider input if possible, Alexandre, Grant, what do you say?
>
> I'd say WARN_ON() is just appropriate here. Calling a preemptible
> function from a context that cannot sleep is a serious issue and you
> cannot nag the user enough about it. At least if something bad happens
> due to this condition the warning is guaranteed to be one of the last
> messages the user will see before the system locks. Change it with
> WARN_ON_ONCE() and chances are high that the system will hang without
> any meaningful log near the point of failure.
>
> Each caller should know whether it is running in preemptible context
> or not and can thus use the right function, so I don't see any reason
> to relax the rules here.
>
> If we could know for sure at runtime whether we are running in
> preemptible context or not we could probably merge these functions
> into one and warn more appropriately on a per-case basis, but as far
> as I know (which is not very far) there is no such way.
>
OK, that's fine by me.
Thanks for the feedback,
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2013-12-02 10:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-24 12:37 [PATCH] gpiolib: Replace WARN_ON with WARN_ON_ONCE Ezequiel Garcia
2013-11-28 19:16 ` Ezequiel Garcia
2013-11-29 12:27 ` Linus Walleij
2013-12-01 3:07 ` Alexandre Courbot
2013-12-02 10:02 ` Ezequiel Garcia [this message]
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=20131202100229.GA2466@localhost \
--to=ezequiel.garcia@free-electrons.com \
--cc=acourbot@nvidia.com \
--cc=gnurou@gmail.com \
--cc=grant.likely@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
/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.