All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Juergen Gross <jgross@suse.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com
Cc: Arnd Bergmann <arnd@arndb.de>,
	linux-mm@kvack.org, linux-arch@vger.kernel.org
Subject: Re: [Patch V6 12/16] mm: provide early_memremap_ro to establish read-only mapping
Date: Thu, 6 Aug 2015 15:08:33 +0200	[thread overview]
Message-ID: <55C35C51.1040005@suse.cz> (raw)
In-Reply-To: <55C35AD1.7010101@suse.com>

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@suse.cz>


> Juergen
>

WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Juergen Gross <jgross@suse.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, david.vrabel@citrix.com,
	boris.ostrovsky@oracle.com
Cc: Arnd Bergmann <arnd@arndb.de>,
	linux-mm@kvack.org, linux-arch@vger.kernel.org
Subject: Re: [Patch V6 12/16] mm: provide early_memremap_ro to establish read-only mapping
Date: Thu, 6 Aug 2015 15:08:33 +0200	[thread overview]
Message-ID: <55C35C51.1040005@suse.cz> (raw)
In-Reply-To: <55C35AD1.7010101@suse.com>

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@suse.cz>


> Juergen
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2015-08-06 13:08 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-17  4:51 [Patch V6 00/16] xen: support pv-domains larger than 512GB Juergen Gross
2015-07-17  4:51 ` [Patch V6 01/16] xen: sync with xen headers Juergen Gross
2015-07-17  4:51 ` [Patch V6 02/16] xen: save linear p2m list address in shared info structure Juergen Gross
2015-07-17  4:51 ` [Patch V6 03/16] xen: don't build mfn tree if tools don't need it Juergen Gross
2015-07-17  4:51 ` [Patch V6 04/16] xen: eliminate scalability issues from initial mapping setup Juergen Gross
2015-07-17  4:51 ` [Patch V6 05/16] xen: move static e820 map to global scope Juergen Gross
2015-07-17  4:51 ` [Patch V6 06/16] xen: split counting of extra memory pages from remapping Juergen Gross
2015-07-17  4:51 ` [Patch V6 07/16] xen: check memory area against e820 map Juergen Gross
2015-07-17  4:51 ` [Patch V6 08/16] xen: find unused contiguous memory area Juergen Gross
2015-07-17  4:51 ` [Patch V6 09/16] xen: check for kernel memory conflicting with memory layout Juergen Gross
2015-07-17  4:51 ` [Patch V6 10/16] xen: check pre-allocated page tables for conflict with memory map Juergen Gross
2015-07-17  4:51 ` [Patch V6 11/16] xen: check for initrd conflicting with e820 map Juergen Gross
2015-07-17  4:51 ` [Patch V6 12/16] mm: provide early_memremap_ro to establish read-only mapping Juergen Gross
2015-07-17  4:51   ` Juergen Gross
2015-07-21  4:49   ` Juergen Gross
2015-07-21  4:49     ` Juergen Gross
2015-07-29  9:20     ` Juergen Gross
2015-07-29  9:20       ` Juergen Gross
2015-08-05 11:16       ` Juergen Gross
2015-08-05 11:16         ` Juergen Gross
2015-08-06 12:46   ` Vlastimil Babka
2015-08-06 12:46     ` Vlastimil Babka
2015-08-06 13:02     ` Juergen Gross
2015-08-06 13:02       ` Juergen Gross
2015-08-06 13:08       ` Vlastimil Babka [this message]
2015-08-06 13:08         ` Vlastimil Babka
2015-07-17  4:51 ` [Patch V6 13/16] xen: add explicit memblock_reserve() calls for special pages Juergen Gross
2015-07-17  4:51 ` [Patch V6 14/16] xen: move p2m list if conflicting with e820 map Juergen Gross
2015-07-17  4:51 ` [Patch V6 15/16] xen: allow more than 512 GB of RAM for 64 bit pv-domains Juergen Gross
2015-07-17  4:51 ` [Patch V6 16/16] xen: remove no longer needed p2m.h Juergen Gross
2015-07-20 12:14 ` [Xen-devel] [Patch V6 00/16] xen: support pv-domains larger than 512GB David Vrabel
2015-07-20 12:14   ` David Vrabel
2015-08-06 13:59 ` David Vrabel
2015-08-06 13:59   ` David Vrabel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55C35C51.1040005@suse.cz \
    --to=vbabka@suse.cz \
    --cc=arnd@arndb.de \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=jgross@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.