lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <51245FB4.6050506@gmail.com>
Date:	Wed, 20 Feb 2013 13:31:32 +0800
From:	Simon Jeons <simon.jeons@...il.com>
To:	Kyungmin Park <kmpark@...radead.org>
CC:	Marek Szyprowski <m.szyprowski@...sung.com>,
	Minchan Kim <minchan@...nel.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	mgorman@...e.de
Subject: Re: [PATCH] mm: cma: fix accounting of CMA pages placed in high memory

On 02/20/2013 10:57 AM, Kyungmin Park wrote:
> On Tue, Feb 19, 2013 at 10:27 PM, Simon Jeons <simon.jeons@...il.com> wrote:
>> On 02/05/2013 03:10 PM, Marek Szyprowski wrote:
>>> Hello,
>>>
>>> On 2/5/2013 12:34 AM, Minchan Kim wrote:
>>>> On Mon, Feb 04, 2013 at 11:27:05AM +0100, Marek Szyprowski wrote:
>>>>> The total number of low memory pages is determined as
>>>>> totalram_pages - totalhigh_pages, so without this patch all CMA
>>>>> pageblocks placed in highmem were accounted to low memory.
>>>> So what's the end user effect? With the effect, we have to decide
>>>> routing it on stable.
>>>>
>>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@...sung.com>
>>>>> ---
>>>>>   mm/page_alloc.c |    4 ++++
>>>>>   1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>>>> index f5bab0a..6415d93 100644
>>>>> --- a/mm/page_alloc.c
>>>>> +++ b/mm/page_alloc.c
>>>>> @@ -773,6 +773,10 @@ void __init init_cma_reserved_pageblock(struct
>>>>> page *page)
>>>>>       set_pageblock_migratetype(page, MIGRATE_CMA);
>>>>>       __free_pages(page, pageblock_order);
>>>>>       totalram_pages += pageblock_nr_pages;
>>>>> +#ifdef CONFIG_HIGHMEM
>>>> We don't need #ifdef/#endif.
>>>
>>> #ifdef is required to let this code compile when highmem is not enabled,
>>> becuase totalhigh_pages is defined as 0, see include/linux/highmem.h
>>>
>> Hi Marek,
>>
>> 1) Why can support CMA regions placed in highmem?
> Some vendors use reserved memory at highmem, and it's hard to modify
> to use lowmem, so just CMA can support highmem and no need to adjust
> address used at reserved memory.
>> CMA is for dma buffer, correct? Then how can old dma device access highmem?
> What's the "old dma device"? To support it, we also modify

I mean dma devices which should still use bounce buffer, then these 
devices will use bounce buffer to access CMA region in highmem or ...?

> arch/arm/mm/dma-mapping.c for handling highmem address.
>
>> 2) Why there is no totalhigh_pages variable define in the case of config
>> highmem?
> I don't know. it's just defined in case of highmem. that's reason to
> use #ifdef/endif. we don't know hisotrical reason.
>
> Thank you,
> Kyungmin Park
>>
>>>>> +    if (PageHighMem(page))
>>>>> +        totalhigh_pages += pageblock_nr_pages;
>>>>> +#endif
>>>>>   }
>>>>>   #endif
>>>>>
>>>
>>> Best regards
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majordomo@...ck.org.  For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ