[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55C35C51.1040005@suse.cz>
Date: Thu, 6 Aug 2015 15:08:33 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Juergen Gross <jgross@...e.com>, linux-kernel@...r.kernel.org,
xen-devel@...ts.xensource.com, konrad.wilk@...cle.com,
david.vrabel@...rix.com, boris.ostrovsky@...cle.com
Cc: Arnd Bergmann <arnd@...db.de>, linux-mm@...ck.org,
linux-arch@...r.kernel.org
Subject: Re: [Patch V6 12/16] mm: provide early_memremap_ro to establish
read-only mapping
On 08/06/2015 03:02 PM, Juergen Gross wrote:
> On 08/06/2015 02:46 PM, Vlastimil Babka wrote:
>> On 07/17/2015 06:51 AM, Juergen Gross wrote:
>>
>> ... and here for !CONFIG_MMU.
>>
>> So, what about CONFIG_MMU && !FIXMAP_PAGE_RO combinations? Which
>> translates to CONFIG_MMU && !PAGE_KERNEL_RO. Maybe they don't exist, but
>> then it's still awkward to see the combination in the code left
>> unimplemented.
>
> At least there are some architectures without #define PAGE_KERNEL_RO but
> testing CONFIG_MMU (arm, m68k, xtensa).
>
>> Would it be perhaps simpler to assume the same thing as in
>> drivers/base/firmware_class.c ?
>>
>> /* Some architectures don't have PAGE_KERNEL_RO */
>> #ifndef PAGE_KERNEL_RO
>> #define PAGE_KERNEL_RO PAGE_KERNEL
>> #endif
>>
>> Or would it be dangerous here to silently lose the read-only protection?
>
> The only reason to use this function instead of early_memremap() is the
> mandatory read-only mapping. My intention was to let the build fail in
> case it is being used but not implemented. An architecture requiring the
> function but having no PAGE_KERNEL_RO still can define FIXMAP_PAGE_RO.
OK, in that case
Acked-by: Vlastimil Babka <vbabka@...e.cz>
> Juergen
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists