LGTM

The change looks good to me.

Fixed the assert. PTAL.

Hm, I don't see this failure. Just in case I rebased onto the latest tip.

Thanks! Could you commit this?

Thanks! Could you commit this as well?

Added a test.

PTAL. Added AlwaysRecoverable to SanitizerArgs.cpp. Right now recovery is disallowed for both KASan and KHWASan, but all the appropriate flags seem to be passed properly to the instrumentation pass, so we can easily allow it in the future in we want.

Also rebased onto the latest tip.

I don't have any preference between -fsanitize=kernel-address and -fsanitize=address -mllvm asan-kernel=1. GCC uses -fsanitize=kernel-address and I think it looked quite logical to use the same in Clang.

Check ClEnableK[hw]asan.getNumOccurrences().

Could you commit this?

The -fsanitize=kernel-address flag is used by the kernel and we should leave it. The no_sanitize("kernel-address") attribute is not used in the kernel, so it's totally OK to get rid of it. What kind of changes would that require? AFAIU clang/include/clang/Basic/Sanitizers.def is used to generate both, the flag and the no_sanitize attribute.

Addressed @eugenis comments.

I don't see an easy way to fix this in SemaDeclAttr.cpp. The way that I see is to change std::vector<StringRef> Sanitizers to something like std::set, then .insert("kernel-address") when we see "address" and vice versa, and then convert back to vector before passing to D->addAttr. What do you think?

Rebased onto https://reviews.llvm.org/D44699

Note: goes on top of https://reviews.llvm.org/D44827 and https://reviews.llvm.org/D44981

I think it makes sense to make both no_sanitize("address") and no_sanitize("kernel-address") work. Done that.

Done, PTAL

What do you mean by "(0 .. 0xFF, -1)"? Should it accept a list of tag values in some format?

If to land means to commit, then yes, please :)

PTAL

Try harder to install SIGTRAP handler.

PTAL

Install SIGTRAP handler.

Done, PTAL

Use 0x900 instead of 0x100 for brk immediate (0x100 - 0x800 are unavailable in the kernel).

It seems that hwasan_linux.cc is in a different repo (compiler-rt) and is not picked up by svn diff. Do I need to submit that change as a separate patch?

This is still not committed AFAICT.

Renamed kernel_inline.ll to kernel-inline.ll

PTAL

Switched user space hwasan to brk.
Fixed and added tests.

I'll send my patch with more khwasan related changes, once this is committed.

Thanks!

Sorry, it was supposed to go on top of https://reviews.llvm.org/D42423 (which is committed now).
Anyway, I noticed an issue in naming ("loadN" is actually supposed to be "load_n") and another issue with asan flags (need "-asan-recover=1" and "noabort" suffixes).
Could you try again?

Fixed "_n" vs "N" naming and added "-asan-recover=1" flag, which is always enabled for the kernel.

Could you commit this?

Yes, that would be great if you commit this.

Sent https://reviews.llvm.org/D42473

It is strange indeed.

Asan uses "asan_loadN" and "asan_storeN" and hwasan now has "hwasan_loadN" and "hwasan_storeN", so both use "N" and this is consistent as is.

In D42423#985333, @eugenis wrote:

Please fix hwasan as well.