Re: [PATCH] ib_srpt: Make compilation with BUG=n proceed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux