On 08/19, Michal Hocko wrote: > > On Fri 12-08-16 11:41:13, Michal Hocko wrote: > > On Wed 03-08-16 23:08:04, Oleg Nesterov wrote: > > > > > > So if we want this change, why we can't simply do > > > > > > - if (!(tsk->flags & PF_SIGNALED) && > > > + if (!(tsk->signal->flags & SIGNAL_GROUP_COREDUMP) && > > > > > > ? > > > > This is what I had initially. But then the comment above the check made > > me worried that the parent of vforked child might get confused if the > > flag is cleared. I don't think the child can be confused... At least I can't imagine how this can happen. Anyway, I objected because the tsk->vfork != NULL check was wrong, in this case this tsk is vforke'd child, not parent. > So should I drop the vfork check and repost Probably yes. At least the SIGNAL_GROUP_COREDUMP will match the comment. > or we do not care about this > "regression" Honestly, I do not know ;) Personally, I am always scared when it comes to the subtle changes like this, you can never know what can be broken. And note that it can be broken 10 years later, like it happened with nscd ;) But if you send the s/PF_SIGNALED/SIGNAL_GROUP_COREDUMP/ change I will ack it ;) Even if it won't really fix this nscd problem (imo), because I guess nscd wants to reset ->clear_child_tid even if the signal was sig_kernel_coredump(). 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>