On Thu, 19 Sep 2013, Chen,Gang( 陈刚) wrote: > Please search BUG_ON() in kernel wide source code, we can know whether > it is commonly used or not. > > Please search BUG in arch/ sub-system, we can know which architectures > customize BUG/BUG_ON. > > After do the 2 things, In my opinion, we can treat BUG/BUG_ON() is common > implementation, and most of architectures uses the default one. > > Please check again, thanks. > BUG_ON() is used for fatal conditions where continuing could potentially be harmful. Obviously it is commonly used in a kernel. That doesn't mean we BUG_ON() when a string hasn't been defined for a mempolicy mode. mpol_to_str() is not critical. It is not a fatal condition, and nothing you say is going to convince anybody on this thread that it's a fatal condition. > > That's absolutely insane. If code is not allocating enough memory for the > > maximum possible length of a string to be stored by mpol_to_str(), it's a > > bug in the code. We do not panic and reboot the user's machine for such a > > bug. Instead, we break the build and require the broken code to be fixed. > > > > Please say in polite. > You want a polite response when you're insisting that we declare absolute failure, BUG_ON(), stop, and reboot the kernel because a mempolicy mode isn't defined as a string in mpol_to_str()? That sounds like an impolite response to the user, so see my politeness to you as coming from the users of the systems you just crashed. This is a compile-time problem, not run-time. > Can you be sure, the "maxlen == 50" in "fs/proc/task_mmu()", must be a bug?? > I asked you to figure out the longest string possible to be stored by mpol_to_str(). There's nothing mysterious about that function. It's deterministic. If you really can't figure out the value this should be, then you shouldn't be touching mpol_to_str().