On Thu, Aug 27, 2020 at 1:04 AM Chunguang Xu <brookxu.cn@xxxxxxxxx> wrote:
>
> The kernel has not yet defined ASSERT(). Indeed, BUG() and WARN() are very
> clear and can cover most application scenarios. However, some applications
> require more debugging information and similar behavior to assert(), which
> cannot be directly provided by BUG() and WARN().
>
> Therefore, many modules independently implement ASSERT(), and most of them
> are similar, but slightly different, such as:
>
> #define ASSERT(expr) \
> if(!(expr)) { \
> printk( "\n" __FILE__ ":%d: Assertion " #expr " failed!\n",__LINE__); \
> panic(#expr); \
> }
>
> #define ASSERT(x) \
> do { \
> if (!(x)) { \
> printk(KERN_EMERG "assertion failed %s: %d: %s\n", \
> __FILE__, __LINE__, #x); \
> BUG(); \
Generally, I don't think the extra printk() here helps much, as BUG() and
panic() both provide the source location already.
> Some implementations are not optimal for instruction prediction, such as
> missing unlikely():
>
> #define assert(expr) \
> if(!(expr)) { \
> printk( "Assertion failed! %s,%s,%s,line=%d\n",\
> #expr,__FILE__,__func__,__LINE__); \
> BUG(); \
> }
>
> Some implementations have too little log content information, such as:
>
> #define ASSERT(X) \
> do { \
> if (unlikely(!(X))) { \
> printk(KERN_ERR "\n"); \
> printk(KERN_ERR "XXX: Assertion failed\n"); \
> BUG(); \
> } \
> } while(0)
>
> As we have seen, This makes the code redundant and inconvenient to
> troubleshoot the system. Therefore, perhaps we need to define two
> wrappers for BUG() and WARN_ON(), provide the implementation of ASSERT(),
> simplifyy the code and facilitate problem analysis .
>
> Maybe I missed some information, but I think there is a need to clean
> up the code, maybe in other ways, and more discussion is needed here.
> If this approach is reasonable, I will clean up these codes later and
> issue related patches.
In general, I'd argue that any direct usage of macros like these should
just use BUG(). However it seems that the ones you are replacing
tend to make it conditional on either the 'DEBUG' macro, on a Kconfig
symbol or on some other preprocessor conditional. My feeling is that
if there is some cleanup, maybe we should instead be adding a variant
of BUG_ON() that takes both a preprocessor token (like IS_ENABLED()
does) and a condition.
Arnd
