Re: [PATCH 1/2] pstore-ram: Fix hangs by using write-combine mappings

2014-12-10 Thread Kees Cook
On Fri, Sep 12, 2014 at 11:32 AM, Tony Lindgren t...@atomide.com wrote:
 From: Rob Herring robherri...@gmail.com

 Currently trying to use pstore on at least ARMs can hang as we're
 mapping the peristent RAM with pgprot_noncached().

 On ARMs, pgprot_noncached() will actually make the memory strongly
 ordered, and as the atomic operations pstore uses are implementation
 defined for strongly ordered memory, they may not work. So basically
 atomic operations have undefined behavior on ARM for device or strongly
 ordered memory types.

 Let's fix the issue by using write-combine variants for mappings. This
 corresponds to normal, non-cacheable memory on ARM. For many other
 architectures, this change does not change the mapping type as by
 default we have:

 #define pgprot_writecombine pgprot_noncached

 The reason why pgprot_noncached() was originaly used for pstore
 is because Colin Cross ccr...@android.com had observed lost
 debug prints right before a device hanging write operation on some
 systems. For the platforms supporting pgprot_noncached(), we can
 add a an optional configuration option to support that. But let's
 get pstore working first before adding new features.

 Cc: Arnd Bergmann a...@arndb.de
 Cc: Anton Vorontsov cbouatmai...@gmail.com
 Cc: Colin Cross ccr...@android.com
 Cc: Kees Cook keesc...@chromium.org
 Cc: Olof Johansson o...@lixom.net
 Cc: Tony Luck tony.l...@intel.com
 Cc: linux-ker...@vger.kernel.org
 Signed-off-by: Rob Herring rob.herr...@calxeda.com
 [t...@atomide.com: updated description]
 Signed-off-by: Tony Lindgren t...@atomide.com

Acked-by: Kees Cook keesc...@chromium.org

Please Cc: sta...@vger.kernel.org on this one too.

Thanks!

-Kees

 ---
  fs/pstore/ram_core.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
 index 9d7b9a8..24f94b0 100644
 --- a/fs/pstore/ram_core.c
 +++ b/fs/pstore/ram_core.c
 @@ -392,7 +392,7 @@ static void *persistent_ram_vmap(phys_addr_t start, 
 size_t size)
 page_start = start - offset_in_page(start);
 page_count = DIV_ROUND_UP(size + offset_in_page(start), PAGE_SIZE);

 -   prot = pgprot_noncached(PAGE_KERNEL);
 +   prot = pgprot_writecombine(PAGE_KERNEL);

 pages = kmalloc_array(page_count, sizeof(struct page *), GFP_KERNEL);
 if (!pages) {
 @@ -422,7 +422,7 @@ static void *persistent_ram_iomap(phys_addr_t start, 
 size_t size)
 buffer_start_add = buffer_start_add_locked;
 buffer_size_add = buffer_size_add_locked;

 -   return ioremap(start, size);
 +   return ioremap_wc(start, size);
  }

  static int persistent_ram_buffer_map(phys_addr_t start, phys_addr_t size,
 --
 2.1.0




-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/2] pstore-ram: Fix hangs by using write-combine mappings

2014-09-12 Thread Tony Lindgren
From: Rob Herring robherri...@gmail.com

Currently trying to use pstore on at least ARMs can hang as we're
mapping the peristent RAM with pgprot_noncached().

On ARMs, pgprot_noncached() will actually make the memory strongly
ordered, and as the atomic operations pstore uses are implementation
defined for strongly ordered memory, they may not work. So basically
atomic operations have undefined behavior on ARM for device or strongly
ordered memory types.

Let's fix the issue by using write-combine variants for mappings. This
corresponds to normal, non-cacheable memory on ARM. For many other
architectures, this change does not change the mapping type as by
default we have:

#define pgprot_writecombine pgprot_noncached

The reason why pgprot_noncached() was originaly used for pstore
is because Colin Cross ccr...@android.com had observed lost
debug prints right before a device hanging write operation on some
systems. For the platforms supporting pgprot_noncached(), we can
add a an optional configuration option to support that. But let's
get pstore working first before adding new features.

Cc: Arnd Bergmann a...@arndb.de
Cc: Anton Vorontsov cbouatmai...@gmail.com
Cc: Colin Cross ccr...@android.com
Cc: Kees Cook keesc...@chromium.org
Cc: Olof Johansson o...@lixom.net
Cc: Tony Luck tony.l...@intel.com
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Rob Herring rob.herr...@calxeda.com
[t...@atomide.com: updated description]
Signed-off-by: Tony Lindgren t...@atomide.com
---
 fs/pstore/ram_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 9d7b9a8..24f94b0 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -392,7 +392,7 @@ static void *persistent_ram_vmap(phys_addr_t start, size_t 
size)
page_start = start - offset_in_page(start);
page_count = DIV_ROUND_UP(size + offset_in_page(start), PAGE_SIZE);
 
-   prot = pgprot_noncached(PAGE_KERNEL);
+   prot = pgprot_writecombine(PAGE_KERNEL);
 
pages = kmalloc_array(page_count, sizeof(struct page *), GFP_KERNEL);
if (!pages) {
@@ -422,7 +422,7 @@ static void *persistent_ram_iomap(phys_addr_t start, size_t 
size)
buffer_start_add = buffer_start_add_locked;
buffer_size_add = buffer_size_add_locked;
 
-   return ioremap(start, size);
+   return ioremap_wc(start, size);
 }
 
 static int persistent_ram_buffer_map(phys_addr_t start, phys_addr_t size,
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html