Re: Question regarding x86_64 __PHYSICAL_MASK_SHIFT

From: Tejun Heo
Date: Tue Oct 04 2005 - 23:02:36 EST



Hello, Andi.

Andi Kleen wrote:
On Tuesday 04 October 2005 21:19, Tejun Heo wrote:


Hmmm.. but, currently

* PHYSICAL_PAGE_MASK == (~(PAGE_SIZE-1)&(__PHYSICAL_MASK << PAGE_SHIFT)
== (0xffffffff_fffff000 & (0x00003fff_ffffffff << 12)
== 0x03ffffff_fffff000
while it actually should be 0x00003fff_fffff000


Right. Fixed now


* PTE_FILE_MAX_BITS == __PHYSICAL_MASK_SHIFT == 46, but only 40bits are
available in page table entries.


The non linear mapping format is independent from the MMU, the number
is pretty much arbitary, but it is consistent to make it the same as
other ptes for easier sanity checking.

Okay, please forgive me if I'm bugging you with something stupid but I still don't quite get it. When using NONLINEAR mapping, pgoff is stored to pte to use later when faulting in the page. Storing and reading pgoff are done with the following macros.

#define pte_to_pgoff(pte) \
((pte_val(pte) & PHYSICAL_PAGE_MASK) >> PAGE_SHIFT)
#define pgoff_to_pte(off) \
((pte_t) { ((off) << PAGE_SHIFT) | _PAGE_FILE })

In pte_to_pgoff we're masking pte value with PHYSICAL_PAGE_MASK which gives us 34bits with patches applied. This means that if a pgoff goes through pgoff_to_pte and then pte_to_pgoff only 34bits survive.

sys_remap_file_pages() checks if required pgoff's fit in pte's using PTE_FILE_MAX_BITS.

#define PTE_FILE_MAX_BITS __PHYSICAL_MASK_SHIFT

Which is 46 with patches applied. Meaning that we could end up shoving up value larger than 34bits into pte and losing information when reading back (and it's only 16GB!).

So, IMHO, we should either shrink PTE_FILE_MAX_BITS to 36 or change pte_to_pgoff/pgoff_to_pte macros to carry more bits (as pte bits 52-62 are available, we can shove 46bits easily).

No?

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