Re: [PATCH -mm 4/7] mm: make page colouring code generic

From: Rik van Riel
Date: Thu Jun 21 2012 - 09:25:49 EST


On 06/21/2012 08:37 AM, Borislav Petkov wrote:

-unsigned long align_addr(unsigned long addr, struct file *filp,
- enum align_flags flags)
+unsigned long arch_align_addr(unsigned long addr, struct file *filp,
+ unsigned long pgoff, unsigned long flags,
+ enum mmap_allocation_direction direction)

Arguments vertical alignment too, not only addr alignment :-)

Will do.

{
- unsigned long tmp_addr;
+ unsigned long tmp_addr = PAGE_ALIGN(addr);

I'm guessing addr coming from arch_get_unmapped_area(_topdown) might not
be page-aligned in all cases?

That is my guess, too :)

In some places arch_get_unmapped_area(_topdown) called
PAGE_ALIGN(addr), so we should make sure it is called.

It is probably masking bugs in some old old application,
and calling it here really should not hurt.

- if (!(current->flags& PF_RANDOMIZE))
- return addr;
+ /* Always allow MAP_FIXED. Colouring is a performance thing only. */
+ if (flags& MAP_FIXED)
+ return tmp_addr;

Why here? Maybe we should push this MAP_FIXED check up in the
arch_get_unmapped_area(_topdown) and not call arch_align_addr() for
MAP_FIXED requests?

Or do you want to save some code duplication?

The problem is that certain other architectures have
data cache alignment requirements, where mis-aligning
somebody's mmap of a file could result in actual data
corruption.

This means that, for those architectures, we have to
refuse non-colour-aligned MAP_FIXED mappings.

On x86 we can allow them, so we do. But that decision
needs to be taken in architecture specific code, not
in the shared arch_get_unmapped_area(_topdown) :)

+ /*
+ * When aligning down, make sure we did not accidentally go up.
+ * The caller will check for underflow.
+ */

Can we add this comment to the x86-64 version of arch_align_addr too pls?

Will do.

--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/