On Thu, Nov 17, 2011 at 11:52 PM, Bart Van Assche <bvanass...@acm.org> 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.
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?
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
