From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 27 Jul 2015 07:14:13 +0200 From: Christoph Hellwig Subject: Re: [PATCH v2 25/25] pmem: convert to generic memremap Message-ID: <20150727051413.GC15836@lst.de> References: <20150725023649.8664.59145.stgit@dwillia2-desk3.amr.corp.intel.com> <20150725024020.8664.52581.stgit@dwillia2-desk3.amr.corp.intel.com> <20150726173317.GD29513@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Dan Williams Cc: Christoph Hellwig , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , linux-arch@vger.kernel.org, "Kani, Toshimitsu" , "linux-nvdimm@lists.01.org" , "linux-kernel@vger.kernel.org" , Russell King , Ross Zwisler , "linux-arm-kernel@lists.infradead.org" List-ID: On Sun, Jul 26, 2015 at 11:11:44AM -0700, Dan Williams wrote: > I don't follow. We have __iomem for the cpu mapping of a resource and > dma_map() for a PCI device. __pmem works the same and is there to > make sure someone doesn't simply de-reference a pointer to pmem and > hope that the write is persistent. But no deference of a kernel pointer is magily persistent, so I'm not really worried about that. It just means whenever we want to pass it to anything we'll need to cast. And anything that does I/O falls into that category. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753898AbbG0FOR (ORCPT ); Mon, 27 Jul 2015 01:14:17 -0400 Received: from verein.lst.de ([213.95.11.211]:35853 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750955AbbG0FOP (ORCPT ); Mon, 27 Jul 2015 01:14:15 -0400 Date: Mon, 27 Jul 2015 07:14:13 +0200 From: Christoph Hellwig To: Dan Williams Cc: Christoph Hellwig , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , linux-arch@vger.kernel.org, "Kani, Toshimitsu" , "linux-nvdimm@lists.01.org" , "linux-kernel@vger.kernel.org" , Russell King , Ross Zwisler , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v2 25/25] pmem: convert to generic memremap Message-ID: <20150727051413.GC15836@lst.de> References: <20150725023649.8664.59145.stgit@dwillia2-desk3.amr.corp.intel.com> <20150725024020.8664.52581.stgit@dwillia2-desk3.amr.corp.intel.com> <20150726173317.GD29513@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jul 26, 2015 at 11:11:44AM -0700, Dan Williams wrote: > I don't follow. We have __iomem for the cpu mapping of a resource and > dma_map() for a PCI device. __pmem works the same and is there to > make sure someone doesn't simply de-reference a pointer to pmem and > hope that the write is persistent. But no deference of a kernel pointer is magily persistent, so I'm not really worried about that. It just means whenever we want to pass it to anything we'll need to cast. And anything that does I/O falls into that category. From mboxrd@z Thu Jan 1 00:00:00 1970 From: hch@lst.de (Christoph Hellwig) Date: Mon, 27 Jul 2015 07:14:13 +0200 Subject: [PATCH v2 25/25] pmem: convert to generic memremap In-Reply-To: References: <20150725023649.8664.59145.stgit@dwillia2-desk3.amr.corp.intel.com> <20150725024020.8664.52581.stgit@dwillia2-desk3.amr.corp.intel.com> <20150726173317.GD29513@lst.de> Message-ID: <20150727051413.GC15836@lst.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Sun, Jul 26, 2015 at 11:11:44AM -0700, Dan Williams wrote: > I don't follow. We have __iomem for the cpu mapping of a resource and > dma_map() for a PCI device. __pmem works the same and is there to > make sure someone doesn't simply de-reference a pointer to pmem and > hope that the write is persistent. But no deference of a kernel pointer is magily persistent, so I'm not really worried about that. It just means whenever we want to pass it to anything we'll need to cast. And anything that does I/O falls into that category.