On 5/2/16 20:42, Alexander Potapenko wrote: > On Mon, May 2, 2016 at 2:27 PM, Chen Gang <chengang@xxxxxxxxxxxxxxxx> wrote: >> On 5/2/16 19:21, Dmitry Vyukov wrote: >>> >>> Signed counter looks good to me. >> >> Oh, sorry, it seems a little mess (originally, I need let the 2 patches >> in one patch set). >> >> If what Alexander's idea is OK (if I did not misunderstand), I guess, >> unsigned counter is still necessary. > I don't think it's critical for us to use an unsigned counter. > If we increment the counter in kasan_disable_current() and decrement > it in kasan_enable_current(), as Dmitry suggested, we'll be naturally > using only positive integers for the counter. > If the counter drops below zero, or exceeds a certain number (say, > 20), we can immediately issue a warning. > OK, thanks. And for "kasan_depth == 1", I guess, its meaning is related with kasan_depth[++|--] in kasan_[en|dis]able_current(): - If kasan_depth++ in kasan_enable_current() with preventing overflow/ underflow, it means "we always want to disable KASAN, if CONFIG_KASAN is not under arm64 or x86_64". - If kasan_depth-- in kasan_enable_current() with preventing overflow/ underflow, it means "we can enable KASAN if CONFIG_KASAN, but firstly we disable it, if it is not under arm64 or x86_64". For me, I don't know which one is correct (or my whole 'guess' is incorrect). Could any members provide your ideas? >>> We can both issue a WARNING and prevent the actual overflow/underflow. >>> But I don't think that there is any sane way to handle the bug (other >>> than just fixing the unmatched disable/enable). If we ignore an >>> excessive disable, then we can end up with ignores enabled >>> permanently. If we ignore an excessive enable, then we can end up with >>> ignores enabled when they should not be enabled. The main point here >>> is to bark loudly, so that the unmatched annotations are noticed and >>> fixed. >>> >> >> How about BUG_ON()? > As noted by Dmitry in an offline discussion, we shouldn't bail out as > long as it's possible to proceed, otherwise the kernel may become very > hard to debug. > A mismatching annotation isn't a case in which we can't proceed with > the execution. OK, thanks. I guess, we are agree with each other: "We can both issue a WARNING and prevent the actual overflow/underflow.". Thanks. -- Chen Gang (陈刚) Managing Natural Environments is the Duty of Human Beings. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>