On Fri, Nov 18, 2011 at 9:10 PM, Roland Dreier <roland@xxxxxxxxxxxxxxx> wrote:
> On Thu, Nov 17, 2011 at 11:52 PM, Bart Van Assche <bvanassche@xxxxxxx> wrote:
> > As far as I can see with CONFIG_BUG=n WARN() is defined as follows:
> >
> > #define WARN(condition, format...) ({ \
> > int __ret_warn_on = !!(condition); \
> > unlikely(__ret_warn_on); \
> > })
> >
> > So the changing pr_err(); WARN_ON(true); into WARN(1, ...) would cause
> > no error message to be printed if CONFIG_BUG=n. Is that the way kernel
> > code should behave if CONFIG_BUG=n ?
>
> I don't know the code well enough to know what it *should* do ...
> pretty much all WARN (or WARN_ON or __WARN) gives over a
> printk is that it includes the backtrace. Which might not be particularly
> useful in this case.
>
> So maybe pr_err() without WARN_ON is the best thing. I was
> just responding microlocally to the couple of lines here without
> thinking through what output is actually useful.
According to the description in init/Kconfig, BUG=n should only be
used on embedded systems with no facilities for error reporting. I do
not expect that anyone will miss the pr_err() output on such a system.
> What are these error messages for? A "can never happen" bug
> in the ib_srpt logic, or something that could be triggered by an
> insane initiator sending a bogus sequence?
These messages are present in code paths that should never be reached,
no matter how the initiator or the IB network behaves. These messages
have been useful while making ib_srpt robust against IB cable pulling
- see e.g. http://www.mail-archive.com/linux-rdma@xxxxxxxxxxxxxxx/msg09664.html.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
