From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92396C282D7 for ; Sat, 2 Feb 2019 11:06:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6B6352146E for ; Sat, 2 Feb 2019 11:06:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727500AbfBBLGM (ORCPT ); Sat, 2 Feb 2019 06:06:12 -0500 Received: from www262.sakura.ne.jp ([202.181.97.72]:32816 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726757AbfBBLGM (ORCPT ); Sat, 2 Feb 2019 06:06:12 -0500 Received: from fsav303.sakura.ne.jp (fsav303.sakura.ne.jp [153.120.85.134]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id x12B6AFR081072; Sat, 2 Feb 2019 20:06:10 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav303.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav303.sakura.ne.jp); Sat, 02 Feb 2019 20:06:10 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav303.sakura.ne.jp) Received: from [192.168.1.8] (softbank126126163036.bbtec.net [126.126.163.36]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id x12B69Es081069 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Sat, 2 Feb 2019 20:06:09 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: [PATCH v2] mm, oom: Tolerate processes sharing mm with different view of oom_score_adj. To: Michal Hocko Cc: Andrew Morton , Johannes Weiner , David Rientjes , linux-mm@kvack.org, Yong-Taek Lee , Paul McKenney , Linus Torvalds , LKML References: <1547636121-9229-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> <20190116110937.GI24149@dhcp22.suse.cz> <88e10029-f3d9-5bb5-be46-a3547c54de28@I-love.SAKURA.ne.jp> <20190116121915.GJ24149@dhcp22.suse.cz> <6118fa8a-7344-b4b2-36ce-d77d495fba69@i-love.sakura.ne.jp> <20190116134131.GP24149@dhcp22.suse.cz> <20190117155159.GA4087@dhcp22.suse.cz> <20190131071130.GM18811@dhcp22.suse.cz> <5fd73d87-3e4b-f793-1976-b937955663e3@i-love.sakura.ne.jp> <20190201091433.GH11599@dhcp22.suse.cz> From: Tetsuo Handa Message-ID: <643b94c2-d720-fa95-d6ee-4f0ea6e2686a@i-love.sakura.ne.jp> Date: Sat, 2 Feb 2019 20:06:07 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <20190201091433.GH11599@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/02/01 18:14, Michal Hocko wrote: > On Fri 01-02-19 05:59:55, Tetsuo Handa wrote: >> On 2019/01/31 16:11, Michal Hocko wrote: >>> This is really ridiculous. I have already nacked the previous version >>> and provided two ways around. The simplest one is to drop the printk. >>> The second one is to move oom_score_adj to the mm struct. Could you >>> explain why do you still push for this? >> >> Dropping printk() does not close the race. > > But it does remove the source of a long operation from the RCU context. > If you are not willing to post such a trivial patch I will do so. > >> You must propose an alternative patch if you dislike this patch. > > I will eventually get there. > This is really ridiculous. "eventually" cannot be justified as a reason for rejecting this patch. I want a patch which can be easily backported _now_ . If vfork() => __set_oom_adj() => execve() sequence is permitted, someone can try vfork() => clone() => __set_oom_adj() => execve() sequence. And below program demonstrates that task->vfork_done based exemption in __set_oom_adj() is broken. It is not always the task_struct who called vfork() that will call execve(). ---------------------------------------- #define _GNU_SOURCE #include #include #include #include #include #include #include static int thread1(void *unused) { char *args[3] = { "/bin/true", "true", NULL }; int fd = open("/proc/self/oom_score_adj", O_WRONLY); write(fd, "1000", 4); close(fd); execve(args[0], args, NULL); return 0; } int main(int argc, char *argv[]) { printf("PID=%d\n", getpid()); if (vfork() == 0) { clone(thread1, malloc(8192) + 8192, CLONE_VM | CLONE_FS | CLONE_FILES, NULL); sleep(1); _exit(0); } return 0; } ---------------------------------------- PID=8802 [ 1138.425255] updating oom_score_adj for 8802 (a.out) from 0 to 1000 because it shares mm with 8804 (a.out). Report if this is unexpected. Current loop to enforce same oom_score_adj is 99%+ ending in vain. And even your "eventually" will remove this loop.