| Message ID | 20190625075227.15193-2-osalvador@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Allocate memmap from hotadded memory | expand |
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().
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(). >
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 >
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)
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);
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(-)