Received: by 10.213.65.68 with SMTP id h4csp3393314imn; Mon, 9 Apr 2018 20:45:27 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/zR0qx48dXZJS82buGyLR6ODEXd+uHpn4L/6uoNfQbX9SJ9HsFaevxnU/M1kKEUoZDiLp2 X-Received: by 10.167.134.70 with SMTP id a6mr1298340pfo.203.1523331927083; Mon, 09 Apr 2018 20:45:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523331927; cv=none; d=google.com; s=arc-20160816; b=mteWY8LiyDS33r4n15IiN540y4aAzRwSnjzSN/160AFwzuEDvYms9rok6WgOqwdiA9 ZJs0UhwKhgvbny0abtBXJipGZVgxdK+Us8pWNR1sdp0mbxxRYnemzGH01IeKu8AwXalu xYmxQh87p7Fl3D5698Bbsyf6BOIXNBZc/GkC/1ceBAYEfSyxASrfvat9v0PzkzDPlGal iw1Iy9HX36X/9omjY9qUDg133w/2T3eprOjIdSiWcCGEgtZ7ahs0lbfVKVSe3j8i7H9A o/eL8EDTiuLXNoxBA+Og7xIQ5jkvq/83c5bCpf1LQVoje3m/jJocMZaX6EcAdH9ups/L 8p4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=7F5OhopYv13ZfMUGDJ6YzRq21kCY48jMR4Qu8WYUbt0=; b=hzphITTU/y/+rJ+8rfyK8M8lb5Hm5aWv1IflsbTI7kBLMSeuuhG5kHPnlhTNFggXQg qC0Uks5nCTbtttktuMobhagAJSRBzFtQplC1WE6LD9qgXzUQQQYTHm2rWxn2Ae2hTvoF b1x1LrsyoEDHZu2ARHZQVgjU0VoCMxnTh/QXEEg9r6W6pCXbjvYsqY79BT6ivGTfySdG WKnZIbljEfHYRo8I2gPN+qHxq6tGNecB8CDeNTwAfO0IRR2kNukC+vVn/5wGm6jfIhll VbwaTeGtdVPxtt1+AB8FSTX8EB9KiAEm0397FQU2ccjkgcTZgVMNneuC7cNqs1nmWbfL 83RA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=i0D353NZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y70si1371674pfg.121.2018.04.09.20.44.50; Mon, 09 Apr 2018 20:45:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=i0D353NZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752076AbeDJDlq (ORCPT + 99 others); Mon, 9 Apr 2018 23:41:46 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:52605 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751833AbeDJDlp (ORCPT ); Mon, 9 Apr 2018 23:41:45 -0400 Received: by mail-wm0-f67.google.com with SMTP id g8so22985178wmd.2 for ; Mon, 09 Apr 2018 20:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7F5OhopYv13ZfMUGDJ6YzRq21kCY48jMR4Qu8WYUbt0=; b=i0D353NZWieOScpl1ih9gDc84inuKud2lG91x2RhZ3OAFyBaj9VPTCnedEclXVZg1z 1RJ4iZyFIHg/J6n84n3RbpF5AWHLeG8UpHlX0n8BozwJxm2BVJtwITJ86LPFVCxuFkCe CAPZnGWevn2VKS6DKzmIcOYGhVLTc2RxD2IwDULGsfDE3U8FRHfUPa5oY9DJx5eohdC3 kEIFVEuaSeB6m/6CAVVoDtacFwUglA+KND5RXGqSjZJ6DtWxDuwZlkj0f9pL8dym8rxZ jAkIRhowoX2VwAGHBdMGSSsyxafE3xYS40h3s4wEKNFjU7ELLsdm4ADqpvI67wdTc5uf vt+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7F5OhopYv13ZfMUGDJ6YzRq21kCY48jMR4Qu8WYUbt0=; b=dBXWYTe3Y6Q4q3t6vGFSHTWdvTQvNzKubO9QrGOVrT6n3KUKn/kPHqkdvHCpd69WAs iLUgd19d5vvAgC2plIgAtoGNgPRCTsg1HsuDsyPJQad3iYGWR0lAg62omc67xIZ/fhcj QPlmAGfnpxtkD9d0+yn6N+gztlXNL10FtxzJT8z8+R0bLfEFFraTxEfHXJ33k/eVIyVL Nyyq3p1VKlStR/gcT1i42vZ7p2IkPiMhdRC8kRCU1FONvHKIVRw3Yyf8tXsHx0O5MnWP 05TnPMcfSL4y9e+HtLebc0GvIrWMSvtB4gacxo7JFwRA4cm7cECdHqBHH9rLOEci4Ool TZAg== X-Gm-Message-State: ALQs6tAcL0OwQ0rg/oFaeZ42jwtgw8z4EchC8NVk+uYM5RuGfGSWwC/h repLuTcZ6MRE5sYdnvuVqjkVqXNyFH2KA0CzxjI= X-Received: by 10.80.145.111 with SMTP id f44mr740765eda.29.1523331704434; Mon, 09 Apr 2018 20:41:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.201.76 with HTTP; Mon, 9 Apr 2018 20:41:44 -0700 (PDT) In-Reply-To: <20180409231230.1ab99e85@vmware.local.home> References: <1523153783-20579-1-git-send-email-zhaoyang.huang@spreadtrum.com> <20180407234812.2bf2b24b@gandalf.local.home> <20180408084717.62ee4f9e@gandalf.local.home> <20180409094944.6399b211@gandalf.local.home> <20180409231230.1ab99e85@vmware.local.home> From: Zhaoyang Huang Date: Tue, 10 Apr 2018 11:41:44 +0800 Message-ID: Subject: Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN To: Steven Rostedt , Michal Hocko Cc: Ingo Molnar , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 10, 2018 at 11:12 AM, Steven Rostedt wrote: > On Tue, 10 Apr 2018 10:32:36 +0800 > Zhaoyang Huang wrote: > >> For bellowing scenario, process A have no intension to exhaust the >> memory, but will be likely to be selected by OOM for we set >> OOM_CORE_ADJ_MIN for it. >> process A(-1000) process B >> >> i = si_mem_available(); >> if (i < nr_pages) >> return -ENOMEM; >> schedule >> ---------------> >> allocate huge memory >> <------------- >> if (user_thread) >> set_current_oom_origin(); >> >> for (i = 0; i < nr_pages; i++) { >> bpage = kzalloc_node > > Is this really an issue though? > > Seriously, do you think you will ever hit this? > > How often do you increase the size of the ftrace ring buffer? For this > to be an issue, the system has to trigger an OOM at the exact moment > you decide to increase the size of the ring buffer. That would be an > impressive attack, with little to gain. > > Ask the memory management people. If they think this could be a > problem, then I'll be happy to take your patch. > > -- Steve add Michael for review. Hi Michael, I would like suggest Steve NOT to set OOM_CORE_ADJ_MIN for the process with adj = -1000 when setting the user space process as potential victim of OOM. Steve doubts about the possibility of the scenario. In my opinion, we should NOT break the original concept of the OOM, that is, OOM would not select -1000 process unless it config it itself. With regard to the possibility, in memory thirsty system such as android on mobile phones, there are different kinds of user behavior or test script to attack or ensure the stability of the system. So I suggest we'd better keep every corner case safe. Would you please give a comment on that? thanks