From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753001AbbFAOcG (ORCPT ); Mon, 1 Jun 2015 10:32:06 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:54204 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751479AbbFAOb6 (ORCPT ); Mon, 1 Jun 2015 10:31:58 -0400 From: Arnd Bergmann To: Dan Williams Cc: Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Thomas Gleixner , Ross Zwisler , Andrew Morton , Juergen Gross , X86 ML , "Kani, Toshimitsu" , "linux-nvdimm@lists.01.org" , Luis Rodriguez , Konrad Rzeszutek Wilk , "linux-kernel@vger.kernel.org" , Stefan Bader , Andy Lutomirski , linux-mm@kvack.org, geert@linux-m68k.org, Henrique de Moraes Holschuh , Tejun Heo , Christoph Hellwig Subject: Re: [PATCH v2 3/4] arch: introduce memremap() Date: Mon, 01 Jun 2015 16:29:55 +0200 Message-ID: <2979323.pqVEGrEfg7@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <20150530185425.32590.3190.stgit@dwillia2-desk3.amr.corp.intel.com> <201505302300.10950.arnd@arndb.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:5MlHoWoH6AI5qXhzwV9WvnXYwKSfH5LrhirxsTPKmbbR/J1jIJV YkwQFeNQ5ypqLVCTQVPdYUBujTrL5kpmoah4GyMnI1eS9Z17TS8UzHXTTTELYLuGic8REj+ LkR6750hIuucxVXfS/EEEBfLebmMAjOrFDuIlhqT/XvQuTFw0kXzCqROBJQFhVIS3G3HwF9 3/5Wd6gtJ1F97DM5nUhMA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Z8vKPojb0iw=:HU4DGxHb9yTluv7eyt32jZ ZoxoLZ9WIvDsZ78ok93P2lykQ7w+ehSmu/q5CSaiLnqlPk42eZDS2KY3Z9Hxu3sKw/kQ6WBhw GnQCFHOEVZAUcynQ+gAPP7XNCHn59/f+a4/8DK5/HF2mpxQO9kbkZ4USUGowXw3ZR3LXfs0ct bjo4SxDiVLOZ0WjNaluui8D4yYtKiaQ0TKOoY4RHbIK0C8HxYbmZVALhkDIhy66Vhf3v4hM35 fLlBMWdX7jUOSsamcLAAVQsyoHnAl0j5oqBU23yNTeeHBYfmYGzlV/J0KyWr9YL7MF69fq7gP b9MA2S0CiVGsFglpf/mqV3HQIsdQj6kErE1Q5J2D0CUQF3XHYHadtOfnRbZyx6JHes7geoEIt l9r33yXkAcv5iODUfgPOCIROyZuSEUGyNI3c6HIQHJC/1v/VUiclHsW4VVgHBTvY8CKrHqYQy md0zGCLyHqMYsMlT3OPRWmrBH0IuruOIOztYPwk0Md/DXZpCuKiTQNTVl5GxmeFJmd46leMU8 4qGrZZ6qj+lOUdOH9we9hZLYj2PJMow3V9mPE3pOLzo3fqhT9qQ4Wg/ZlGFT0YDX+7E6nEbqe ytRiNgMIB8yMPAviYoJD1mN5IHpcFKlYgQZ/+2JPvq4Kw9ccyhbLFfArJ+X2CRPKCUG1YU+HL U98pQ/muV7EgKl+jtW15nVbjlpNiKBkyPpDGciGReDIRBjA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Saturday 30 May 2015 14:39:48 Dan Williams wrote: > On Sat, May 30, 2015 at 2:00 PM, Arnd Bergmann wrote: > > On Saturday 30 May 2015, Dan Williams wrote: > >> > >> +/* > >> + * memremap() is "ioremap" for cases where it is known that the resource > >> + * being mapped does not have i/o side effects and the __iomem > >> + * annotation is not applicable. > >> + */ > >> + > >> +static inline void *memremap(resource_size_t offset, size_t size) > >> +{ > >> + return (void __force *) ioremap(offset, size); > >> +} > >> + > >> +static inline void *memremap_nocache(resource_size_t offset, size_t size) > >> +{ > >> + return (void __force *) ioremap_nocache(offset, size); > >> +} > >> + > >> +static inline void *memremap_cache(resource_size_t offset, size_t size) > >> +{ > >> + return (void __force *) ioremap_cache(offset, size); > >> +} > >> + > > > > There are architectures on which the result of ioremap is not necessarily > > a pointer, but instead indicates that the access is to be done through > > some other indirect access, or require special instructions. I think implementing > > the memremap() interfaces is generally helpful, but don't rely on the > > ioremap implementation. > > Is it enough to detect the archs where ioremap() does return an > otherwise usable pointer and set ARCH_HAS_MEMREMAP, in the first take > of this introduction? Regardless, it seems that drivers should have > Kconfig dependency checks for archs where ioremap can not be used in > this manner. Yes, that should work. > > Adding both cached an uncached versions is also dangerous, because you > > typically get either undefined behavior or a system checkstop when a > > single page is mapped both cached and uncached at the same time. This > > means that doing memremap() or memremap_nocache() on something that > > may be part of the linear kernel mapping is a bug, and we should probably > > check for that here. > > Part of the reason for relying on ioremap() was to borrow its internal > checks to fail attempts that try to remap ranges that are already in > the kernel linear map. Hmm, that's a guarantee x86 ioremap gives, but > maybe that's not universal? I haven't seen that check elsewhere. IIRC what ioremap() guarantees on ARM is that if there is an existing boot-time mapping (similar to x86 fixmap, but more commonly used), we use the same flags in the new ioremap and override the ones that are provided by the caller. Arnd