Solar Designer

> Maybe `GFP_ATOMIC` behaves in a more relaxed way (is more likely to succeed) when not in interrupt context? We'd need to review the code for it There are in...

> There are in fact `in_interrupt()` checks in various places in files under `mm`. Upon a closer look, the most relevant ones appear to be limited to applying the current...

@Adam-pi3 Would it make sense for us to use `in_interrupt() ? GFP_ATOMIC : GFP_KERNEL`? That way, with ftrace most of those would end up `GFP_KERNEL`.

This issue isn't fully fixed yet - still getting part of the above errors - those for functions other than `security_bprm_committ*` now. #178 says: ``` How Has This Been Tested?...

Nasty. This illustrates another rather fundamental issue we're facing lately: even when we do find and hook the symbol, there might be an inlined copy (or several) of the same...

In the case of your kernel build, it looks like we have this problem for at least two symbols, and I guess at least one of those wasn't among the...

No, I don't think we should be adding one more symbol to the exports because of this, nor would it be expected to help. My current best idea for a...

My understanding is that exporting a symbol takes and records its address, causing a non-inlined copy of the function to be preserved, but it does not prevent the compiler from...

Thanks, @berkley4! @oshogbo @sempervictus You want to help fix this? We could also want to introduce some way to prevent/detect similar breakage going forward.

@sempervictus Are you going to send us a PR fixing this issue? Thanks!