On 2018/07/17 9:55, Tetsuo Handa wrote: >> I don't get, why it's necessary to drop the cgroup oom killer to merge your fix? >> I'm happy to help with rebasing and everything else. > > Yes, I wish you rebase your series on top of OOM lockup (CVE-2016-10723) mitigation > patch ( https://marc.info/?l=linux-mm&m=153112243424285&w=4 ). It is a trivial change > and easy to cleanly backport (if applied before your series). > > Also, I expect you to check whether my cleanup patch which removes "abort" path > ( [PATCH 1/2] at https://marc.info/?l=linux-mm&m=153119509215026&w=4 ) helps > simplifying your series. I don't know detailed behavior of your series, but I > assume that your series do not kill threads which current thread should not wait > for MMF_OOM_SKIP. syzbot is hitting WARN(1) due to mem_cgroup_out_of_memory() == false. https://syzkaller.appspot.com/bug?id=ea8c7912757d253537375e981b61749b2da69258 I can't tell what change is triggering this race. Maybe removal of oom_lock from the oom reaper made more likely to hit. But anyway I suspect that static bool oom_kill_memcg_victim(struct oom_control *oc) { if (oc->chosen_memcg == NULL || oc->chosen_memcg == INFLIGHT_VICTIM) return oc->chosen_memcg; // <= This line is still broken because /* We have one or more terminating processes at this point. */ oc->chosen_task = INFLIGHT_VICTIM; is not called. Also, that patch is causing confusion by reviving schedule_timeout_killable(1) with oom_lock held. Can we temporarily drop cgroup-aware OOM killer from linux-next.git and apply my cleanup patch? Since the merge window is approaching, I really want to see how next -rc1 would look like...
