All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Oscar Salvador <osalvador@suse.de>, akpm@linux-foundation.org
Cc: mhocko@suse.com, dan.j.williams@intel.com,
	pasha.tatashin@soleen.com, Jonathan.Cameron@huawei.com,
	anshuman.khandual@arm.com, vbabka@suse.cz, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/5] drivers/base/memory: Remove unneeded check in remove_memory_block_devices
Date: Tue, 25 Jun 2019 10:03:31 +0200	[thread overview]
Message-ID: <0ed2f4ec-cc6f-8b81-46b0-d56d90ac1e86@redhat.com> (raw)
In-Reply-To: <3e820fee-f82f-3336-ff34-31c66dbbbbfe@redhat.com>

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().
> 


-- 

Thanks,

David / dhildenb

  reply	other threads:[~2019-06-25  8:03 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-25  7:52 [PATCH v2 0/5] Allocate memmap from hotadded memory Oscar Salvador
2019-06-25  7:52 ` [PATCH v2 1/5] drivers/base/memory: Remove unneeded check in remove_memory_block_devices Oscar Salvador
2019-06-25  8:01   ` David Hildenbrand
2019-06-25  8:03     ` David Hildenbrand [this message]
2019-06-25  8:09       ` Oscar Salvador
2019-06-25  8:27         ` David Hildenbrand
2019-06-25  7:52 ` [PATCH v2 2/5] mm,memory_hotplug: Introduce MHP_VMEMMAP_FLAGS Oscar Salvador
2019-06-25  8:31   ` David Hildenbrand
2019-07-24 20:11   ` Dan Williams
2019-07-24 20:11     ` Dan Williams
2019-07-24 21:36     ` osalvador
2019-07-25  9:27     ` Oscar Salvador
2019-07-25  9:30       ` David Hildenbrand
2019-07-25  9:40         ` Oscar Salvador
2019-07-25 10:04           ` David Hildenbrand
2019-07-25 10:13             ` Oscar Salvador
2019-07-25 10:15               ` David Hildenbrand
2019-06-25  7:52 ` [PATCH v2 3/5] mm,memory_hotplug: Introduce Vmemmap page helpers Oscar Salvador
2019-06-25 10:28   ` David Hildenbrand
2019-06-26  9:48     ` Oscar Salvador
2019-06-25  7:52 ` [PATCH v2 4/5] mm,memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap Oscar Salvador
2019-06-25  8:49   ` David Hildenbrand
2019-06-26  8:13     ` Oscar Salvador
2019-06-26  8:15       ` David Hildenbrand
2019-06-26  8:17   ` Anshuman Khandual
2019-06-26  8:28     ` Oscar Salvador
2019-07-24 21:49   ` Dan Williams
2019-07-24 21:49     ` Dan Williams
2019-06-25  7:52 ` [PATCH v2 5/5] mm,memory_hotplug: Allow userspace to enable/disable vmemmap Oscar Salvador
2019-06-25  8:25 ` [PATCH v2 0/5] Allocate memmap from hotadded memory David Hildenbrand
2019-06-25  8:33   ` David Hildenbrand
2019-06-26  8:03   ` Oscar Salvador
2019-06-26  8:11     ` David Hildenbrand
2019-06-26  8:15       ` Oscar Salvador
2019-06-26  8:27         ` Oscar Salvador
2019-06-26  8:37           ` David Hildenbrand
2019-06-26  8:28         ` David Hildenbrand
2019-07-02  6:42           ` Rashmica Gupta
2019-07-02  6:42             ` Rashmica Gupta
2019-07-02  7:48             ` Oscar Salvador
2019-07-02  8:52               ` Rashmica Gupta
2019-07-10  1:14                 ` Rashmica Gupta
2019-07-10  1:14                   ` Rashmica Gupta
2019-07-31 12:08                 ` Michal Hocko
2019-07-31 23:06                   ` Rashmica Gupta
2019-07-31 23:06                     ` Rashmica Gupta
2019-08-01  7:17                     ` Michal Hocko
2019-08-01  7:18                       ` David Hildenbrand
2019-08-01  7:24                         ` Michal Hocko
2019-08-01  7:26                           ` David Hildenbrand
2019-08-01  7:31                             ` David Hildenbrand
2019-08-01  7:39                               ` Michal Hocko
2019-08-01  7:48                                 ` Michal Hocko
2019-08-01  9:18                                   ` David Hildenbrand
2019-08-01  7:34                             ` Michal Hocko
2019-08-01  7:50                               ` David Hildenbrand
2019-08-01  8:04                                 ` Michal Hocko
2019-07-16 12:28             ` David Hildenbrand
2019-07-29  5:42               ` Rashmica Gupta
2019-07-29  5:42                 ` Rashmica Gupta
2019-07-29  8:06                 ` David Hildenbrand
2019-07-30  7:08                   ` Rashmica Gupta
2019-07-30  7:08                     ` Rashmica Gupta
2019-07-31  2:21                   ` Rashmica Gupta
2019-07-31  2:21                     ` Rashmica Gupta
2019-07-31  9:39                     ` David Hildenbrand

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=0ed2f4ec-cc6f-8b81-46b0-d56d90ac1e86@redhat.com \
    --to=david@redhat.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=dan.j.williams@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=osalvador@suse.de \
    --cc=pasha.tatashin@soleen.com \
    --cc=vbabka@suse.cz \
    /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.