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,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 43330C433ED for ; Mon, 3 May 2021 15:57:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A86D0610C8 for ; Mon, 3 May 2021 15:57:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A86D0610C8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=deltatee.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 171A96B0070; Mon, 3 May 2021 11:57:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 122496B0071; Mon, 3 May 2021 11:57:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDCD56B0072; Mon, 3 May 2021 11:57:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0046.hostedemail.com [216.40.44.46]) by kanga.kvack.org (Postfix) with ESMTP id D2FBB6B0070 for ; Mon, 3 May 2021 11:57:55 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 86BD16C04 for ; Mon, 3 May 2021 15:57:55 +0000 (UTC) X-FDA: 78100375710.34.40FE237 Received: from ale.deltatee.com (ale.deltatee.com [204.191.154.188]) by imf02.hostedemail.com (Postfix) with ESMTP id 6111040002E1 for ; Mon, 3 May 2021 15:57:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=deltatee.com; s=20200525; h=Subject:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:content-disposition; bh=GRATXEdDLtmHYm2zR9BEphk7UXJZV3Wtupp7N/wM0ac=; b=KNKJz1k9cORPoOeawf3gcXlCu5 eI5GgEzgHHpsYGlQc305kr/f0HuWYO8UNczmVWxt1wCYcoLWokF5N2V6w0Tr7HbLBBwOhuaZYiBVJ RXbD1gckXcqlsUMeH9JobfBXeFE5SdNlofp70fCSoNaQ37ycRBY2AiN/N2MGbLxcVQsKPdjEDluEe xb+cwsUh7oSz+dRCBwiTM/nRSQ/P9EnqjLLnduy9HUZFFtdlvwQIiZwlOJ3I55O2xSohd2rV9g6Un JoFznbmJCUxco07ATLbqEg9Sb2LPcjgV4llvYQvj9+M1NAvWehU2wAYl3X5X+lgSipjOFaQhNM/X1 iheL+1Kg==; Received: from guinness.priv.deltatee.com ([172.16.1.162]) by ale.deltatee.com with esmtp (Exim 4.92) (envelope-from ) id 1ldax0-0003G8-Dd; Mon, 03 May 2021 09:57:39 -0600 To: John Hubbard , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, iommu@lists.linux-foundation.org Cc: Stephen Bates , Christoph Hellwig , Dan Williams , Jason Gunthorpe , =?UTF-8?Q?Christian_K=c3=b6nig?= , Don Dutile , Matthew Wilcox , Daniel Vetter , Jakowski Andrzej , Minturn Dave B , Jason Ekstrand , Dave Hansen , Xiong Jianxin , Bjorn Helgaas , Ira Weiny , Robin Murphy , Bjorn Helgaas References: <20210408170123.8788-1-logang@deltatee.com> <20210408170123.8788-2-logang@deltatee.com> From: Logan Gunthorpe Message-ID: <8ea5b5b3-e10f-121a-bd2a-07db83c6da01@deltatee.com> Date: Mon, 3 May 2021 09:57:35 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.162 X-SA-Exim-Rcpt-To: bhelgaas@google.com, robin.murphy@arm.com, ira.weiny@intel.com, helgaas@kernel.org, jianxin.xiong@intel.com, dave.hansen@linux.intel.com, jason@jlekstrand.net, dave.b.minturn@intel.com, andrzej.jakowski@intel.com, daniel.vetter@ffwll.ch, willy@infradead.org, ddutile@redhat.com, christian.koenig@amd.com, jgg@ziepe.ca, dan.j.williams@intel.com, hch@lst.de, sbates@raithlin.com, iommu@lists.linux-foundation.org, linux-mm@kvack.org, linux-pci@vger.kernel.org, linux-block@vger.kernel.org, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, jhubbard@nvidia.com X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: [PATCH 01/16] PCI/P2PDMA: Pass gfp_mask flags to upstream_bridge_distance_warn() X-SA-Exim-Version: 4.2.1 (built Wed, 08 May 2019 21:11:16 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=deltatee.com header.s=20200525 header.b=KNKJz1k9; dmarc=none; spf=pass (imf02.hostedemail.com: domain of logang@deltatee.com designates 204.191.154.188 as permitted sender) smtp.mailfrom=logang@deltatee.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6111040002E1 X-Stat-Signature: fhd1qz9q36j5kohn9gs86g1bcfp66wi1 Received-SPF: none (deltatee.com>: No applicable sender policy available) receiver=imf02; identity=mailfrom; envelope-from=""; helo=ale.deltatee.com; client-ip=204.191.154.188 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620057443-475642 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 2021-05-01 9:58 p.m., John Hubbard wrote: > Another odd thing: this used to check for memory failure and just give > up, and now it doesn't. Yes, I realize that it all still works at the > moment, but this is quirky and we shouldn't stop here. > > Instead, a cleaner approach would be to push the memory allocation > slightly higher up the call stack, out to the > pci_p2pdma_distance_many(). So pci_p2pdma_distance_many() should make > the kmalloc() call, and fail out if it can't get a page for the seq_buf > buffer. Then you don't have to do all this odd stuff. I don't really agree with this assessment. If kmalloc fails to initialize the seq_buf() (which should be very rare), the only thing that is lost is the one warning print that tells the user the command line parameter needed disable the ACS. Everything else works fine, nothing else can fail. I don't see the need to add extra complexity just so the code errors out in no-mem instead of just skipping the one, slightly more informative, warning line. Also, keep in mind the result of all these functions are cached so it only ever happens once. So for this to matter, the user would have to do their first transaction between two devices exactly at the time memory allocations would fail. > Furthermore, the call sites can then decide for themselves which GFP > flags, GFP_ATOMIC or GFP_KERNEL or whatever they want for kmalloc(). > > A related thing: this whole exercise would go better if there were a > preparatory patch or two that changed the return codes in this file to > something less crazy. There are too many functions that can fail, but > are treated as if they sort-of-mostly-would-never-fail, in the hopes of > using the return value directly for counting and such. This is badly > mistaken, and it leads developers to try to avoid returning -ENOMEM > (which is what we need here). Hmm? Which functions can fail? and how? Logan