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 A63B0C43462 for ; Mon, 3 May 2021 18:21:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 754D8613BB for ; Mon, 3 May 2021 18:21:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229641AbhECSV4 (ORCPT ); Mon, 3 May 2021 14:21:56 -0400 Received: from ale.deltatee.com ([204.191.154.188]:60390 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229472AbhECSVy (ORCPT ); Mon, 3 May 2021 14:21:54 -0400 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=btAG4Vr3f5GLEzhmHmHkox49Ultu4PcxMLcQ9c/IbGg=; b=Kok6u9aTNQ/DTtp1uHx6mPrNjx K8OjtI9P0WjkLvmrMoggQoeKvdKKIN8gAf//ZoorpRZxjiWc12WO+bWHaVjJOoXdbmJdZIAIUUL1x Q6vPsiblyYvlCii5btWVUafaskZ5yfaz9cDn/nnSxzVz+4JYypdaPqNwwnVcKoWo4Sne+INjhTfrV ZW3hhWBsn8zY0B97HLikca3VnzSWWlgwewCA8CA6MeLf174EE1h8BrpH8TB/RtRDj7O61YRad/Djs j0PGayIK3T4fD/uzv3Z6XaDwcSoaqpjnxy6wGL2mD+pDdVcJztSQdxhWIFsh1Ipo3mp/N2GlM7zPU EFmnDZ6w==; Received: from guinness.priv.deltatee.com ([172.16.1.162]) by ale.deltatee.com with esmtp (Exim 4.92) (envelope-from ) id 1lddBX-0000Z1-P0; Mon, 03 May 2021 12:20:49 -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> <8ea5b5b3-e10f-121a-bd2a-07db83c6da01@deltatee.com> <3bced3a4-b826-46ab-3d98-d2dc6871bfe1@nvidia.com> From: Logan Gunthorpe Message-ID: <8402ca0b-f147-fb99-bab4-71f047d2ba46@deltatee.com> Date: Mon, 3 May 2021 12:20:38 -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: <3bced3a4-b826-46ab-3d98-d2dc6871bfe1@nvidia.com> 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) Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On 2021-05-03 12:17 p.m., John Hubbard wrote: > On 5/3/21 8:57 AM, Logan Gunthorpe wrote: >> >> >> 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. > > That's the thing: memory failure should be exceedingly rare for this. > Therefore, just fail out entirely (which I don't expect we'll likely > ever see), instead of doing all this weird stuff to try to continue > on if you cannot allocate a single page. If you are in that case, the > system is not in a state that is going to run your dma p2p setup well > anyway. > > I think it's *less* complexity to allocate up front, fail early if > allocation fails, and then not have to deal with these really odd > quirks at the lower levels. > I don't see how it's all that weird. We're skipping a warning if we can't allocate memory to calculate part of the message. It's really not necessary. If the memory really can't be allocated then something else will fail, but we really don't need to fail here because we couldn't print a verbose warning message. Logan