On Tue 18-05-21 12:06:42, David Hildenbrand wrote:
On 18.05.21 11:59, Michal Hocko wrote:
On Sun 16-05-21 10:29:24, Mike Rapoport wrote:
On Fri, May 14, 2021 at 11:25:43AM +0200, David Hildenbrand wrote:
[...]
if (!page)return VM_FAULT_OOM;err = set_direct_map_invalid_noflush(page, 1);if (err) {put_page(page);return vmf_error(err);Would we want to translate that to a proper VM_FAULT_..., which would most probably be VM_FAULT_OOM when we fail to allocate a pagetable?
That's what vmf_error does, it translates -ESOMETHING to VM_FAULT_XYZ.
I haven't read through the rest but this has just caught my attention. Is it really reasonable to trigger the oom killer when you cannot invalidate the direct mapping. From a quick look at the code it is quite unlikely to se ENOMEM from that path (it allocates small pages) but this can become quite sublte over time. Shouldn't this simply SIGBUS if it cannot manipulate the direct mapping regardless of the underlying reason for that?
OTOH, it means our kernel zones are depleted, so we'd better reclaim somehow ...
Killing a userspace seems to be just a bad way around that.
Although I have to say openly that I am not a great fan of VM_FAULT_OOM in general. It is usually a a wrong way to tell the handle the failure because it happens outside of the allocation context so you lose all the details (e.g. allocation constrains, numa policy etc.). Also whenever there is ENOMEM then the allocation itself has already made sure that all the reclaim attempts have been already depleted. Just consider an allocation with GFP_NOWAIT/NO_RETRY or similar to fail and propagate ENOMEM up the call stack. Turning that into the OOM killer sounds like a bad idea to me. But that is a more general topic. I have tried to bring this up in the past but there was not much of an interest to fix it as it was not a pressing problem...