[v2,1/5] drivers/base/memory: Remove unneeded check in remove_memory_block_devices
diff mbox series

Message ID 20190625075227.15193-2-osalvador@suse.de
State New
Headers show
Series
  • Allocate memmap from hotadded memory
Related show

Commit Message

Oscar Salvador June 25, 2019, 7:52 a.m. UTC
remove_memory_block_devices() checks for the range to be aligned
to memory_block_size_bytes, which is our current memory block size,
and WARNs_ON and bails out if it is not.

This is the right to do, but we do already do that in try_remove_memory(),
where remove_memory_block_devices() gets called from, and we even are
more strict in try_remove_memory, since we directly BUG_ON in case the range
is not properly aligned.

Since remove_memory_block_devices() is only called from try_remove_memory(),
we can safely drop the check here.

To be honest, I am not sure if we should kill the system in case we cannot
remove memory.
I tend to think that WARN_ON and return and error is better.

Signed-off-by: Oscar Salvador <osalvador@suse.de>
---
 drivers/base/memory.c | 4 ----
 1 file changed, 4 deletions(-)

Comments

David Hildenbrand June 25, 2019, 8:01 a.m. UTC | #1
On 25.06.19 09:52, Oscar Salvador wrote:
> remove_memory_block_devices() checks for the range to be aligned
> to memory_block_size_bytes, which is our current memory block size,
> and WARNs_ON and bails out if it is not.
> 
> This is the right to do, but we do already do that in try_remove_memory(),
> where remove_memory_block_devices() gets called from, and we even are
> more strict in try_remove_memory, since we directly BUG_ON in case the range
> is not properly aligned.
> 
> Since remove_memory_block_devices() is only called from try_remove_memory(),
> we can safely drop the check here.
> 
> To be honest, I am not sure if we should kill the system in case we cannot
> remove memory.
> I tend to think that WARN_ON and return and error is better.

I failed to parse this sentence.

> 
> Signed-off-by: Oscar Salvador <osalvador@suse.de>
> ---
>  drivers/base/memory.c | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 826dd76f662e..07ba731beb42 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -771,10 +771,6 @@ void remove_memory_block_devices(unsigned long start, unsigned long size)
>  	struct memory_block *mem;
>  	int block_id;
>  
> -	if (WARN_ON_ONCE(!IS_ALIGNED(start, memory_block_size_bytes()) ||
> -			 !IS_ALIGNED(size, memory_block_size_bytes())))
> -		return;
> -
>  	mutex_lock(&mem_sysfs_mutex);
>  	for (block_id = start_block_id; block_id != end_block_id; block_id++) {
>  		mem = find_memory_block_by_id(block_id, NULL);
> 

As I said when I introduced this, I prefer to have such duplicate checks
in place in case we have dependent code splattered over different files.
(especially mm/ vs. drivers/base). Such simple checks avoid to document
"start and size have to be aligned to memory blocks".

If you still insist, then also remove the same sequence from
create_memory_block_devices().
David Hildenbrand June 25, 2019, 8:03 a.m. UTC | #2
On 25.06.19 10:01, David Hildenbrand wrote:
> On 25.06.19 09:52, Oscar Salvador wrote:
>> remove_memory_block_devices() checks for the range to be aligned
>> to memory_block_size_bytes, which is our current memory block size,
>> and WARNs_ON and bails out if it is not.
>>
>> This is the right to do, but we do already do that in try_remove_memory(),
>> where remove_memory_block_devices() gets called from, and we even are
>> more strict in try_remove_memory, since we directly BUG_ON in case the range
>> is not properly aligned.
>>
>> Since remove_memory_block_devices() is only called from try_remove_memory(),
>> we can safely drop the check here.
>>
>> To be honest, I am not sure if we should kill the system in case we cannot
>> remove memory.
>> I tend to think that WARN_ON and return and error is better.
> 
> I failed to parse this sentence.
> 
>>
>> Signed-off-by: Oscar Salvador <osalvador@suse.de>
>> ---
>>  drivers/base/memory.c | 4 ----
>>  1 file changed, 4 deletions(-)
>>
>> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
>> index 826dd76f662e..07ba731beb42 100644
>> --- a/drivers/base/memory.c
>> +++ b/drivers/base/memory.c
>> @@ -771,10 +771,6 @@ void remove_memory_block_devices(unsigned long start, unsigned long size)
>>  	struct memory_block *mem;
>>  	int block_id;
>>  
>> -	if (WARN_ON_ONCE(!IS_ALIGNED(start, memory_block_size_bytes()) ||
>> -			 !IS_ALIGNED(size, memory_block_size_bytes())))
>> -		return;
>> -
>>  	mutex_lock(&mem_sysfs_mutex);
>>  	for (block_id = start_block_id; block_id != end_block_id; block_id++) {
>>  		mem = find_memory_block_by_id(block_id, NULL);
>>
> 
> As I said when I introduced this, I prefer to have such duplicate checks
> in place in case we have dependent code splattered over different files.
> (especially mm/ vs. drivers/base). Such simple checks avoid to document
> "start and size have to be aligned to memory blocks".

Lol, I even documented it as well. So yeah, if you're going to drop this
once, also drop the one in create_memory_block_devices().

> 
> If you still insist, then also remove the same sequence from
> create_memory_block_devices().
>
Oscar Salvador June 25, 2019, 8:09 a.m. UTC | #3
On Tue, Jun 25, 2019 at 10:03:31AM +0200, David Hildenbrand wrote:
> On 25.06.19 10:01, David Hildenbrand wrote:
> > On 25.06.19 09:52, Oscar Salvador wrote:
> >> remove_memory_block_devices() checks for the range to be aligned
> >> to memory_block_size_bytes, which is our current memory block size,
> >> and WARNs_ON and bails out if it is not.
> >>
> >> This is the right to do, but we do already do that in try_remove_memory(),
> >> where remove_memory_block_devices() gets called from, and we even are
> >> more strict in try_remove_memory, since we directly BUG_ON in case the range
> >> is not properly aligned.
> >>
> >> Since remove_memory_block_devices() is only called from try_remove_memory(),
> >> we can safely drop the check here.
> >>
> >> To be honest, I am not sure if we should kill the system in case we cannot
> >> remove memory.
> >> I tend to think that WARN_ON and return and error is better.
> > 
> > I failed to parse this sentence.
> > 
> >>
> >> Signed-off-by: Oscar Salvador <osalvador@suse.de>
> >> ---
> >>  drivers/base/memory.c | 4 ----
> >>  1 file changed, 4 deletions(-)
> >>
> >> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> >> index 826dd76f662e..07ba731beb42 100644
> >> --- a/drivers/base/memory.c
> >> +++ b/drivers/base/memory.c
> >> @@ -771,10 +771,6 @@ void remove_memory_block_devices(unsigned long start, unsigned long size)
> >>  	struct memory_block *mem;
> >>  	int block_id;
> >>  
> >> -	if (WARN_ON_ONCE(!IS_ALIGNED(start, memory_block_size_bytes()) ||
> >> -			 !IS_ALIGNED(size, memory_block_size_bytes())))
> >> -		return;
> >> -
> >>  	mutex_lock(&mem_sysfs_mutex);
> >>  	for (block_id = start_block_id; block_id != end_block_id; block_id++) {
> >>  		mem = find_memory_block_by_id(block_id, NULL);
> >>
> > 
> > As I said when I introduced this, I prefer to have such duplicate checks
> > in place in case we have dependent code splattered over different files.
> > (especially mm/ vs. drivers/base). Such simple checks avoid to document
> > "start and size have to be aligned to memory blocks".
> 
> Lol, I even documented it as well. So yeah, if you're going to drop this
> once, also drop the one in create_memory_block_devices().

TBH, I would not mind sticking with it.
What sticked out the most was that in the previous check, we BUG_on while
here we just print out a warning, so it seemed quite "inconsistent" to me.

And I only stumbled upon this when I was testing a kernel module that
hot-removed memory in a different granularity.

Anyway, I do not really feel strong here, I can perfectly drop this patch as I
would rather have the focus in the following-up patches, which are the important
ones IMO.

> 
> > 
> > If you still insist, then also remove the same sequence from
> > create_memory_block_devices().
> > 
> 
> 
> -- 
> 
> Thanks,
> 
> David / dhildenb
>
David Hildenbrand June 25, 2019, 8:27 a.m. UTC | #4
On 25.06.19 10:09, Oscar Salvador wrote:
> On Tue, Jun 25, 2019 at 10:03:31AM +0200, David Hildenbrand wrote:
>> On 25.06.19 10:01, David Hildenbrand wrote:
>>> On 25.06.19 09:52, Oscar Salvador wrote:
>>>> remove_memory_block_devices() checks for the range to be aligned
>>>> to memory_block_size_bytes, which is our current memory block size,
>>>> and WARNs_ON and bails out if it is not.
>>>>
>>>> This is the right to do, but we do already do that in try_remove_memory(),
>>>> where remove_memory_block_devices() gets called from, and we even are
>>>> more strict in try_remove_memory, since we directly BUG_ON in case the range
>>>> is not properly aligned.
>>>>
>>>> Since remove_memory_block_devices() is only called from try_remove_memory(),
>>>> we can safely drop the check here.
>>>>
>>>> To be honest, I am not sure if we should kill the system in case we cannot
>>>> remove memory.
>>>> I tend to think that WARN_ON and return and error is better.
>>>
>>> I failed to parse this sentence.
>>>
>>>>
>>>> Signed-off-by: Oscar Salvador <osalvador@suse.de>
>>>> ---
>>>>  drivers/base/memory.c | 4 ----
>>>>  1 file changed, 4 deletions(-)
>>>>
>>>> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
>>>> index 826dd76f662e..07ba731beb42 100644
>>>> --- a/drivers/base/memory.c
>>>> +++ b/drivers/base/memory.c
>>>> @@ -771,10 +771,6 @@ void remove_memory_block_devices(unsigned long start, unsigned long size)
>>>>  	struct memory_block *mem;
>>>>  	int block_id;
>>>>  
>>>> -	if (WARN_ON_ONCE(!IS_ALIGNED(start, memory_block_size_bytes()) ||
>>>> -			 !IS_ALIGNED(size, memory_block_size_bytes())))
>>>> -		return;
>>>> -
>>>>  	mutex_lock(&mem_sysfs_mutex);
>>>>  	for (block_id = start_block_id; block_id != end_block_id; block_id++) {
>>>>  		mem = find_memory_block_by_id(block_id, NULL);
>>>>
>>>
>>> As I said when I introduced this, I prefer to have such duplicate checks
>>> in place in case we have dependent code splattered over different files.
>>> (especially mm/ vs. drivers/base). Such simple checks avoid to document
>>> "start and size have to be aligned to memory blocks".
>>
>> Lol, I even documented it as well. So yeah, if you're going to drop this
>> once, also drop the one in create_memory_block_devices().
> 
> TBH, I would not mind sticking with it.
> What sticked out the most was that in the previous check, we BUG_on while
> here we just print out a warning, so it seemed quite "inconsistent" to me.
> 
> And I only stumbled upon this when I was testing a kernel module that
> hot-removed memory in a different granularity.
> 
> Anyway, I do not really feel strong here, I can perfectly drop this patch as I
> would rather have the focus in the following-up patches, which are the important
> ones IMO.

Whetever you prefer, I can live with either :)

(yes, separating this patch from the others makes sense)

Patch
diff mbox series

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 826dd76f662e..07ba731beb42 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -771,10 +771,6 @@  void remove_memory_block_devices(unsigned long start, unsigned long size)
 	struct memory_block *mem;
 	int block_id;
 
-	if (WARN_ON_ONCE(!IS_ALIGNED(start, memory_block_size_bytes()) ||
-			 !IS_ALIGNED(size, memory_block_size_bytes())))
-		return;
-
 	mutex_lock(&mem_sysfs_mutex);
 	for (block_id = start_block_id; block_id != end_block_id; block_id++) {
 		mem = find_memory_block_by_id(block_id, NULL);