On 09/14/2014 05:35 AM, Randy Dunlap wrote: > Following sentence is confusing. I'm not sure how to fix it. >
Perhaps rephrase is like this: Do not use slub poisoning with KASan if user tracking enabled (iow slub_debug=PU). User tracking info (allocation/free stacktraces) are stored inside slub object's metadata. Slub poisoning overwrites slub object and it's metadata with poison value on freeing. So if KASan will detect use after free, allocation/free stacktraces will be overwritten and KASan won't be able to print them. >> +Please don't use slab poisoning with KASan (slub_debug=P), beacuse if KASan >> will > > > drop: will > >> +detects use after free allocation and free stacktraces will be overwritten >> by > > maybe: use after free, > >> +poison bytes, and KASan won't be able to print this backtraces. > > backtrace. > >> + >> +Each shadow byte corresponds to 8 bytes of the main memory. We use the >> +following encoding for each shadow byte: 0 means that all 8 bytes of the >> +corresponding memory region are addressable; k (1 <= k <= 7) means that >> +the first k bytes are addressable, and other (8 - k) bytes are not; >> +any negative value indicates that the entire 8-byte word is unaddressable. >> +We use different negative values to distinguish between different kinds of >> +unaddressable memory (redzones, freed memory) (see mm/kasan/kasan.h). >> + > > Is there any need for something similar to k (1 <= k <= 7) but meaning that > the > *last* k bytes are addressable instead of the first k bytes? > There is no need for that. Slub allocations are always 8 byte aligned (at least on 64bit systems). Now I realized that it could be a problem for 32bit systems. Anyway, the best way to deal with that would be align allocation to 8 bytes. >> +Poisoning or unpoisoning a byte in the main memory means writing some >> special >> +value into the corresponding shadow memory. This value indicates whether the >> +byte is addressable or not. >> + > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
