On 12/14/18 22:27, Thomas Schoebel-Theuer wrote:
On 12/14/18 21:24, Borislav Petkov wrote:
Because apei_resources_fini() happens under the same condition check and
if arch_apei_filter_addr was false, it should not become true, all of a
sudden. Or?
please take a look at the stacktrace. For some reason, and only at
that specific hardware, the condition is false, there but later the
indicated error exit is taken whose message you can see immediately
before the stack trace.
Ah, I overlooked that commit e56c92565dfe2 is already providing a
different solution to the same problem in newer kernels _only_, as a
_side_ effect (not clear to me from the description, but clear from
reading the code).
But this patch is not present at the 4.4.166 kernel where I found the
problem and fixed it internally in a different way.
The 4.4.166 code looks like this, without the if-statement you are
mentioning, unconditionally trying to free the unitinialized variable
under certain circumstances:
d91525eb8ee6a (Chen, Gong 2014-12-10 13:53:26 -0800 553) arch_res_fini:
d91525eb8ee6a (Chen, Gong 2014-12-10 13:53:26 -0800 554)
apei_resources_fini(&arch_res);
d91525eb8ee6a (Chen, Gong 2014-12-10 13:53:26 -0800 555) nvs_res_fini:
4134b8c8811f2 (Huang Ying 2011-12-08 11:25:50 +0800 556)
apei_resources_fini(&nvs_resources);
23f124ca3dda9 (Huang Ying 2010-09-29 19:53:54 +0800 557) return rc;
So another alternative would be backporting e56c92565dfe2 to the 4.4 LTS
series. Also fine for me.
