Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp104761imm; Fri, 21 Sep 2018 11:04:52 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYtGSVTayVibX1YCELtTN0796/1YkJMP0Al/IlOz92M7gFOb0xUe0yMXbLqAIt3Ts932c3R X-Received: by 2002:a17:902:47c2:: with SMTP id d2-v6mr46036000plh.317.1537553092277; Fri, 21 Sep 2018 11:04:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537553092; cv=none; d=google.com; s=arc-20160816; b=GOctK6aVfE9KiJ8Z2ZjtflirmD+HPBV9Sr8ZSUm9ceyH9sVUkORlT5pkd88rq4fguH V8EPwlOBzbViRCd3A0DMbZdC6sD7TI+91+rzMx7H0tWxwMnlXE9A671n8mN5OvXnJa/A iRH+CjZbae2my6s/PE4xSZIw4+Xbl9l6WrlgN6ijmatP8HZEFi19Cg/urUoMSj2bM9+f OziC7a6eEA1AT3v+h72vJH8srNDA8QHlP8VQw25V4+EmjB/aPKV2DLSy3uqdgVRWBCYn xxR5+S7IAhZn7l0irKzmzFtA8qNZNPIZepCJd1h6rqoDAO6tdiukVfA5AFhd4W/oM1FR kLvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to; bh=ce0EzbvUMiHHiBhl8o1D2L9VQymy/SHf0P0kkAcjEro=; b=moFCY+XC7YjvtzxVWEkFg+ENWSNWINgBHbKszB1AEl7DH41uBmgrE8kKtYUgZFKZGS 2+aY9ZMkO2pbU1Sl+tKhUXCG244oEs8uR+J23g4WIXN6Jn4LREieSYGK942xDEyxrXMp tpQ7Bc6QI5LMCYwbtQT5CEUYHb/tJrk/RGQqxsS3zwK92gSbougia9xNmSr3sM/wU9XO yYlTcEWQw40jI+BURluFLhJ7v1Fp7aBUGVXZrwACVnmAZsThxQcsB2SaXpXATIFzVq3Y 8aqOHhl1SUI/32srXQ4yAKQxAPI8XutcDkgpBOA+WJyvLPFUowkJOyHkvQqGyCHtBMvG HWOA== 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 w20-v6si2972005plp.260.2018.09.21.11.04.35; Fri, 21 Sep 2018 11:04:52 -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 S2391097AbeIUXxr (ORCPT + 99 others); Fri, 21 Sep 2018 19:53:47 -0400 Received: from ale.deltatee.com ([207.54.116.67]:45256 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390076AbeIUXxr (ORCPT ); Fri, 21 Sep 2018 19:53:47 -0400 Received: from guinness.priv.deltatee.com ([172.16.1.162]) by ale.deltatee.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1g3Plw-0001JR-GL; Fri, 21 Sep 2018 12:03:21 -0600 To: Bjorn Helgaas Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-nvme@lists.infradead.org, linux-rdma@vger.kernel.org, linux-nvdimm@lists.01.org, linux-block@vger.kernel.org, Stephen Bates , Christoph Hellwig , Keith Busch , Sagi Grimberg , Bjorn Helgaas , Jason Gunthorpe , Max Gurtovoy , Dan Williams , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Benjamin Herrenschmidt , Alex Williamson , =?UTF-8?Q?Christian_K=c3=b6nig?= , Jens Axboe , Jonathan Corbet References: <20180913001156.4115-1-logang@deltatee.com> <20180913001156.4115-7-logang@deltatee.com> <20180921164126.GI224714@bhelgaas-glaptop.roam.corp.google.com> From: Logan Gunthorpe Message-ID: Date: Fri, 21 Sep 2018 12:03:12 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180921164126.GI224714@bhelgaas-glaptop.roam.corp.google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.162 X-SA-Exim-Rcpt-To: corbet@lwn.net, axboe@kernel.dk, christian.koenig@amd.com, alex.williamson@redhat.com, benh@kernel.crashing.org, jglisse@redhat.com, dan.j.williams@intel.com, maxg@mellanox.com, jgg@mellanox.com, bhelgaas@google.com, sagi@grimberg.me, keith.busch@intel.com, hch@lst.de, sbates@raithlin.com, linux-block@vger.kernel.org, linux-nvdimm@lists.01.org, linux-rdma@vger.kernel.org, linux-nvme@lists.infradead.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, helgaas@kernel.org X-SA-Exim-Mail-From: logang@deltatee.com X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on ale.deltatee.com X-Spam-Level: X-Spam-Status: No, score=-8.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, GREYLIST_ISWHITE autolearn=ham autolearn_force=no version=3.4.1 Subject: Re: [PATCH v6 06/13] PCI/P2PDMA: Add P2P DMA driver writer's documentation X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-09-21 10:41 AM, Bjorn Helgaas wrote: >> +away, the one returned will be chosen at random. This function returns the PCI > > s/the one returned will be chosen at random/one will be chosen > arbitrarily/ ? (I doubt it's really random) You're the second person to ask this, but yes, we really do it randomly. Such that if there are multiple drivers getting resources they should be evenly distributed. It's not the ideal solution but if it were to do it arbitrarily then the code would likely return the same device all the time and any additional devices would not get used. >> +Struct Page Caveats >> +------------------- >> + >> +Driver writers should be very careful about not passing these special >> +struct pages to code that isn't prepared for it. At this time, the kernel >> +interfaces do not have any checks for ensuring this. This obviously >> +precludes passing these pages to userspace. > > Sounds like landmines here since the reader probably can't translate > "code that isn't prepared for it" into a list of interfaces that are > off-limits. But that's a VM issue that is above my pay grade, so I'm > not suggesting any change; just pointing out something that makes me > wonder "hmmm..., how would I act on this?" Yes, these are big landmines. These are the problems we have been fighting with trying to get P2P memory into the kernel and the first step seems to have settled on the developer using them has to be careful and ensure they are only sent to paths that are used correctly. This series does these things in the block layer and RDMA interface, but due to Jens not wanting to add warnings to the common code, it's still possible for a developer to code something that sends these pages to block devices that are not prepared for it. Logan