Re: [PATCH v2 1/5] x86/mm/pageattr: Ensure cpa->pfn only contains page frame numbers

[Ingo Molnar]

* Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> wrote:

> > > +	npages = (_end - _text) >> PAGE_SHIFT;
> > 
> > You really need to PFN_ALIGN _end and _text. Has been wrong in the
> > existing code as well.
>  
> Hmm... very good point.

So I think we should instead guarantee that _end and _text are page aligned.

_text is already page aligned:

SECTIONS
{
#ifdef CONFIG_X86_32
        . = LOAD_OFFSET + LOAD_PHYSICAL_ADDR;
        phys_startup_32 = startup_32 - LOAD_OFFSET;
#else
        . = __START_KERNEL;
        phys_startup_64 = startup_64 - LOAD_OFFSET;
#endif

        /* Text and read-only data */
        .text :  AT(ADDR(.text) - LOAD_OFFSET) {
                _text = .;

The reason for aligning _end as well is that we already page-align the BSS and BRK 
sections of the kernel and its various section boundary symbols:

        /* BSS */
        . = ALIGN(PAGE_SIZE);
        .bss : AT(ADDR(.bss) - LOAD_OFFSET) {
                __bss_start = .;
                *(.bss..page_aligned)
                *(.bss)
                . = ALIGN(PAGE_SIZE);
                __bss_stop = .;
        }

        . = ALIGN(PAGE_SIZE);
        .brk : AT(ADDR(.brk) - LOAD_OFFSET) {
                __brk_base = .;
                . += 64 * 1024;         /* 64k alignment slop space */
                *(.brk_reservation)     /* areas brk users have reserved */
                __brk_limit = .;
        }

        _end = .;

        STABS_DEBUG
        DWARF_DEBUG

_end is the only odd one out, so we should align it as well - because it's easy to 
make such pfn conversion bugs.

This will also make it easier to mark STABS_DEBUG and DWARF_DEBUG as read-only, 
which they should fundamentally be I think. Alternatively they could be moved to 
the read-only section - at which point _end becomes page aligned 'for free'.

Thanks,

	Ingo
--
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/