On Fri, Nov 23, 2018 at 1:43 PM Michal Hocko mhocko@kernel.org wrote:
On Fri 23-11-18 13:30:57, Daniel Vetter wrote:
On Fri, Nov 23, 2018 at 12:15:57PM +0100, Michal Hocko wrote:
On Thu 22-11-18 17:51:04, Daniel Vetter wrote:
Just a bit of paranoia, since if we start pushing this deep into callchains it's hard to spot all places where an mmu notifier implementation might fail when it's not allowed to.
What does WARN give you more than the existing pr_info? Is really backtrace that interesting?
Automated tools have to ignore everything at info level (there's too much of that). I guess I could do something like
if (blockable) pr_warn(...) else pr_info(...)
WARN() is simply my goto tool for getting something at warning level dumped into dmesg. But I think the pr_warn with the callback function should be enough indeed.
I wouldn't mind s@pr_info@pr_warn@
Well that's too much, because then it would misfire in the oom testcase, where failing is ok (desireble even, we want to avoid blocking after all). So needs to be a switch (or else we need to filter it in results, and that's a bit a maintenance headache from a CI pov). -Danile
If you wonder where all the info level stuff happens that we have to ignore: suspend/resume is a primary culprit (fairly important for gfx/desktops), but there's a bunch of other places. Even if we ignore everything at info and below we still need filters because some drivers are a bit too trigger-happy (i915 definitely included I guess, so everyone contributes to this problem).
Thanks for the clarification.
Michal Hocko SUSE Labs