All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: James Morse <james.morse@arm.com>
Cc: mark.rutland@arm.com, linux-mm@kvack.org, geoff@infradead.org,
	catalin.marinas@arm.com, kexec@lists.infradead.org,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	bauerman@linux.vnet.ibm.com, Dennis Chen <dennis.chen@arm.com>,
	akpm@linux-foundation.org, nd@arm.com, dyoung@redhat.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v27 1/9] memblock: add memblock_cap_memory_range()
Date: Fri, 18 Nov 2016 12:10:36 +0000	[thread overview]
Message-ID: <20161118121036.GK13470@arm.com> (raw)
In-Reply-To: <582DF05A.9050601@arm.com>

On Thu, Nov 17, 2016 at 06:00:58PM +0000, James Morse wrote:
> On 17/11/16 11:19, Will Deacon wrote:
> > It looks much better, thanks! Just one question below.
> > 
> 
> > On Thu, Nov 17, 2016 at 02:34:24PM +0900, AKASHI Takahiro wrote:
> >> diff --git a/mm/memblock.c b/mm/memblock.c
> >> index 7608bc3..fea1688 100644
> >> --- a/mm/memblock.c
> >> +++ b/mm/memblock.c
> >> @@ -1514,11 +1514,37 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
> >>  			      (phys_addr_t)ULLONG_MAX);
> >>  }
> >>  
> >> +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> >> +{
> >> +	int start_rgn, end_rgn;
> >> +	int i, ret;
> >> +
> >> +	if (!size)
> >> +		return;
> >> +
> >> +	ret = memblock_isolate_range(&memblock.memory, base, size,
> >> +						&start_rgn, &end_rgn);
> >> +	if (ret)
> >> +		return;
> >> +
> >> +	/* remove all the MAP regions */
> >> +	for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> >> +		if (!memblock_is_nomap(&memblock.memory.regions[i]))
> >> +			memblock_remove_region(&memblock.memory, i);
> > 
> > In the case that we have only one, giant memblock that covers base all
> > of base + size, can't we end up with start_rgn = end_rgn = 0? In which
> 
> Can this happen? If we only have one memblock that exactly spans
> base:(base+size), memblock_isolate_range() will hit the '@rgn is fully
> contained, record it' code and set start_rgn=0,end_rgn=1. (rbase==base,
> rend==end). We only go round the loop once.
> 
> If we only have one memblock that is bigger than base:(base+size) we end up with
> three regions, start_rgn=1,end_rgn=2. The trickery here is the '@rgn intersects
> from above' code decreases the loop counter so we process the same entry twice,
> hitting '@rgn is fully contained, record it' the second time round... so we go
> round the loop four times.
> 
> I can't see how we hit the:
> > 	if (rbase >= end)
> > 		break;
> > 	if (rend <= base)
> > 		continue;
> 
> code in either case...

I consistently misread that as rend >= end and rbase <= base! In which case,
I agree with your analysis:

Reviewed-by: Will Deacon <will.deacon@arm.com>

The patch could probably still use an ack from an mm person.

Will

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v27 1/9] memblock: add memblock_cap_memory_range()
Date: Fri, 18 Nov 2016 12:10:36 +0000	[thread overview]
Message-ID: <20161118121036.GK13470@arm.com> (raw)
In-Reply-To: <582DF05A.9050601@arm.com>

On Thu, Nov 17, 2016 at 06:00:58PM +0000, James Morse wrote:
> On 17/11/16 11:19, Will Deacon wrote:
> > It looks much better, thanks! Just one question below.
> > 
> 
> > On Thu, Nov 17, 2016 at 02:34:24PM +0900, AKASHI Takahiro wrote:
> >> diff --git a/mm/memblock.c b/mm/memblock.c
> >> index 7608bc3..fea1688 100644
> >> --- a/mm/memblock.c
> >> +++ b/mm/memblock.c
> >> @@ -1514,11 +1514,37 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
> >>  			      (phys_addr_t)ULLONG_MAX);
> >>  }
> >>  
> >> +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> >> +{
> >> +	int start_rgn, end_rgn;
> >> +	int i, ret;
> >> +
> >> +	if (!size)
> >> +		return;
> >> +
> >> +	ret = memblock_isolate_range(&memblock.memory, base, size,
> >> +						&start_rgn, &end_rgn);
> >> +	if (ret)
> >> +		return;
> >> +
> >> +	/* remove all the MAP regions */
> >> +	for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> >> +		if (!memblock_is_nomap(&memblock.memory.regions[i]))
> >> +			memblock_remove_region(&memblock.memory, i);
> > 
> > In the case that we have only one, giant memblock that covers base all
> > of base + size, can't we end up with start_rgn = end_rgn = 0? In which
> 
> Can this happen? If we only have one memblock that exactly spans
> base:(base+size), memblock_isolate_range() will hit the '@rgn is fully
> contained, record it' code and set start_rgn=0,end_rgn=1. (rbase==base,
> rend==end). We only go round the loop once.
> 
> If we only have one memblock that is bigger than base:(base+size) we end up with
> three regions, start_rgn=1,end_rgn=2. The trickery here is the '@rgn intersects
> from above' code decreases the loop counter so we process the same entry twice,
> hitting '@rgn is fully contained, record it' the second time round... so we go
> round the loop four times.
> 
> I can't see how we hit the:
> > 	if (rbase >= end)
> > 		break;
> > 	if (rend <= base)
> > 		continue;
> 
> code in either case...

I consistently misread that as rend >= end and rbase <= base! In which case,
I agree with your analysis:

Reviewed-by: Will Deacon <will.deacon@arm.com>

The patch could probably still use an ack from an mm person.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: James Morse <james.morse@arm.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Dennis Chen <dennis.chen@arm.com>,
	catalin.marinas@arm.com, akpm@linux-foundation.org,
	geoff@infradead.org, bauerman@linux.vnet.ibm.com,
	dyoung@redhat.com, mark.rutland@arm.com,
	kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org,
	linux-mm@kvack.orgnd@arm.com
Subject: Re: [PATCH v27 1/9] memblock: add memblock_cap_memory_range()
Date: Fri, 18 Nov 2016 12:10:36 +0000	[thread overview]
Message-ID: <20161118121036.GK13470@arm.com> (raw)
In-Reply-To: <582DF05A.9050601@arm.com>

On Thu, Nov 17, 2016 at 06:00:58PM +0000, James Morse wrote:
> On 17/11/16 11:19, Will Deacon wrote:
> > It looks much better, thanks! Just one question below.
> > 
> 
> > On Thu, Nov 17, 2016 at 02:34:24PM +0900, AKASHI Takahiro wrote:
> >> diff --git a/mm/memblock.c b/mm/memblock.c
> >> index 7608bc3..fea1688 100644
> >> --- a/mm/memblock.c
> >> +++ b/mm/memblock.c
> >> @@ -1514,11 +1514,37 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
> >>  			      (phys_addr_t)ULLONG_MAX);
> >>  }
> >>  
> >> +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> >> +{
> >> +	int start_rgn, end_rgn;
> >> +	int i, ret;
> >> +
> >> +	if (!size)
> >> +		return;
> >> +
> >> +	ret = memblock_isolate_range(&memblock.memory, base, size,
> >> +						&start_rgn, &end_rgn);
> >> +	if (ret)
> >> +		return;
> >> +
> >> +	/* remove all the MAP regions */
> >> +	for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> >> +		if (!memblock_is_nomap(&memblock.memory.regions[i]))
> >> +			memblock_remove_region(&memblock.memory, i);
> > 
> > In the case that we have only one, giant memblock that covers base all
> > of base + size, can't we end up with start_rgn = end_rgn = 0? In which
> 
> Can this happen? If we only have one memblock that exactly spans
> base:(base+size), memblock_isolate_range() will hit the '@rgn is fully
> contained, record it' code and set start_rgn=0,end_rgn=1. (rbase==base,
> rend==end). We only go round the loop once.
> 
> If we only have one memblock that is bigger than base:(base+size) we end up with
> three regions, start_rgn=1,end_rgn=2. The trickery here is the '@rgn intersects
> from above' code decreases the loop counter so we process the same entry twice,
> hitting '@rgn is fully contained, record it' the second time round... so we go
> round the loop four times.
> 
> I can't see how we hit the:
> > 	if (rbase >= end)
> > 		break;
> > 	if (rend <= base)
> > 		continue;
> 
> code in either case...

I consistently misread that as rend >= end and rbase <= base! In which case,
I agree with your analysis:

Reviewed-by: Will Deacon <will.deacon@arm.com>

The patch could probably still use an ack from an mm person.

Will

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

  parent reply	other threads:[~2016-11-18 12:10 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-02  4:49 [PATCH v27 0/9] arm64: add kdump support AKASHI Takahiro
2016-11-02  4:49 ` AKASHI Takahiro
2016-11-02  4:51 ` [PATCH v27 1/9] memblock: add memblock_cap_memory_range() AKASHI Takahiro
2016-11-02  4:51   ` AKASHI Takahiro
2016-11-02  4:51   ` AKASHI Takahiro
2016-11-10 17:27   ` Will Deacon
2016-11-10 17:27     ` Will Deacon
2016-11-10 17:27     ` Will Deacon
2016-11-11  2:50     ` AKASHI Takahiro
2016-11-11  2:50       ` AKASHI Takahiro
2016-11-11  2:50       ` AKASHI Takahiro
2016-11-11  3:19       ` Dennis Chen
2016-11-11  3:19         ` Dennis Chen
2016-11-11  3:19         ` Dennis Chen
2016-11-14  5:55         ` AKASHI Takahiro
2016-11-14  5:55           ` AKASHI Takahiro
2016-11-14  5:55           ` AKASHI Takahiro
2016-11-16 16:30           ` Will Deacon
2016-11-16 16:30             ` Will Deacon
2016-11-16 16:30             ` Will Deacon
2016-11-17  5:34             ` AKASHI Takahiro
2016-11-17  5:34               ` AKASHI Takahiro
2016-11-17  5:34               ` AKASHI Takahiro
2016-11-17 11:19               ` Will Deacon
2016-11-17 11:19                 ` Will Deacon
2016-11-17 11:19                 ` Will Deacon
2016-11-17 18:00                 ` James Morse
2016-11-17 18:00                   ` James Morse
2016-11-17 18:00                   ` James Morse
2016-11-18  1:03                   ` AKASHI Takahiro
2016-11-18  1:03                     ` AKASHI Takahiro
2016-11-18  1:03                     ` AKASHI Takahiro
2016-11-18 12:10                   ` Will Deacon [this message]
2016-11-18 12:10                     ` Will Deacon
2016-11-18 12:10                     ` Will Deacon
2016-11-02  4:52 ` [PATCH v27 2/9] arm64: limit memory regions based on DT property, usable-memory-range AKASHI Takahiro
2016-11-02  4:52   ` AKASHI Takahiro
2016-11-02  4:52 ` [PATCH v27 3/9] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2016-11-02  4:52   ` AKASHI Takahiro
2016-11-02  4:52 ` [PATCH v27 4/9] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
2016-11-02  4:52   ` AKASHI Takahiro
2016-11-02  4:52 ` [PATCH v27 5/9] arm64: kdump: add VMCOREINFO's for user-space tools AKASHI Takahiro
2016-11-02  4:52   ` AKASHI Takahiro
2016-11-02  4:52 ` [PATCH v27 6/9] arm64: kdump: provide /proc/vmcore file AKASHI Takahiro
2016-11-02  4:52   ` AKASHI Takahiro
2016-11-02  4:52 ` [PATCH v27 7/9] arm64: kdump: enable kdump in defconfig AKASHI Takahiro
2016-11-02  4:52   ` AKASHI Takahiro
2016-11-02  4:52 ` [PATCH v27 8/9] Documentation: kdump: describe arm64 port AKASHI Takahiro
2016-11-02  4:52   ` AKASHI Takahiro
2016-11-02  4:54 ` [PATCH v27 9/9] Documentation: dt: chosen properties for arm64 kdump AKASHI Takahiro
2016-11-02  4:54   ` AKASHI Takahiro
2016-11-02  4:54   ` AKASHI Takahiro
2016-11-02  9:39 ` [PATCH v27 0/9] arm64: add kdump support Pratyush Anand
2016-11-02  9:39   ` Pratyush Anand
2016-11-04  3:00 ` AKASHI Takahiro
2016-11-04  3:00   ` AKASHI Takahiro
2016-11-10 16:06   ` James Morse
2016-11-10 16:06     ` James Morse

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=20161118121036.GK13470@arm.com \
    --to=will.deacon@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=bauerman@linux.vnet.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=dennis.chen@arm.com \
    --cc=dyoung@redhat.com \
    --cc=geoff@infradead.org \
    --cc=james.morse@arm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=nd@arm.com \
    --cc=takahiro.akashi@linaro.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.