Received: by 10.213.65.68 with SMTP id h4csp369008imn; Fri, 30 Mar 2018 07:08:59 -0700 (PDT) X-Google-Smtp-Source: AIpwx48bGBc9V/shmpIuqiJwD/704MygdrHfoAAATvoYI+XKiKvNvlePcIrE7nCB2Qcyo4mf4kP+ X-Received: by 2002:a17:902:684d:: with SMTP id f13-v6mr12894554pln.230.1522418939091; Fri, 30 Mar 2018 07:08:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522418939; cv=none; d=google.com; s=arc-20160816; b=R8uEwAQGMhtnApBW2Dz8rnjiWlfMqAycCueUQE1OKDmgBoaUr+dZOH1bN8nWdpL1Df seYrKQHvMGmsdoF6H3CQrLPIBmX52lvGAUwbacoVZd+5zafO5Sm4pzGWoteXR6rjJ2WW 44XNihZJDQsaAQ3QlIJquA18D3AX8aoyry596cpLolxSup1A04EIea/UZ9PySr282fwh MT+ltk2km/CluXpwsgVTsJqh9kBO9xgdXNBuhoNitG8AOkLnsrFziqZUGemcfJBf4POR 6gszm6ISdEBNPAnBY9XmNgsiBw0XYlzs3JVUWMt5r0vpU97ZOdzHDZ3r2FB7OZG6KLpU 7apw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dmarc-filter:arc-authentication-results; bh=fQakAIl/WK9PwdyttP4Wr5ru2miLoWXqV2nliNxcxuc=; b=fUpoPqT2NpZMeFLyxcbRmpL/wqodGyUh0uZMb8mS6AxAE4rBFLSJlIoorLsAC3vK/n 2vvDv/c1yzHEhRydmPJoDFsYHg5ZQxGUes5L6LymuSQ1qBIhN8i6EG7fvd3NRvPspPRc gqCQ9NfwD4iHhU1pdfEqa/opYukwLgo5UwASYRGzFyr61/cOPU/pUo64zEWgZojgQqqj IvJWsk/ohg84lazxF4pkNFQDZ8QC0JiwNxcf75JxEyNfEi7uqHs7znP3/NfUoEfzakAj 47S/uaUfsniqHbrF46spJAGbDQ+qMlmyQjhr03fcUNDdTsGxJK0+FldGaK6FbrUJkzzK 5GxA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x4-v6si8194460plw.354.2018.03.30.07.08.44; Fri, 30 Mar 2018 07:08:59 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751384AbeC3OHi (ORCPT + 99 others); Fri, 30 Mar 2018 10:07:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:60168 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751216AbeC3OHh (ORCPT ); Fri, 30 Mar 2018 10:07:37 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 70AAC217D2; Fri, 30 Mar 2018 14:07:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 70AAC217D2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Fri, 30 Mar 2018 10:07:34 -0400 From: Steven Rostedt To: Zhaoyang Huang Cc: Ingo Molnar , linux-kernel@vger.kernel.org, kernel-patch-test@lists.linaro.org Subject: Re: [PATCH v1] kernel/trace:check the val against the available mem Message-ID: <20180330100734.7aa872f5@gandalf.local.home> In-Reply-To: References: <1522320104-6573-1-git-send-email-zhaoyang.huang@spreadtrum.com> <20180329120528.337bf6cb@gandalf.local.home> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 30 Mar 2018 11:32:22 +0800 Zhaoyang Huang wrote: > Steve, thanks for your quick feedback. The original purpose is to > avoid such kind > of OOM as kernel can not define the behavior of the application. I > think it is no need > to do the alloc->free process if we have known the number of pages > difinitly lead to failure. > Furthermore, the app which screw up the thing usually escape the OOM and cause > the innocent to be sacrificed. A couple of things. Your patch goes way too deep into coupling with the memory management subsystem. If I were to accept this patch, Linus would have a fit. That get_available_mem() does not belong in the tracing code. If you want that feature, you need to get the mm folks to accept it, and then tracing could call it. Next, this may be an issue with the GPF_RETRY_MAYFAIL should not trigger OOM (although, when it fails, other allocations that happen at that time and before the ring buffer can clean up, will cause an OOM). I'll send an email to folks about this. -- Steve