Received: by 10.213.65.68 with SMTP id h4csp1958129imn; Thu, 5 Apr 2018 06:45:37 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+JSW0QB5fkNomjGBmeyDEGSED0xRTYVdO1YLBzNCJqy5UxbckGh916wq/MzURdsjp/XmGC X-Received: by 10.98.201.194 with SMTP id l63mr17244453pfk.126.1522935937281; Thu, 05 Apr 2018 06:45:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522935937; cv=none; d=google.com; s=arc-20160816; b=ZH5EvGqJURSFYrtv8KYhU06IC+EwL1VKYcTssdgHhcQoScXCjc3VPQ3jdSCOjoVIvs sd86u76vsNobEQYLo0vLAEDeTVko+WNt8iDSmI1axMTkBP3YytbUUHcZV/ANKS98lcFU bXyRvAtO5oDu6kpIgOkwIBeQw+tfh8zUGTUU7UDDgMMib+kIiGJAn4oSunoIlK77G3Ck x5pwpwhgfe/FaeyMZqkEOtRiC+XClWjIk/7VpWdBE1ptC5IEpGDuFFXUwiRQV+LoL/l5 2j8OIqn/G89jhT1BUQEXCfETfSPpfaEOItn5AzByTGLC5/2Np6Hh67eV9eGbnAThvGSe yxkA== 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=IZJrvIUDta2IiEvYXqFbttm4gFrUOg5pCOV9WdAFaNg=; b=RmI/rO01jXAk+2NpW7hI29xC9FQ0KcHfNUgfFKm1WmqKSunLuzNCB2VbQBU1Q8wTId MrN7Kg+FCjP3QCJFiN/Vr6hqumrgnBoUblUlWd6+kXzz1Et1bIq2BemC748YUdLryGGi wznj6VOOMr3Odt/qSlMAtzOvTp4Xk0cHBjyt77btsWpf77SyDD8O/cORfj++3mLlFqHl nskv+MjmFFY+fnk5u5g34r0r8DcX28Ybn/vgxw0ehnJRccTxQ5g+b+B6AXfldnk83/jh V1n7Tb8no2sxQ9eupXYFaW01a7LjAhBe5GfnygzYMhIhSfNm+LxtvBcSDghaea0iL7S+ AQrg== 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 s17si3797839pgq.421.2018.04.05.06.45.22; Thu, 05 Apr 2018 06:45:37 -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 S1751470AbeDENoC (ORCPT + 99 others); Thu, 5 Apr 2018 09:44:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:59222 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751275AbeDENnt (ORCPT ); Thu, 5 Apr 2018 09:43:49 -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 62E9E20B80; Thu, 5 Apr 2018 13:43:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 62E9E20B80 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: Thu, 5 Apr 2018 09:43:46 -0400 From: Steven Rostedt To: Joel Fernandes Cc: LKML , Michal Hocko , Zhaoyang Huang , Ingo Molnar , kernel-patch-test@lists.linaro.org, Andrew Morton , "open list:MEMORY MANAGEMENT" , Vlastimil Babka Subject: Re: [PATCH] ring-buffer: Add set/clear_current_oom_origin() during allocations Message-ID: <20180405094346.104cf288@gandalf.local.home> In-Reply-To: References: <20180404115310.6c69e7b9@gandalf.local.home> <20180404120002.6561a5bc@gandalf.local.home> <20180404121326.6eca4fa3@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 Wed, 4 Apr 2018 16:59:18 -0700 Joel Fernandes wrote: > Happy to try anything else, BTW when the si_mem_available check > enabled, this doesn't happen and the buffer_size_kb write fails > normally without hurting anything else. Can you remove the RETRY_MAYFAIL and see if you can try again? It may be that we just remove that, and if si_mem_available() is wrong, it will kill the process :-/ My original code would only add MAYFAIL if it was a kernel thread (which is why I created the mflags variable). -- Steve