Page MenuHomePhabricator

melver (Marco Elver)
User

Projects

User does not belong to any projects.

User Details

User Since
Aug 20 2018, 1:39 PM (148 w, 7 h)

Recent Activity

Fri, Jun 18

melver accepted D104491: [Docs][Clang][Attr] mark no_stack_protector+no_sanitize GCC compatible.

There might be subtle inconsistencies between values accepted by our no_sanitize and GCC's no_sanitize, because of internal naming differences, but I couldn't say what those are right now (I think no_sanitize("coverage") only works with Clang, and GCC wants no_sanitize_coverage which we don't have due to not allowing new no_sanitize_*).

Fri, Jun 18, 1:27 AM · Restricted Project

Thu, Jun 17

melver added a comment to D104475: [Clang][Codegen] Add GNU function attribute 'no_profile' and lower it to noprofile.

So if we don't want to offer guarantee for IR/C/C++ attributes, we can document that users may need to additionally specify __attribute__((noinline)) to suppress inlining.

I don't generally like that approach:

  1. it's not easy for developers to validate their call call chains to ensure that a caller with a restrictive function attribute doesn't have unrestricted callers inlined into the restricted caller.
  2. that behavior opposes the principle of least surprise.
  3. We don't have a statement attribute for call sites to say "please don't inline this call" which would be fine grain. noinline is a course-grain hammer; what if we want to inline a callee into most callers but not this one caller that has such a restricted function attribute?

See also D91816 where I took the conservative approach for no_stack_protector and simply chose not to perform such inline substitution on caller and callee function attribute mismatch. I find this behavior to be the least surprising, and the developer is provided with introspection as to why the compile did not perform such inlining via -Rpass=inline flag.

Thu, Jun 17, 3:02 PM · Restricted Project
melver added a comment to D104475: [Clang][Codegen] Add GNU function attribute 'no_profile' and lower it to noprofile.

Should no_profile specify the inlining behavior? Though no_sanitize_* don't specify that, either.

I think it's somehow implicit, but I can't quite say how. There are some tests that check this, e.g.
compiler-rt/test/asan/TestCases/inline.cpp
[...]
noinstr does add noinline, but other uses of the attribute alone might not. But in the end inlining is a red herring, it just seems to be the easiest way to enforce the promised contract. See https://lore.kernel.org/lkml/CANpmjNNRz5OVKb6PE7K6GjfoGbht_ZhyPkNG9aD+KjNDzK7hGg@mail.gmail.com/
[...]

Thanks for the comments. Recently there is a discussion about LLVM IR function attribute nointeropt (similar to a debugging-only GCC function attribute noipa).
People tend to think attributes should be orthogonal. I think not suppressing inlining for the IR attribute no_profile is nice.
Ideally the GNU function attribute (C/C++) does not diverge much from the IR semantics.
So if we don't want to offer guarantee for IR/C/C++ attributes, we can document that users may need to additionally specify __attribute__((noinline)) to suppress inlining.

Thu, Jun 17, 2:59 PM · Restricted Project
melver added a comment to D104475: [Clang][Codegen] Add GNU function attribute 'no_profile' and lower it to noprofile.

Should no_profile specify the inlining behavior? Though no_sanitize_* don't specify that, either.

Thu, Jun 17, 2:19 PM · Restricted Project

Mon, Jun 14

melver added a comment to D104253: [Clang][Codegen] emit noprofile IR Fn Attr for no_instrument_function Fn Attr.

What are your thoughts on adding a noprofile function attribute in the FE? @MaskRay suggested filing a bug with gcov (below) to get their take on it.

https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__&component=gcov-profile&list_id=304970&product=gcc
Mon, Jun 14, 12:24 PM · Restricted Project

Fri, Jun 11

melver abandoned D103958: [WIP] Support MustControl conditional control attribute.
Fri, Jun 11, 10:35 AM · Restricted Project, Restricted Project

Thu, Jun 10

melver added a comment to D103958: [WIP] Support MustControl conditional control attribute.

Defining the value used to establish a control dependency, e.g. the load later writes depend on (kernel only defines writes to be ctrl-dependently ordered).

[[mustcontrol]] also has this problem.

At the LLVM IR level, if just want to split the load from the control dependency intrinsic, we could define a special kind of load that produces a LLVM IR "token". The control dependency intrinsic then takes the token as an operand, and optimizations understand that they aren't allowed to touch the token.

The problem at that point is, how does clang emit LLVM IR? It would have to do some sort of dataflow analysis to connect the load to the control dependency. And we'd need to define rules for what sort of data/control flow are allowed. That's not impossible, but it's complicated.

  1. Defining later ops that are control-dependent. With an expression like the __builtin, this could be any operation after, or it becomes too hard to define:

I don't think this is a problem we need to solve. If the user sticks the builtin in some weird location that doesn't have a branch immediately following it, that's fine. Any branch that depends on a value can enforce a control dependency, so in general, we just insert a no-op branch at the point of the call to the builtin. Like I mentioned before, we can think of removing that no-op branch as an optimization.


Whatever we end up doing, I really don't want to mark up LLVM IR branches. I don't want to add more constraints to CFG transforms at the LLVM IR level. The rules are already hard to understand; I don't want to add more weird edge cases. And I don't think it's necessary here.

Thu, Jun 10, 1:19 PM · Restricted Project, Restricted Project
melver updated the diff for D103958: [WIP] Support MustControl conditional control attribute.

As promised, some cleanups, docs, and updated test for the current version (no
other major changes yet).

Thu, Jun 10, 11:59 AM · Restricted Project, Restricted Project
melver added a comment to D103958: [WIP] Support MustControl conditional control attribute.

You could break __builtin_load_with_control_dependency(x) into something like __builtin_control_dependency(READ_ONCE(x)). I don't think any transforms will touch that in practice, even if it isn't theoretically sound. The rest of my suggestion still applies to that form, I think. They key point is that the compiler just needs to ensure some branch consumes the loaded value; it doesn't matter which branch it is.

Thu, Jun 10, 5:32 AM · Restricted Project, Restricted Project

Wed, Jun 9

melver added a comment to D103958: [WIP] Support MustControl conditional control attribute.

I don't like using metadata like this. Dropping metadata should generally preserve the semantics of the code.

Anything better for this without introducing new instructions? Would an argument be reasonable?

If we really want to make it part of the branch, maybe add an intrinsic that can be used with callbr. Not something we've done before, but the infrastructure should be mostly there.

That said, I'm not sure this is the best approach. Alternative proposal:

We could add a regular intrinsic. Just ignore the control flow at the IR level, and come up with a straight-line blob that just does the right thing. I think we'd want to actually perform the load as part of the intrinsic, to avoid worrying about the consume dependency. So we'd have an intrinsic "__builtin_load_with_control_dependency()". It would lower to something along the lines of asm("ldr %0, [%1]; cbnz %0, .+4":"=r"(dest):"r"(x):"memory"); on AArch64. The differences between the intrinsic and just using the asm I wrote:

  1. We weaken the "memory" clobber to something that more accurately matches what we need.
  2. We add a compiler transform to check if the branch is redundant, late in the optimization pipeline, and remove it if it is.

I think this produces the code you want, and it should be easier to understand and maintain.

Wed, Jun 9, 4:45 PM · Restricted Project, Restricted Project
melver added a comment to D103958: [WIP] Support MustControl conditional control attribute.

Please bear with me, I'm updating examples and documentation. I didn't think anybody would look at this while [WIP]. :-)

People try to help so you have early design feedback ;)

Wed, Jun 9, 1:48 PM · Restricted Project, Restricted Project
melver added a comment to D103958: [WIP] Support MustControl conditional control attribute.

I don't like using metadata like this. Dropping metadata should generally preserve the semantics of the code.

Wed, Jun 9, 1:38 PM · Restricted Project, Restricted Project
melver planned changes to D103958: [WIP] Support MustControl conditional control attribute.
Wed, Jun 9, 6:51 AM · Restricted Project, Restricted Project
melver added a comment to D103958: [WIP] Support MustControl conditional control attribute.

This is missing langref changes, and a RFC to llvm-dev.

Wed, Jun 9, 6:48 AM · Restricted Project, Restricted Project
melver requested review of D103958: [WIP] Support MustControl conditional control attribute.
Wed, Jun 9, 5:39 AM · Restricted Project, Restricted Project

Thu, May 27

melver added a comment to D103159: [Clang] Enable __has_feature(coverage_sanitizer).

Ping.

FWIW, the usual practice is to ping after no activity on the review for about a week.

That said, LGTM!

Thu, May 27, 9:36 AM · Restricted Project
melver committed rG4fbc66cd6d90: [Clang] Enable __has_feature(coverage_sanitizer) (authored by melver).
[Clang] Enable __has_feature(coverage_sanitizer)
Thu, May 27, 9:25 AM
melver closed D103159: [Clang] Enable __has_feature(coverage_sanitizer).
Thu, May 27, 9:25 AM · Restricted Project
melver added a comment to D103159: [Clang] Enable __has_feature(coverage_sanitizer).

To reviewers: Do note the feature vs. extension discussion.
Summary: We think to be consistent with other sanitizers and avoid confusion, we must make this a feature, too.

Thu, May 27, 8:09 AM · Restricted Project

Wed, May 26

melver added inline comments to D103159: [Clang] Enable __has_feature(coverage_sanitizer).
Wed, May 26, 11:19 AM · Restricted Project
melver updated the diff for D103159: [Clang] Enable __has_feature(coverage_sanitizer).

s/Since/Because/

Wed, May 26, 10:59 AM · Restricted Project
melver added inline comments to D103159: [Clang] Enable __has_feature(coverage_sanitizer).
Wed, May 26, 10:55 AM · Restricted Project
melver updated the diff for D103159: [Clang] Enable __has_feature(coverage_sanitizer).

Documentation wording.

Wed, May 26, 5:33 AM · Restricted Project
melver requested review of D103159: [Clang] Enable __has_feature(coverage_sanitizer).
Wed, May 26, 5:31 AM · Restricted Project

Tue, May 25

melver committed rG280333021e95: [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute (authored by melver).
[SanitizeCoverage] Add support for NoSanitizeCoverage function attribute
Tue, May 25, 4:00 AM
melver committed rG85feebf5a340: [NFC][SanitizeCoverage] Test always_inline functions work (authored by melver).
[NFC][SanitizeCoverage] Test always_inline functions work
Tue, May 25, 4:00 AM
melver committed rGca6df734069a: [NFC][CodeGenOptions] Refactor checking SanitizeCoverage options (authored by melver).
[NFC][CodeGenOptions] Refactor checking SanitizeCoverage options
Tue, May 25, 4:00 AM
melver closed D102772: [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute.
Tue, May 25, 4:00 AM · Restricted Project, Restricted Project
melver closed D102929: [NFC][SanitizeCoverage] Test always_inline functions work.
Tue, May 25, 4:00 AM · Restricted Project
melver closed D102927: [NFC][CodeGenOptions] Refactor checking SanitizeCoverage options.
Tue, May 25, 4:00 AM · Restricted Project

May 21 2021

melver added a comment to D102772: [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute.

Please have a look at the other 2 patches which are now a dependency for this. Once you're happy with all 3 I'll push them all together.
Thanks!

May 21 2021, 9:26 AM · Restricted Project, Restricted Project
melver added inline comments to D102772: [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute.
May 21 2021, 9:23 AM · Restricted Project, Restricted Project
melver updated the diff for D102772: [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute.
  • Refactor test and SanitizeCoverage* checking.
  • s/no_sanitize_coverage/nosanitize_coverage/
May 21 2021, 9:23 AM · Restricted Project, Restricted Project
melver requested review of D102929: [NFC][SanitizeCoverage] Test always_inline functions work.
May 21 2021, 9:17 AM · Restricted Project
melver requested review of D102927: [NFC][CodeGenOptions] Refactor checking SanitizeCoverage options.
May 21 2021, 9:13 AM · Restricted Project
melver added inline comments to D102772: [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute.
May 21 2021, 7:25 AM · Restricted Project, Restricted Project

May 19 2021

melver added a reviewer for D102772: [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute: pcc.
May 19 2021, 2:54 PM · Restricted Project, Restricted Project
melver updated the diff for D102772: [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute.

Rest of long-tail of IR changes related to introducing a new attributes...

May 19 2021, 2:53 PM · Restricted Project, Restricted Project
melver added inline comments to D102772: [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute.
May 19 2021, 10:22 AM · Restricted Project, Restricted Project
melver updated the diff for D102772: [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute.

Test that always_inline works as expected with no_sanitize("coverage")

May 19 2021, 9:19 AM · Restricted Project, Restricted Project
melver updated the diff for D102772: [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute.

Address Aaron's comments

May 19 2021, 7:30 AM · Restricted Project, Restricted Project
melver requested review of D102772: [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute.
May 19 2021, 6:45 AM · Restricted Project, Restricted Project

Dec 11 2020

melver committed rGc28b18af1962: [KernelAddressSanitizer] Fix globals exclusion for indirect aliases (authored by melver).
[KernelAddressSanitizer] Fix globals exclusion for indirect aliases
Dec 11 2020, 3:31 AM
melver closed D92846: [KernelAddressSanitizer] Fix globals exclusion for indirect aliases.
Dec 11 2020, 3:30 AM · Restricted Project, Restricted Project
melver updated the diff for D92846: [KernelAddressSanitizer] Fix globals exclusion for indirect aliases.

Check aliases exist in test

Dec 11 2020, 3:19 AM · Restricted Project, Restricted Project

Dec 10 2020

melver added inline comments to D92846: [KernelAddressSanitizer] Fix globals exclusion for indirect aliases.
Dec 10 2020, 3:28 PM · Restricted Project, Restricted Project

Dec 9 2020

melver added a comment to D92846: [KernelAddressSanitizer] Fix globals exclusion for indirect aliases.

The code looks reasonable to me. I see it only affects kernel, so assuming you booted kernel, we should be fine.
I can rubber-stamp it, but if you want more meaningful review, please wait for Alex or Nick.

Dec 9 2020, 9:22 AM · Restricted Project, Restricted Project
melver added a reviewer for D92846: [KernelAddressSanitizer] Fix globals exclusion for indirect aliases: nickdesaulniers.
Dec 9 2020, 9:18 AM · Restricted Project, Restricted Project
melver added reviewers for D92846: [KernelAddressSanitizer] Fix globals exclusion for indirect aliases: dvyukov, glider.
Dec 9 2020, 4:16 AM · Restricted Project, Restricted Project
melver updated the diff for D92846: [KernelAddressSanitizer] Fix globals exclusion for indirect aliases.

Revert unnecessary reformat

Dec 9 2020, 4:15 AM · Restricted Project, Restricted Project
melver updated the diff for D92846: [KernelAddressSanitizer] Fix globals exclusion for indirect aliases.

Style

Dec 9 2020, 4:14 AM · Restricted Project, Restricted Project
melver added a comment to D92846: [KernelAddressSanitizer] Fix globals exclusion for indirect aliases.

Have you checked if there is already a function that does this? Frequently there is :)
Some functions that look similar based on names:
stripPointerCasts
stripPointerCastsAndOffsets
stripPointerCastsAndAliases
canonicalizeAlias

Dec 9 2020, 4:07 AM · Restricted Project, Restricted Project
melver updated the diff for D92846: [KernelAddressSanitizer] Fix globals exclusion for indirect aliases.

Simplify using stripPointerCastsAndAliases()

Dec 9 2020, 4:07 AM · Restricted Project, Restricted Project
melver updated the diff for D92846: [KernelAddressSanitizer] Fix globals exclusion for indirect aliases.

Add test

Dec 9 2020, 3:47 AM · Restricted Project, Restricted Project

Dec 8 2020

melver updated the diff for D92846: [KernelAddressSanitizer] Fix globals exclusion for indirect aliases.

Fix recursive case

Dec 8 2020, 7:48 AM · Restricted Project, Restricted Project
melver requested review of D92846: [KernelAddressSanitizer] Fix globals exclusion for indirect aliases.
Dec 8 2020, 7:18 AM · Restricted Project, Restricted Project

Jul 31 2020

melver added a comment to D81346: [KernelAddressSanitizer] Ensure global array size remains multiple of type-size.

Note: We landed globals support for KASAN with https://reviews.llvm.org/rGd3f89314ff20ce1612bd5e09f9f90ff5dd5205a7

Jul 31 2020, 9:04 AM · Restricted Project, Restricted Project
melver abandoned D83949: [TSan] Do not compound reads and writes when separated by atomics.
Jul 31 2020, 9:02 AM · Restricted Project

Jul 17 2020

melver committed rG785d41a261d1: [TSan] Add option for emitting compound read-write instrumentation (authored by melver).
[TSan] Add option for emitting compound read-write instrumentation
Jul 17 2020, 1:25 AM
melver closed D83867: [TSan] Add option for emitting compound read-write instrumentation.
Jul 17 2020, 1:25 AM · Restricted Project

Jul 16 2020

melver added a comment to D83949: [TSan] Do not compound reads and writes when separated by atomics.

In practice, it probably doesn't really matter because T0 would probably load acquire spin on B or something better, and it'd be all in separate basic blocks.

Yes, that's what I am thinking as well. This only makes difference for a ~1 instruction window for the context where everything is timing dependent anyway...

Jul 16 2020, 9:07 AM · Restricted Project
melver added a comment to D83949: [TSan] Do not compound reads and writes when separated by atomics.

What would be an example of code where it matters?

Jul 16 2020, 8:02 AM · Restricted Project
melver added a comment to D83867: [TSan] Add option for emitting compound read-write instrumentation.

What happens if the load and the store are separated by a barrier atomic load or store? Will they also be combined into a single operation?

Jul 16 2020, 6:48 AM · Restricted Project
Herald added a project to D83949: [TSan] Do not compound reads and writes when separated by atomics: Restricted Project.
Jul 16 2020, 6:48 AM · Restricted Project
melver updated the diff for D83867: [TSan] Add option for emitting compound read-write instrumentation.

Address comments.

Jul 16 2020, 6:47 AM · Restricted Project

Jul 15 2020

melver added a comment to D83867: [TSan] Add option for emitting compound read-write instrumentation.

KCSAN change (draft) is here: https://github.com/melver/linux/commit/a04e683f457ea94b4bbba80cf05b5bcb50857fa7 -- tested and working as intended.

Jul 15 2020, 6:05 AM · Restricted Project
melver added a comment to D83867: [TSan] Add option for emitting compound read-write instrumentation.

It seems the linter/clang-format did a number of non-functional changes here. I'm inclined to keep them, because they more closely adhere to LLVM's style guide.

Jul 15 2020, 6:01 AM · Restricted Project
Herald added a project to D83867: [TSan] Add option for emitting compound read-write instrumentation: Restricted Project.
Jul 15 2020, 6:00 AM · Restricted Project

Jun 17 2020

melver added inline comments to D73543: [clang] Add support for __builtin_memcpy_inline.
Jun 17 2020, 7:31 AM · Restricted Project, Restricted Project

Jun 12 2020

melver committed rG8af7fa07aa24: [ASan][NFC] Refactor redzone size calculation (authored by melver).
[ASan][NFC] Refactor redzone size calculation
Jun 12 2020, 6:59 AM
melver closed D81367: [ASan][NFC] Refactor redzone size calculation.
Jun 12 2020, 6:59 AM · Restricted Project
melver added a reviewer for D81367: [ASan][NFC] Refactor redzone size calculation: andreyknvl.
Jun 12 2020, 4:17 AM · Restricted Project

Jun 10 2020

melver committed rG52cae05e087b: [ASan][Test] Fix expected strings for globals test (authored by melver).
[ASan][Test] Fix expected strings for globals test
Jun 10 2020, 11:46 AM
melver committed rG0f04f104537b: [ASan][Test] Split out global alias test (authored by melver).
[ASan][Test] Split out global alias test
Jun 10 2020, 11:07 AM
melver closed D81591: [ASan][Test] Split out global alias test.
Jun 10 2020, 11:06 AM · Restricted Project
melver updated the diff for D81591: [ASan][Test] Split out global alias test.

Comment.

Jun 10 2020, 10:34 AM · Restricted Project
melver created D81591: [ASan][Test] Split out global alias test.
Jun 10 2020, 10:32 AM · Restricted Project
melver committed rGd3f89314ff20: [KernelAddressSanitizer] Make globals constructors compatible with kernel [v2] (authored by melver).
[KernelAddressSanitizer] Make globals constructors compatible with kernel [v2]
Jun 10 2020, 6:33 AM
melver closed D81390: [KernelAddressSanitizer] Make globals constructors compatible with kernel [v2].
Jun 10 2020, 6:32 AM · Restricted Project, Restricted Project
melver updated the summary of D81367: [ASan][NFC] Refactor redzone size calculation.
Jun 10 2020, 3:47 AM · Restricted Project
melver updated the diff for D81390: [KernelAddressSanitizer] Make globals constructors compatible with kernel [v2].

Fix test on windows.

Jun 10 2020, 3:47 AM · Restricted Project, Restricted Project
melver updated the diff for D81390: [KernelAddressSanitizer] Make globals constructors compatible with kernel [v2].

Fix typos.

Jun 10 2020, 1:03 AM · Restricted Project, Restricted Project

Jun 9 2020

melver updated the summary of D81367: [ASan][NFC] Refactor redzone size calculation.
Jun 9 2020, 11:32 AM · Restricted Project
melver updated the diff for D81390: [KernelAddressSanitizer] Make globals constructors compatible with kernel [v2].

Fix test broken by linter.

Jun 9 2020, 10:25 AM · Restricted Project, Restricted Project
melver added a comment to D81390: [KernelAddressSanitizer] Make globals constructors compatible with kernel [v2].

Thanks! PTAL.

Jun 9 2020, 10:25 AM · Restricted Project, Restricted Project
melver updated the diff for D81390: [KernelAddressSanitizer] Make globals constructors compatible with kernel [v2].

Address comments.

Jun 9 2020, 10:25 AM · Restricted Project, Restricted Project
melver added a reviewer for D81390: [KernelAddressSanitizer] Make globals constructors compatible with kernel [v2]: dvyukov.
Jun 9 2020, 5:59 AM · Restricted Project, Restricted Project
melver retitled D81390: [KernelAddressSanitizer] Make globals constructors compatible with kernel [v2] from [KernelAddressSanitizer] Make globals constructors compatible with kernel to [KernelAddressSanitizer] Make globals constructors compatible with kernel [v2].
Jun 9 2020, 1:03 AM · Restricted Project, Restricted Project
melver added a comment to D81390: [KernelAddressSanitizer] Make globals constructors compatible with kernel [v2].

I do not know enough about KASAN enough to review this patch but I can say that against mainline at https://git.kernel.org/linus/af7b4801030c07637840191c69eb666917e4135d, there appear to be no visible regressions with this version of the patch on top of caa2fddce72f2e8ca3d6346cc2c8fe85252b91d8.

Jun 9 2020, 1:03 AM · Restricted Project, Restricted Project

Jun 8 2020

melver updated the summary of D81390: [KernelAddressSanitizer] Make globals constructors compatible with kernel [v2].
Jun 8 2020, 1:51 PM · Restricted Project, Restricted Project
melver added a reviewer for D81390: [KernelAddressSanitizer] Make globals constructors compatible with kernel [v2]: nathanchance.
Jun 8 2020, 8:11 AM · Restricted Project, Restricted Project
melver updated the summary of D81390: [KernelAddressSanitizer] Make globals constructors compatible with kernel [v2].
Jun 8 2020, 8:11 AM · Restricted Project, Restricted Project
melver updated the diff for D81390: [KernelAddressSanitizer] Make globals constructors compatible with kernel [v2].

Also ignore non-alias globals prefixed by __.

Jun 8 2020, 8:11 AM · Restricted Project, Restricted Project
melver created D81390: [KernelAddressSanitizer] Make globals constructors compatible with kernel [v2].
Jun 8 2020, 7:05 AM · Restricted Project, Restricted Project
melver created D81367: [ASan][NFC] Refactor redzone size calculation.
Jun 8 2020, 2:40 AM · Restricted Project
melver committed rGc6ec352a6bde: Revert "[KernelAddressSanitizer] Make globals constructors compatible with… (authored by melver).
Revert "[KernelAddressSanitizer] Make globals constructors compatible with…
Jun 8 2020, 2:08 AM
melver added a reverting change for rG866ee2353f7d: [KernelAddressSanitizer] Make globals constructors compatible with kernel: rGc6ec352a6bde: Revert "[KernelAddressSanitizer] Make globals constructors compatible with….
Jun 8 2020, 2:08 AM
melver abandoned D81346: [KernelAddressSanitizer] Ensure global array size remains multiple of type-size.

With an allmodconfig, mostpost still isn't happy because it expects the device_id info to be a certain size. Revert everything while we figure out how to make modpost happy.

Jun 8 2020, 2:08 AM · Restricted Project, Restricted Project

Jun 7 2020

melver updated the diff for D81346: [KernelAddressSanitizer] Ensure global array size remains multiple of type-size.

Add 0-size array to test to check redzone calculation does not divide by 0.

Jun 7 2020, 3:27 PM · Restricted Project, Restricted Project
melver created D81346: [KernelAddressSanitizer] Ensure global array size remains multiple of type-size.
Jun 7 2020, 10:38 AM · Restricted Project, Restricted Project