From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ale.deltatee.com (ale.deltatee.com [207.54.116.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 1126F21A04817 for ; Fri, 7 Apr 2017 10:59:34 -0700 (PDT) References: <1490911959-5146-1-git-send-email-logang@deltatee.com> <1490911959-5146-6-git-send-email-logang@deltatee.com> <20170331070950.GA9059@infradead.org> <435d4471-436b-87e6-8827-c9fc6cbdde2c@deltatee.com> <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> <22930db3-a194-8b60-5aab-4a8add1ddc55@deltatee.com> From: Logan Gunthorpe Message-ID: <6206d74b-b2e2-f1f7-5a9d-60f20d837374@deltatee.com> Date: Fri, 7 Apr 2017 11:59:20 -0600 MIME-Version: 1.0 In-Reply-To: Subject: Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams Cc: Jens Axboe , Keith Busch , "James E.J. Bottomley" , linux-scsi , "Martin K. Petersen" , "linux-nvdimm@lists.01.org" , linux-rdma@vger.kernel.org, linux-pci@vger.kernel.org, Steve Wise , "linux-kernel@vger.kernel.org" , linux-nvme@lists.infradead.org, Christoph Hellwig , Max Gurtovoy , Christoph Hellwig , Jason Gunthorpe List-ID: Hi Dan, On 03/04/17 06:07 PM, Dan Williams wrote: > The completely agnostic part is where I get worried, but I shouldn't > say anymore until I actually read the patch.The worry is cases where > this agnostic enabling allows unsuspecting code paths to do the wrong > thing. Like bypass iomem safety. Yup, you're right the iomem safety issue is a really difficult problem. I think replacing struct page with pfn_t in a bunch of places is probably going to be a requirement for my work. However, this is going to be a very large undertaking. I've done an audit of sg_page users and there will indeed be some difficult cases. However, I'm going to start doing some cleanup and semantic changes to hopefully move in that direction. The first step I've chosen to look at is to create an sg_kmap interface which replaces about 77 (out of ~340) sg_page users. I'm hoping the new interface can have the semantic that sg_kmap can fail (which would happen in the case that no suitable page exists). Eventually, I'd want to get to a place where sg_page either doesn't exists or can fail and is always checked. At that point swapping out pfn_t in the sgl would be manageable. Thoughts? Logan _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 From: Logan Gunthorpe Subject: Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory. Date: Fri, 7 Apr 2017 11:59:20 -0600 Message-ID: <6206d74b-b2e2-f1f7-5a9d-60f20d837374@deltatee.com> References: <1490911959-5146-1-git-send-email-logang@deltatee.com> <1490911959-5146-6-git-send-email-logang@deltatee.com> <20170331070950.GA9059@infradead.org> <435d4471-436b-87e6-8827-c9fc6cbdde2c@deltatee.com> <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> <22930db3-a194-8b60-5aab-4a8add1ddc55@deltatee.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: Dan Williams Cc: Jens Axboe , Keith Busch , "James E.J. Bottomley" , linux-scsi , "Martin K. Petersen" , "linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org" , linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Steve Wise , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Christoph Hellwig , Max Gurtovoy , Christoph Hellwig , Jason Gunthorpe List-Id: linux-rdma@vger.kernel.org Hi Dan, On 03/04/17 06:07 PM, Dan Williams wrote: > The completely agnostic part is where I get worried, but I shouldn't > say anymore until I actually read the patch.The worry is cases where > this agnostic enabling allows unsuspecting code paths to do the wrong > thing. Like bypass iomem safety. Yup, you're right the iomem safety issue is a really difficult problem. I think replacing struct page with pfn_t in a bunch of places is probably going to be a requirement for my work. However, this is going to be a very large undertaking. I've done an audit of sg_page users and there will indeed be some difficult cases. However, I'm going to start doing some cleanup and semantic changes to hopefully move in that direction. The first step I've chosen to look at is to create an sg_kmap interface which replaces about 77 (out of ~340) sg_page users. I'm hoping the new interface can have the semantic that sg_kmap can fail (which would happen in the case that no suitable page exists). Eventually, I'd want to get to a place where sg_page either doesn't exists or can fail and is always checked. At that point swapping out pfn_t in the sgl would be manageable. Thoughts? Logan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934655AbdDGR7r (ORCPT ); Fri, 7 Apr 2017 13:59:47 -0400 Received: from ale.deltatee.com ([207.54.116.67]:44363 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932127AbdDGR7i (ORCPT ); Fri, 7 Apr 2017 13:59:38 -0400 To: Dan Williams References: <1490911959-5146-1-git-send-email-logang@deltatee.com> <1490911959-5146-6-git-send-email-logang@deltatee.com> <20170331070950.GA9059@infradead.org> <435d4471-436b-87e6-8827-c9fc6cbdde2c@deltatee.com> <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> <22930db3-a194-8b60-5aab-4a8add1ddc55@deltatee.com> Cc: Christoph Hellwig , Jens Axboe , Keith Busch , "James E.J. Bottomley" , linux-scsi , "Martin K. Petersen" , "linux-nvdimm@lists.01.org" , linux-rdma@vger.kernel.org, linux-pci@vger.kernel.org, Steve Wise , "linux-kernel@vger.kernel.org" , linux-nvme@lists.infradead.org, Jason Gunthorpe , Max Gurtovoy , Christoph Hellwig From: Logan Gunthorpe Message-ID: <6206d74b-b2e2-f1f7-5a9d-60f20d837374@deltatee.com> Date: Fri, 7 Apr 2017 11:59:20 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.111 X-SA-Exim-Rcpt-To: hch@lst.de, maxg@mellanox.com, jgunthorpe@obsidianresearch.com, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, swise@opengridcomputing.com, linux-pci@vger.kernel.org, linux-rdma@vger.kernel.org, linux-nvdimm@lists.01.org, martin.petersen@oracle.com, linux-scsi@vger.kernel.org, jejb@linux.vnet.ibm.com, keith.busch@intel.com, axboe@kernel.dk, hch@infradead.org, dan.j.williams@intel.com X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory. X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Dan, On 03/04/17 06:07 PM, Dan Williams wrote: > The completely agnostic part is where I get worried, but I shouldn't > say anymore until I actually read the patch.The worry is cases where > this agnostic enabling allows unsuspecting code paths to do the wrong > thing. Like bypass iomem safety. Yup, you're right the iomem safety issue is a really difficult problem. I think replacing struct page with pfn_t in a bunch of places is probably going to be a requirement for my work. However, this is going to be a very large undertaking. I've done an audit of sg_page users and there will indeed be some difficult cases. However, I'm going to start doing some cleanup and semantic changes to hopefully move in that direction. The first step I've chosen to look at is to create an sg_kmap interface which replaces about 77 (out of ~340) sg_page users. I'm hoping the new interface can have the semantic that sg_kmap can fail (which would happen in the case that no suitable page exists). Eventually, I'd want to get to a place where sg_page either doesn't exists or can fail and is always checked. At that point swapping out pfn_t in the sgl would be manageable. Thoughts? Logan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ale.deltatee.com ([207.54.116.67]:44363 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932127AbdDGR7i (ORCPT ); Fri, 7 Apr 2017 13:59:38 -0400 To: Dan Williams References: <1490911959-5146-1-git-send-email-logang@deltatee.com> <1490911959-5146-6-git-send-email-logang@deltatee.com> <20170331070950.GA9059@infradead.org> <435d4471-436b-87e6-8827-c9fc6cbdde2c@deltatee.com> <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> <22930db3-a194-8b60-5aab-4a8add1ddc55@deltatee.com> Cc: Christoph Hellwig , Jens Axboe , Keith Busch , "James E.J. Bottomley" , linux-scsi , "Martin K. Petersen" , "linux-nvdimm@lists.01.org" , linux-rdma@vger.kernel.org, linux-pci@vger.kernel.org, Steve Wise , "linux-kernel@vger.kernel.org" , linux-nvme@lists.infradead.org, Jason Gunthorpe , Max Gurtovoy , Christoph Hellwig From: Logan Gunthorpe Message-ID: <6206d74b-b2e2-f1f7-5a9d-60f20d837374@deltatee.com> Date: Fri, 7 Apr 2017 11:59:20 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Subject: Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory. Sender: linux-pci-owner@vger.kernel.org List-ID: Hi Dan, On 03/04/17 06:07 PM, Dan Williams wrote: > The completely agnostic part is where I get worried, but I shouldn't > say anymore until I actually read the patch.The worry is cases where > this agnostic enabling allows unsuspecting code paths to do the wrong > thing. Like bypass iomem safety. Yup, you're right the iomem safety issue is a really difficult problem. I think replacing struct page with pfn_t in a bunch of places is probably going to be a requirement for my work. However, this is going to be a very large undertaking. I've done an audit of sg_page users and there will indeed be some difficult cases. However, I'm going to start doing some cleanup and semantic changes to hopefully move in that direction. The first step I've chosen to look at is to create an sg_kmap interface which replaces about 77 (out of ~340) sg_page users. I'm hoping the new interface can have the semantic that sg_kmap can fail (which would happen in the case that no suitable page exists). Eventually, I'd want to get to a place where sg_page either doesn't exists or can fail and is always checked. At that point swapping out pfn_t in the sgl would be manageable. Thoughts? Logan From mboxrd@z Thu Jan 1 00:00:00 1970 From: logang@deltatee.com (Logan Gunthorpe) Date: Fri, 7 Apr 2017 11:59:20 -0600 Subject: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory. In-Reply-To: References: <1490911959-5146-1-git-send-email-logang@deltatee.com> <1490911959-5146-6-git-send-email-logang@deltatee.com> <20170331070950.GA9059@infradead.org> <435d4471-436b-87e6-8827-c9fc6cbdde2c@deltatee.com> <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> <22930db3-a194-8b60-5aab-4a8add1ddc55@deltatee.com> Message-ID: <6206d74b-b2e2-f1f7-5a9d-60f20d837374@deltatee.com> Hi Dan, On 03/04/17 06:07 PM, Dan Williams wrote: > The completely agnostic part is where I get worried, but I shouldn't > say anymore until I actually read the patch.The worry is cases where > this agnostic enabling allows unsuspecting code paths to do the wrong > thing. Like bypass iomem safety. Yup, you're right the iomem safety issue is a really difficult problem. I think replacing struct page with pfn_t in a bunch of places is probably going to be a requirement for my work. However, this is going to be a very large undertaking. I've done an audit of sg_page users and there will indeed be some difficult cases. However, I'm going to start doing some cleanup and semantic changes to hopefully move in that direction. The first step I've chosen to look at is to create an sg_kmap interface which replaces about 77 (out of ~340) sg_page users. I'm hoping the new interface can have the semantic that sg_kmap can fail (which would happen in the case that no suitable page exists). Eventually, I'd want to get to a place where sg_page either doesn't exists or can fail and is always checked. At that point swapping out pfn_t in the sgl would be manageable. Thoughts? Logan