All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan.kim@gmail.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux@arm.linux.org.uk, Yinghai Lu <yinghai@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Shaohua Li <shaohua.li@intel.com>,
	Yakui Zhao <yakui.zhao@intel.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	arm-kernel@lists.infradead.org, kgene.kim@samsung.com,
	Mel Gorman <mel@csn.ul.ie>
Subject: Re: [RFC] Tight check of pfn_valid on sparsemem
Date: Tue, 13 Jul 2010 17:06:56 +0900	[thread overview]
Message-ID: <AANLkTinxTojeckJpfLh9eMM4odK61-VzE2A0G9E3nRuQ@mail.gmail.com> (raw)
In-Reply-To: <20100713154025.7c60c76b.kamezawa.hiroyu@jp.fujitsu.com>

On Tue, Jul 13, 2010 at 3:40 PM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Tue, 13 Jul 2010 15:04:00 +0900
> Minchan Kim <minchan.kim@gmail.com> wrote:
>
>> >> >  2. This can't be help for a case where a section has multiple small holes.
>> >>
>> >> I agree. But this(not punched hole but not filled section problem)
>> >> isn't such case. But it would be better to handle it altogether. :)
>> >>
>> >> >
>> >> > Then, my proposal for HOLES_IN_MEMMAP sparsemem is below.
>> >> > ==
>> >> > Some architectures unmap memmap[] for memory holes even with SPARSEMEM.
>> >> > To handle that, pfn_valid() should check there are really memmap or not.
>> >> > For that purpose, __get_user() can be used.
>> >>
>> >> Look at free_unused_memmap. We don't unmap pte of hole memmap.
>> >> Is __get_use effective, still?
>> >>
>> > __get_user() works with TLB and page table, the vaddr is really mapped or not.
>> > If you got SEGV, __get_user() returns -EFAULT. It works per page granule.
>>
>> I mean following as.
>> For example, there is a struct page in on 0x20000000.
>>
>> int pfn_valid_mapped(unsigned long pfn)
>> {
>>        struct page *page = pfn_to_page(pfn); /* hole page is 0x2000000 */
>>        char *lastbyte = (char *)(page+1)-1;  /* lastbyte is 0x2000001f */
>>        char byte;
>>
>>        /* We pass this test since free_unused_memmap doesn't unmap pte */
>>        if(__get_user(byte, page) != 0)
>>                return 0;
>
> why ? When the page size is 4096 byte.
>
>      0x1ffff000 - 0x1ffffffff
>      0x20000000 - 0x200000fff are on the same page. And memory is mapped per page.

sizeof(struct page) is 32 byte.
So lastbyte is address of struct page + 32 byte - 1.

> What we access by above __get_user() is a byte at [0x20000000, 0x20000001)

Right.

> and it's unmapped if 0x20000000 is unmapped.

free_unused_memmap doesn't unmap pte although it returns the page to
free list of buddy.

>
> Thanks,
> -Kame
>
>



-- 
Kind regards,
Minchan Kim

WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan.kim@gmail.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux@arm.linux.org.uk, Yinghai Lu <yinghai@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Shaohua Li <shaohua.li@intel.com>,
	Yakui Zhao <yakui.zhao@intel.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	arm-kernel@lists.infradead.org, kgene.kim@samsung.com,
	Mel Gorman <mel@csn.ul.ie>
Subject: Re: [RFC] Tight check of pfn_valid on sparsemem
Date: Tue, 13 Jul 2010 17:06:56 +0900	[thread overview]
Message-ID: <AANLkTinxTojeckJpfLh9eMM4odK61-VzE2A0G9E3nRuQ@mail.gmail.com> (raw)
In-Reply-To: <20100713154025.7c60c76b.kamezawa.hiroyu@jp.fujitsu.com>

On Tue, Jul 13, 2010 at 3:40 PM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Tue, 13 Jul 2010 15:04:00 +0900
> Minchan Kim <minchan.kim@gmail.com> wrote:
>
>> >> >  2. This can't be help for a case where a section has multiple small holes.
>> >>
>> >> I agree. But this(not punched hole but not filled section problem)
>> >> isn't such case. But it would be better to handle it altogether. :)
>> >>
>> >> >
>> >> > Then, my proposal for HOLES_IN_MEMMAP sparsemem is below.
>> >> > ==
>> >> > Some architectures unmap memmap[] for memory holes even with SPARSEMEM.
>> >> > To handle that, pfn_valid() should check there are really memmap or not.
>> >> > For that purpose, __get_user() can be used.
>> >>
>> >> Look at free_unused_memmap. We don't unmap pte of hole memmap.
>> >> Is __get_use effective, still?
>> >>
>> > __get_user() works with TLB and page table, the vaddr is really mapped or not.
>> > If you got SEGV, __get_user() returns -EFAULT. It works per page granule.
>>
>> I mean following as.
>> For example, there is a struct page in on 0x20000000.
>>
>> int pfn_valid_mapped(unsigned long pfn)
>> {
>>        struct page *page = pfn_to_page(pfn); /* hole page is 0x2000000 */
>>        char *lastbyte = (char *)(page+1)-1;  /* lastbyte is 0x2000001f */
>>        char byte;
>>
>>        /* We pass this test since free_unused_memmap doesn't unmap pte */
>>        if(__get_user(byte, page) != 0)
>>                return 0;
>
> why ? When the page size is 4096 byte.
>
>      0x1ffff000 - 0x1ffffffff
>      0x20000000 - 0x200000fff are on the same page. And memory is mapped per page.

sizeof(struct page) is 32 byte.
So lastbyte is address of struct page + 32 byte - 1.

> What we access by above __get_user() is a byte at [0x20000000, 0x20000001)

Right.

> and it's unmapped if 0x20000000 is unmapped.

free_unused_memmap doesn't unmap pte although it returns the page to
free list of buddy.

>
> Thanks,
> -Kame
>
>



-- 
Kind regards,
Minchan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-07-13  8:07 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-12 15:53 [RFC] Tight check of pfn_valid on sparsemem Minchan Kim
2010-07-12 15:53 ` Minchan Kim
2010-07-12 23:59 ` Kukjin Kim
2010-07-12 23:59   ` Kukjin Kim
2010-07-13  3:19 ` KAMEZAWA Hiroyuki
2010-07-13  3:19   ` KAMEZAWA Hiroyuki
2010-07-13  4:11   ` Minchan Kim
2010-07-13  4:11     ` Minchan Kim
2010-07-13  4:23     ` KAMEZAWA Hiroyuki
2010-07-13  4:23       ` KAMEZAWA Hiroyuki
2010-07-13  6:04       ` Minchan Kim
2010-07-13  6:04         ` Minchan Kim
2010-07-13  6:40         ` KAMEZAWA Hiroyuki
2010-07-13  6:40           ` KAMEZAWA Hiroyuki
2010-07-13  8:06           ` Minchan Kim [this message]
2010-07-13  8:06             ` Minchan Kim
2010-07-13  8:03             ` KAMEZAWA Hiroyuki
2010-07-13  8:03               ` KAMEZAWA Hiroyuki
2010-07-13  7:20         ` Russell King - ARM Linux
2010-07-13  7:20           ` Russell King - ARM Linux
2010-07-13  7:34           ` KAMEZAWA Hiroyuki
2010-07-13  7:34             ` KAMEZAWA Hiroyuki
2010-07-13  7:58             ` KAMEZAWA Hiroyuki
2010-07-13  7:58               ` KAMEZAWA Hiroyuki
2010-07-13  8:02               ` KAMEZAWA Hiroyuki
2010-07-13  8:02                 ` KAMEZAWA Hiroyuki
2010-07-13 18:39                 ` Russell King - ARM Linux
2010-07-13 18:39                   ` Russell King - ARM Linux
2010-07-13 20:46                   ` Dave Hansen
2010-07-13 20:46                     ` Dave Hansen
2010-07-13  9:30 ` Johannes Weiner
2010-07-13  9:30   ` Johannes Weiner
2010-07-13 15:43   ` Minchan Kim
2010-07-13 15:43     ` Minchan Kim
2010-07-13 16:35     ` Dave Hansen
2010-07-13 16:35       ` Dave Hansen
2010-07-13 16:44       ` Minchan Kim
2010-07-13 16:44         ` Minchan Kim
2010-07-14  0:23         ` KAMEZAWA Hiroyuki
2010-07-14  0:23           ` KAMEZAWA Hiroyuki
2010-07-14  6:44           ` Minchan Kim
2010-07-14  6:44             ` Minchan Kim
2010-07-14  7:10             ` KAMEZAWA Hiroyuki
2010-07-14  7:10               ` KAMEZAWA Hiroyuki
2010-07-14  7:35               ` Minchan Kim
2010-07-14  7:35                 ` Minchan Kim
2010-07-14  7:39                 ` KAMEZAWA Hiroyuki
2010-07-14  7:39                   ` KAMEZAWA Hiroyuki
2010-07-14  7:50           ` Kukjin Kim
2010-07-14  7:50             ` Kukjin Kim
2010-07-14  8:09             ` KAMEZAWA Hiroyuki
2010-07-14  8:09               ` KAMEZAWA Hiroyuki
2010-07-13  9:37 ` Mel Gorman
2010-07-13  9:37   ` Mel Gorman
2010-07-13  9:46   ` Russell King - ARM Linux
2010-07-13  9:46     ` Russell King - ARM Linux
2010-07-13 10:00     ` Mel Gorman
2010-07-13 10:00       ` Mel Gorman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTinxTojeckJpfLh9eMM4odK61-VzE2A0G9E3nRuQ@mail.gmail.com \
    --to=minchan.kim@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arm-kernel@lists.infradead.org \
    --cc=hpa@zytor.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kgene.kim@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mel@csn.ul.ie \
    --cc=shaohua.li@intel.com \
    --cc=yakui.zhao@intel.com \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.