On 5/2/16 16:26, Dmitry Vyukov wrote: > On Mon, May 2, 2016 at 7:36 AM, <chengang@xxxxxxxxxxxxxxxx> wrote: >> From: Chen Gang <chengang@xxxxxxxxxxxxxxxx> >> >> According to kasan_[dis|en]able_current() comments and the kasan_depth' >> s initialization, if kasan_depth is zero, it means disable. >> >> So need use "!!kasan_depth" instead of "!kasan_depth" for checking >> enable. >> > > Hi Chen, > > I don't think this is correct. OK, thanks. > We seem to have some incorrect comments around kasan_depth, and a > weird way of manipulating it (disable should increment, and enable > should decrement). But in the end it is working. This change will > suppress all true reports and enable all false reports. > For me, I guess, what you said above is reasonable. But it is really strange to any newbies (e.g. me), so it will be better to get another member's confirmation, too. If no any additional reply by any other members within 3 days, I shall treat what you said is OK. > If you want to improve kasan_depth handling, then please fix the > comments and make disable increment and enable decrement (potentially > with WARNING on overflow/underflow). It's better to produce a WARNING > rather than silently ignore the error. We've ate enough unmatched > annotations in user space (e.g. enable is skipped on an error path). > These unmatched annotations are hard to notice (they suppress > reports). So in user space we bark loudly on overflows/underflows and > also check that a thread does not exit with enabled suppressions. > For me, when WARNING on something, it will dummy the related feature which should be used (may let user's hope fail), but should not get the negative result (hurt user's original work). So in our case: - When caller calls kasan_report_enabled(), kasan_depth-- to 0, - When a caller calls kasan_report_enabled() again, the caller will get a warning, and notice about this calling is failed, but it is still in enable state, should not change to disable state automatically. - If we report an warning, but still kasan_depth--, it will let things much complex. And for me, another improvements can be done: - signed int kasan_depth may be a little better. When kasan_depth > 0, it is in disable state, else in enable state. It will be much harder to generate overflow than unsigned int kasan_depth. - Let kasan_[en|dis]able_current() return Boolean value to notify the caller whether the calling succeeds or fails. 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>