* David Miller <davem@xxxxxxxxxxxxx> wrote: > > fix warning in drivers/net/sky2.c > > fix warning in net/sunrpc/svcauth_unix.c > > fix warning in security/selinux/netnode.c > > fix warning in net/packet/af_packet.c > > fix warning in net/rfkill/rfkill.c > > Not applied. Changing this from a BUG() to a panic() is wrong. > BUG() kills the current execution context, and allows the system to > potentially continue. Panic() takes down the entire machine. Yeah, although in practice a BUG() in some of those places will take down the whole machine: > > fix warning in net/packet/af_packet.c That's packet receive path, holding spinlocks or in other atomic context (irq/softirq)? A BUG() will take down the machine as we will crash and try to schedule in atomic context. > The !CONFIG_BUG BUG() definition should be marked in such a way that > gcc thinks it is noreturn. Otherwise BUG() isn't really BUG() > anymore. The other option is to never allow BUG to be disabled or > have it always evaluate to a simple bug trap. Yeah, but note that that's exactly the current behavior (and intent) of !CONFIG_BUG: it is not doing anything (it's just an empty macro which returns!), and we get those build warnings because the control flow becomes undefined. We cannot mark it noreturn because it does return. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
