On 27 May 2014 19:45, Dave Hansen wrote:
>
> I don't think this is quite right. pfn_valid() tells us whether we have
> a 'struct page' there or not. *BUT*, it does not tell us whether it is
> RAM that we can actually address and than can be freed in to the buddy
> allocator.
>
> I think
On 27 May 2014 19:45, Dave Hansen dave.han...@intel.com wrote:
I don't think this is quite right. pfn_valid() tells us whether we have
a 'struct page' there or not. *BUT*, it does not tell us whether it is
RAM that we can actually address and than can be freed in to the buddy
allocator.
I
On 05/27/2014 07:10 AM, Matt Fleming wrote:
> We need to check that a pfn is valid before handing it to pfn_to_page()
> since on low memory systems with CONFIG_HIGHMEM=n it's possible that a
> pfn may not have a corresponding struct page.
>
> This is in fact the case for one of Alan's machines
We need to check that a pfn is valid before handing it to pfn_to_page()
since on low memory systems with CONFIG_HIGHMEM=n it's possible that a
pfn may not have a corresponding struct page.
This is in fact the case for one of Alan's machines where some of the
EFI boot services pages live in
We need to check that a pfn is valid before handing it to pfn_to_page()
since on low memory systems with CONFIG_HIGHMEM=n it's possible that a
pfn may not have a corresponding struct page.
This is in fact the case for one of Alan's machines where some of the
EFI boot services pages live in
On 05/27/2014 07:10 AM, Matt Fleming wrote:
We need to check that a pfn is valid before handing it to pfn_to_page()
since on low memory systems with CONFIG_HIGHMEM=n it's possible that a
pfn may not have a corresponding struct page.
This is in fact the case for one of Alan's machines where
6 matches
Mail list logo
