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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 CC521C4338F for ; Tue, 10 Aug 2021 11:04:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2E8E860F55 for ; Tue, 10 Aug 2021 11:04:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2E8E860F55 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=virtuozzo.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 5463D6B0071; Tue, 10 Aug 2021 07:04:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F7A38D0001; Tue, 10 Aug 2021 07:04:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E4856B0073; Tue, 10 Aug 2021 07:04:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0114.hostedemail.com [216.40.44.114]) by kanga.kvack.org (Postfix) with ESMTP id 2182D6B0071 for ; Tue, 10 Aug 2021 07:04:14 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B644721251 for ; Tue, 10 Aug 2021 11:04:13 +0000 (UTC) X-FDA: 78458886786.29.B4B5440 Received: from relay.sw.ru (relay.sw.ru [185.231.240.75]) by imf09.hostedemail.com (Postfix) with ESMTP id 1666A3001D8C for ; Tue, 10 Aug 2021 11:04:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuozzo.com; s=relay; h=Content-Type:MIME-Version:Date:Message-ID:From: Subject; bh=IWF7YnjMUZ36VVps825FuadCPSXkcIXXEF9D9EXb+Jw=; b=jfqhwSlskPaXHRioD gd3dJw7xEkdzxwW4uAG6nzxFaR86y7Gm1PXlTlit1dPLVildLYwWGKwRXkFIx2euTkd/3JthQm+mD PC8/8C9ptqj/YCqDDcHqlnAVgJMBPfAl/dQUQnGDI+uCVZ0Pdhcs+T+q7Zh3KpGmUv35hP90WB1Go =; Received: from [10.93.0.56] by relay.sw.ru with esmtp (Exim 4.94.2) (envelope-from ) id 1mDPYG-006wYL-96; Tue, 10 Aug 2021 14:04:08 +0300 Subject: Re: [PATCH] mm: use in_task() in __gfp_pfmemalloc_flags() To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel@openvz.org References: <20210809112448.3d7d8f2522e18e75ba6e31c0@linux-foundation.org> From: Vasily Averin Message-ID: <8bbc1658-03b2-f64e-d11a-153da3eb723a@virtuozzo.com> Date: Tue, 10 Aug 2021 14:04:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210809112448.3d7d8f2522e18e75ba6e31c0@linux-foundation.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=virtuozzo.com header.s=relay header.b=jfqhwSls; dmarc=pass (policy=quarantine) header.from=virtuozzo.com; spf=pass (imf09.hostedemail.com: domain of vvs@virtuozzo.com designates 185.231.240.75 as permitted sender) smtp.mailfrom=vvs@virtuozzo.com X-Stat-Signature: p6fsiooq5y6fy3wx9nywyo1puawoxe7m X-Rspamd-Queue-Id: 1666A3001D8C X-Rspamd-Server: rspam01 X-HE-Tag: 1628593452-691755 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 8/9/21 9:24 PM, Andrew Morton wrote: > On Mon, 9 Aug 2021 11:23:29 +0300 Vasily Averin wrote: > >> obsoleted in_interrupt() include task context with disabled BH, >> it's better to use in_task() instead. > > Are these just blind conversions, or have you verified in each case > that it is correct to newly take these code paths inside > local_bh_disable()? > > If "yes" then please provide the reasoning in each changelog? I cannot say that it is blind conversion. In all fixed patches in_interrupt() is used to identify task context and access current. it is incorrect because in_interrupt() include task context with disabled BH Recently I hit some bug and spend a lot of time for its investigation. Right now I investigate some other issue in neighborhood, noticed sadly familiar pattern and decided fix them too. Then noticed few more similar places. In fact I would like to replace all such places in mm in one patch. Do you want to consider each of these cases separately? In this particular case in_interrupt() is used to prevent current access. I think it is safe to look at current->flags and call oom_reserves_allowed() for tasks with disabled BH and I believe this should provide more correct result. Historically this check was added to handle interrupt context and said nothing special about task context with disabled BH. Could you please clarify wich kind of arguments should I provide? Thank you, Vasily Averin