On 12/05, David Rientjes wrote: > > On Thu, 5 Dec 2013, Oleg Nesterov wrote: > > > > Your v2 series looks good and I suspect anybody trying them doesn't have > > > additional reports of the infinite loop? Should they be marked for > > > stable? > > > > Unlikely... > > > > I think the patch from Sameer makes more sense for stable as a temporary > > (and obviously incomplete) fix. > > There's a problem because none of this is currently even in linux-next. I > think we could make a case for getting Sameer's patch at > http://marc.info/?l=linux-kernel&m=138436313021133 to be merged for > stable, Probably. Ah, I just noticed that this change - if (p->flags & PF_EXITING) { + if (p->flags & PF_EXITING || !pid_alive(p)) { is not needed. !pid_alive(p) obviously implies PF_EXITING. > but then we'd have to revert it in linux-next Or perhaps Sameer can just send his fix to stable/gregkh. Just the changelog should clearly explain that this is the minimal workaround for stable. Once again it doesn't (and can't) fix all problems even in oom_kill_process() paths, but it helps anyway to avoid the easy-to-trigger hang. > before merging your > series at http://marc.info/?l=linux-kernel&m=138616217925981. Just in case, I won't mind to rediff my patches on top of Sameer's patch and then add git-revert patch. > All of the > issues you present in that series seem to be stable material, so why not > just go ahead with your series and mark it for stable for 3.13? OK... I can do this too. I do not really like this because it adds thread_head/node but doesn't remove the old ->thread_group. We will do this later, but obviously this is not the stable material. IOW, if we send this to stable, thread_head/node/for_each_thread will be only used by oom_kill.c. And this is risky. For example, 1/4 depends on (at least) another patch I sent in preparation for this change, commit 81907739851 "kernel/fork.c:copy_process(): don't add the uninitialized child to thread/task/pid lists", perhaps on something else. So personally I'd prefer to simply send the workaround for stable. Oleg. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>