Michal Hocko <mhocko@xxxxxxx> writes: > On Mon 03-02-14 12:27:17, Andrew Morton wrote: >> On Mon, 3 Feb 2014 15:15:30 +0100 Michal Hocko <mhocko@xxxxxxx> wrote: >> >> > On Fri 31-01-14 12:36:20, Andrew Morton wrote: >> > > Subject: [obsolete] memcg-do-not-hang-on-oom-when-killed-by-userspace-oom-access-to-memory-reserves.patch removed from -mm tree >> > > To: mhocko@xxxxxxx,ebiederm@xxxxxxxxxxxx,hannes@xxxxxxxxxxx,kamezawa.hiroyu@xxxxxxxxxxxxxx,rientjes@xxxxxxxxxx,stable@xxxxxxxxxxxxxxx,mm-commits@xxxxxxxxxxxxxxx >> > > From: akpm@xxxxxxxxxxxxxxxxxxxx >> > > Date: Fri, 31 Jan 2014 12:36:20 -0800 >> > > >> > > >> > > The patch titled >> > > Subject: memcg: do not hang on OOM when killed by userspace OOM access to memory reserves >> > > has been removed from the -mm tree. Its filename was >> > > memcg-do-not-hang-on-oom-when-killed-by-userspace-oom-access-to-memory-reserves.patch >> > > >> > > This patch was dropped because it is obsolete >> > >> > What has made the patch obsolete? I do not see any alternative merged in >> > the Linus' tree. >> >> hm, sorry, I thought I'd sent an email about this. >> >> The patch hasn't been confirmed to fix the issue Eric reported, and it >> doesn't appear that this testing avenue will be happening. And the >> discussion between yourself and David is nowhere near completed. >> >> So I don't see the patch as being mergeable at this stage. The issues >> should be revisited and having a particular patch floating around in >> -mm in permastuck state will if anything prevent this from happening. > > OK, I will get back to it later after other parts of the oom discussions > settle down. The only reporter was Eric so far which means that the rush > is not really needed. I was just surprised that it was marked obsolete > because that would imply that it is no longer needed. Of course I found that at the time with about 5 minutes of testing. The real reason I haven't come back is that I have found so many more bugs that the easiest solution was to tell my users don't do that! Well that and it seemed like all it took to verify the bug was simple inspection. I was heartened to see that Michal had been carrying this forward. I was surprised and am still suprised that there is controversy. I will see if I can take a look in the next couple of days. I have been busily working through the details so my users can get the latest fixes so hopefully I can stop people don't do that! don't do that! That really isn't the solution for kernel problems. >> If you think this particular patch is the correct way to go then please >> resend it from scratch and let's fire things up again. > > I will not push it right now and wait for LSF where we are going to > discuss OOM related topics and hopefully come to a conclusion. Have you seen the patch I posted last night where accept was triggering an OOM (no cgroups and with 4GiB free) when trying to allocate a 32KiB page? I would love to have some eyeballs with recent mm knowledge on that problem. Eric -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html