Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756060AbbBFWLD (ORCPT ); Fri, 6 Feb 2015 17:11:03 -0500 Received: from mail-ig0-f169.google.com ([209.85.213.169]:53583 "EHLO mail-ig0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755001AbbBFWK7 (ORCPT ); Fri, 6 Feb 2015 17:10:59 -0500 MIME-Version: 1.0 In-Reply-To: References: <20150206162301.18031.32251.stgit@buzz> <20150206162303.18031.37408.stgit@buzz> Date: Fri, 6 Feb 2015 14:10:58 -0800 X-Google-Sender-Auth: ecDLBEM0-6SXKMzcBVcvDa3Eujs Message-ID: Subject: Re: [PATCH 2/2] kernel/fork: handle put_user errors for CLONE_PARENT_SETTID From: Linus Torvalds To: Konstantin Khlebnikov Cc: Konstantin Khlebnikov , Linux API , Andrew Morton , Linux Kernel Mailing List , Roman Gushchin , Nikita Vetoshkin , Oleg Nesterov , Pavel Emelyanov Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1751 Lines: 39 On Fri, Feb 6, 2015 at 1:13 PM, Konstantin Khlebnikov wrote: > > Currently that works fine only because kernel retries 0-order allocations > endlessly. But pagefault_out_of_memory() is never called for non-user PF. > For kernel PF all oom-kills are triggered by buddy-allocator. This makes no sense. You're trying to fix what you perceive as a problem in the page fault handling in some totally different place. If *that* is what you are worried about, then damnit, just fix the page fault handler for the kernel case to send a signal or something for VM_FAULT_ENOMEM. Or, better yet, make it just trigger oom at return to user space - we could add a _TIF_OOM flag, for example, and make it part of the user-return logic (do_notify_resume), kind of how _TIF_SIGPENDING triggers a signal. Don't try to make horrible code in insane places that have nothing to do with the fundamental problem. Why did you pick this particular get/put user anyway? There are tons others that we don't test, why did you happen pick these and then make it have that horrible and senseless error handling? Because at *NO* point was it obvious that that patch had anything at all to do with "out of memory". Not in the code, not in your commit messages, *nowhere*. There is no way in hell I will take that kind of changes when you didn't even articulate why you wanted to do them in the commit messages, and the patches didn't look like they had anything to do with oom either. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/