In the undo path of start_isolate_page_range(), we need to check
the pfn validity before access its page, or it will trigger an
addressing exception if there is hole in the zone.
Signed-off-by: Weijie Yang <[email protected]>
---
mm/page_isolation.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index d1473b2..3ddc8b3 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -137,8 +137,11 @@ int start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
undo:
for (pfn = start_pfn;
pfn < undo_pfn;
- pfn += pageblock_nr_pages)
- unset_migratetype_isolate(pfn_to_page(pfn), migratetype);
+ pfn += pageblock_nr_pages) {
+ page = __first_valid_page(pfn, pageblock_nr_pages);
+ if (page)
+ unset_migratetype_isolate(page, migratetype);
+ }
return -EBUSY;
}
--
1.7.0.4
On Thu, Nov 06 2014, Weijie Yang <[email protected]> wrote:
> In the undo path of start_isolate_page_range(), we need to check
> the pfn validity before access its page, or it will trigger an
> addressing exception if there is hole in the zone.
>
> Signed-off-by: Weijie Yang <[email protected]>
Acked-by: Michal Nazarewicz <[email protected]>
> ---
> mm/page_isolation.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> index d1473b2..3ddc8b3 100644
> --- a/mm/page_isolation.c
> +++ b/mm/page_isolation.c
> @@ -137,8 +137,11 @@ int start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
> undo:
> for (pfn = start_pfn;
> pfn < undo_pfn;
> - pfn += pageblock_nr_pages)
> - unset_migratetype_isolate(pfn_to_page(pfn), migratetype);
> + pfn += pageblock_nr_pages) {
> + page = __first_valid_page(pfn, pageblock_nr_pages);
> + if (page)
> + unset_migratetype_isolate(page, migratetype);
> + }
>
> return -EBUSY;
> }
> --
> 1.7.0.4
>
>
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +--<[email protected]>--<xmpp:[email protected]>--ooO--(_)--Ooo--
On Thu, 06 Nov 2014 16:08:02 +0800 Weijie Yang <[email protected]> wrote:
> In the undo path of start_isolate_page_range(), we need to check
> the pfn validity before access its page, or it will trigger an
> addressing exception if there is hole in the zone.
>
There is not enough information in the chagnelog for me to decide how
to handle the patch. 3.19? 3.18? 3.18+stable?
When fixing bugs, please remember to fully explain the end-user impact
of the bug. Under what circumstances does it occur?
(2014/11/06 17:08), Weijie Yang wrote:
> In the undo path of start_isolate_page_range(), we need to check
> the pfn validity before access its page, or it will trigger an
> addressing exception if there is hole in the zone.
>
> Signed-off-by: Weijie Yang <[email protected]>
> ---
Looks good to me.
Reviewed-by: Yasuaki Ishimatsu <[email protected]>
Thanks,
Yasuaki Ishimatsu
> mm/page_isolation.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> index d1473b2..3ddc8b3 100644
> --- a/mm/page_isolation.c
> +++ b/mm/page_isolation.c
> @@ -137,8 +137,11 @@ int start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
> undo:
> for (pfn = start_pfn;
> pfn < undo_pfn;
> - pfn += pageblock_nr_pages)
> - unset_migratetype_isolate(pfn_to_page(pfn), migratetype);
> + pfn += pageblock_nr_pages) {
> + page = __first_valid_page(pfn, pageblock_nr_pages);
> + if (page)
> + unset_migratetype_isolate(page, migratetype);
> + }
>
> return -EBUSY;
> }
>
On Wed, Nov 12, 2014 at 6:23 AM, Andrew Morton
<[email protected]> wrote:
> On Thu, 06 Nov 2014 16:08:02 +0800 Weijie Yang <[email protected]> wrote:
>
>> In the undo path of start_isolate_page_range(), we need to check
>> the pfn validity before access its page, or it will trigger an
>> addressing exception if there is hole in the zone.
>>
>
> There is not enough information in the chagnelog for me to decide how
> to handle the patch. 3.19? 3.18? 3.18+stable?
>
> When fixing bugs, please remember to fully explain the end-user impact
> of the bug. Under what circumstances does it occur?
I'm sorry to disturb you. This issue is found by code-review not a test-trigger.
In "CONFIG_HOLES_IN_ZONE" environment, there is a certain chance that
it would casue an addressing exception when start_isolate_page_range() fails,
this could affect CMA, hugepage and memory-hotplug function.
On Thu 06-11-14 16:08:02, Weijie Yang wrote:
> In the undo path of start_isolate_page_range(), we need to check
> the pfn validity before access its page, or it will trigger an
> addressing exception if there is hole in the zone.
This looks a bit fishy to me. I am not familiar with the code much but
at least __offline_pages zone = page_zone(pfn_to_page(start_pfn)) so it
would blow up before we got here. Same applies to the other caller
alloc_contig_range. So either both need a fix and then
start_isolate_page_range doesn't need more checks or this is all
unnecessary.
Please do not make this code more obfuscated than it is already...
> Signed-off-by: Weijie Yang <[email protected]>
> ---
> mm/page_isolation.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> index d1473b2..3ddc8b3 100644
> --- a/mm/page_isolation.c
> +++ b/mm/page_isolation.c
> @@ -137,8 +137,11 @@ int start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
> undo:
> for (pfn = start_pfn;
> pfn < undo_pfn;
> - pfn += pageblock_nr_pages)
> - unset_migratetype_isolate(pfn_to_page(pfn), migratetype);
> + pfn += pageblock_nr_pages) {
> + page = __first_valid_page(pfn, pageblock_nr_pages);
> + if (page)
> + unset_migratetype_isolate(page, migratetype);
> + }
>
> return -EBUSY;
> }
> --
> 1.7.0.4
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to [email protected]. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
--
Michal Hocko
SUSE Labs
On Thu, Nov 13, 2014 at 3:34 AM, Michal Hocko <[email protected]> wrote:
> On Thu 06-11-14 16:08:02, Weijie Yang wrote:
>> In the undo path of start_isolate_page_range(), we need to check
>> the pfn validity before access its page, or it will trigger an
>> addressing exception if there is hole in the zone.
>
> This looks a bit fishy to me. I am not familiar with the code much but
> at least __offline_pages zone = page_zone(pfn_to_page(start_pfn)) so it
> would blow up before we got here. Same applies to the other caller
> alloc_contig_range. So either both need a fix and then
> start_isolate_page_range doesn't need more checks or this is all
> unnecessary.
Thanks for your suggestion.
If start_isolate_page_range()'s user can ensure there isn't hole in
the [start_pfn, end_pfn) range, we can remove the checks. But if we
cann't, I think it's better reserve these "unnecessary" code.
That's really obfuscated : (
> Please do not make this code more obfuscated than it is already...
>
>> Signed-off-by: Weijie Yang <[email protected]>
>> ---
>> mm/page_isolation.c | 7 +++++--
>> 1 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
>> index d1473b2..3ddc8b3 100644
>> --- a/mm/page_isolation.c
>> +++ b/mm/page_isolation.c
>> @@ -137,8 +137,11 @@ int start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
>> undo:
>> for (pfn = start_pfn;
>> pfn < undo_pfn;
>> - pfn += pageblock_nr_pages)
>> - unset_migratetype_isolate(pfn_to_page(pfn), migratetype);
>> + pfn += pageblock_nr_pages) {
>> + page = __first_valid_page(pfn, pageblock_nr_pages);
>> + if (page)
>> + unset_migratetype_isolate(page, migratetype);
>> + }
>>
>> return -EBUSY;
>> }
>> --
>> 1.7.0.4
>>
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to [email protected]. For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
>
> --
> Michal Hocko
> SUSE Labs
On Thu 13-11-14 09:46:34, Weijie Yang wrote:
> On Thu, Nov 13, 2014 at 3:34 AM, Michal Hocko <[email protected]> wrote:
> > On Thu 06-11-14 16:08:02, Weijie Yang wrote:
> >> In the undo path of start_isolate_page_range(), we need to check
> >> the pfn validity before access its page, or it will trigger an
> >> addressing exception if there is hole in the zone.
> >
> > This looks a bit fishy to me. I am not familiar with the code much but
> > at least __offline_pages zone = page_zone(pfn_to_page(start_pfn)) so it
> > would blow up before we got here. Same applies to the other caller
> > alloc_contig_range. So either both need a fix and then
> > start_isolate_page_range doesn't need more checks or this is all
> > unnecessary.
>
> Thanks for your suggestion.
> If start_isolate_page_range()'s user can ensure there isn't hole in
> the [start_pfn, end_pfn) range, we can remove the checks. But if we
> cann't, I think it's better reserve these "unnecessary" code.
I am not sure I understand you correctly but my point was that we do not
need check at start_isolate_page_range level but rather than in the
caller (or do not rely on pfn_to_page at that level).
> That's really obfuscated : (
>
> > Please do not make this code more obfuscated than it is already...
> >
> >> Signed-off-by: Weijie Yang <[email protected]>
> >> ---
> >> mm/page_isolation.c | 7 +++++--
> >> 1 files changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> >> index d1473b2..3ddc8b3 100644
> >> --- a/mm/page_isolation.c
> >> +++ b/mm/page_isolation.c
> >> @@ -137,8 +137,11 @@ int start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
> >> undo:
> >> for (pfn = start_pfn;
> >> pfn < undo_pfn;
> >> - pfn += pageblock_nr_pages)
> >> - unset_migratetype_isolate(pfn_to_page(pfn), migratetype);
> >> + pfn += pageblock_nr_pages) {
> >> + page = __first_valid_page(pfn, pageblock_nr_pages);
> >> + if (page)
> >> + unset_migratetype_isolate(page, migratetype);
> >> + }
> >>
> >> return -EBUSY;
> >> }
> >> --
> >> 1.7.0.4
> >>
> >>
> >> --
> >> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> >> the body to [email protected]. For more info on Linux MM,
> >> see: http://www.linux-mm.org/ .
> >> Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
> >
> > --
> > Michal Hocko
> > SUSE Labs
--
Michal Hocko
SUSE Labs