From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752474AbbHMPBg (ORCPT ); Thu, 13 Aug 2015 11:01:36 -0400 Received: from mail-wi0-f182.google.com ([209.85.212.182]:34330 "EHLO mail-wi0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751517AbbHMPBe (ORCPT ); Thu, 13 Aug 2015 11:01:34 -0400 Message-ID: <55CCB14B.4030303@plexistor.com> Date: Thu, 13 Aug 2015 18:01:31 +0300 From: Boaz Harrosh User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Christoph Hellwig CC: Dan Williams , "linux-kernel@vger.kernel.org" , Jens Axboe , Rik van Riel , "linux-nvdimm@lists.01.org" , Linux MM , Mel Gorman , "torvalds@linux-foundation.org" Subject: Re: [PATCH v5 2/5] allow mapping page-less memremaped areas into KVA References: <20150813025112.36703.21333.stgit@otcpl-skl-sds-2.jf.intel.com> <20150813030109.36703.21738.stgit@otcpl-skl-sds-2.jf.intel.com> <55CC3222.5090503@plexistor.com> <55CC9A5A.1020209@plexistor.com> <20150813144132.GC17375@lst.de> In-Reply-To: <20150813144132.GC17375@lst.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/13/2015 05:41 PM, Christoph Hellwig wrote: > On Thu, Aug 13, 2015 at 04:23:38PM +0300, Boaz Harrosh wrote: >>> DAX as is is races against pmem unbind. A synchronization cost must >>> be paid somewhere to make sure the memremap() mapping is still valid. >> >> Sorry for being so slow, is what I asked. what is exactly "pmem unbind" ? >> >> Currently in my 4.1 Kernel the ioremap is done on modprobe time and >> released modprobe --remove time. the --remove can not happen with a mounted >> FS dax or not. So what is exactly "pmem unbind". And if there is a new knob >> then make it refuse with a raised refcount. > > Surprise removal of a PCIe card which is mapped to provide non-volatile > memory for example. Or memory hot swap. > Then the mapping is just there and you get garbage. Just the same as "memory hot swap" the kernel will not let you HOT-REMOVE a referenced memory. It will just refuse. If you forcefully remove a swapeble memory chip without HOT-REMOVE first what will happen? so the same here. SW wise you refuse to HOT-REMOVE. HW wise BTW the Kernel will not die only farther reads will return all 111111 and writes will go to the either. The all kmap thing was for highmem. Is not the case here. Again see my other comment at dax mmap: - you go pfn_map take a pfn - kpfn_unmap - put pfn on user mmap vma - then what happens to user access after that. Nothing not even a page_fault It will have a vm-mapping to a now none existing physical address that's it. Thanks Boaz