Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Subject: Re: [PATCH] mm/hwpoison: fix build error without
 CONFIG_MEMORY_FAILURE
To:     Naoya Horiguchi <naoya.horiguchi@linux.dev>
References: <20220927102946.98622-1-tanghui20@huawei.com>
 <20220927125350.GA500539@u2004.lan>
CC:     <naoya.horiguchi@nec.com>, <linmiaohe@huawei.com>,
        <akpm@linux-foundation.org>, <linux-mm@kvack.org>,
        <linux-kernel@vger.kernel.org>
From:   Hui Tang <tanghui20@huawei.com>
Message-ID: <c7b234ae-db3a-ef9e-714d-a911d37a272a@huawei.com>
Date:   Wed, 28 Sep 2022 10:54:20 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <20220927125350.GA500539@u2004.lan>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 2022/9/27 20:53, Naoya Horiguchi wrote:
> On Tue, Sep 27, 2022 at 06:29:46PM +0800, Hui Tang wrote:
>> Building without CONFIG_MEMORY_FAILURE will fail:
>>
>> mm/memory-failure.o: In function `action_result':
>> memory-failure.c: undefined reference to `memblk_nr_poison_inc'
>> mm/memory-failure.o: In function `page_handle_poison':
>> memory-failure.c: undefined reference to `memblk_nr_poison_inc'
>> mm/memory-failure.o: In function `__get_huge_page_for_hwpoison':
>> memory-failure.c: undefined reference to `memblk_nr_poison_inc'
>> mm/memory-failure.o: In function `unpoison_memory':
>> memory-failure.c: undefined reference to `memblk_nr_poison_sub'
>> mm/memory-failure.o: In function `num_poisoned_pages_inc':
>> memory-failure.c: undefined reference to `memblk_nr_poison_inc'
>>
>> Add CONFIG_MEMORY_FAILURE wrapper for invoking memblk_nr_poison_{inc|sub}.
>>
>> Fixes: 69b496f03bb4 ("mm/hwpoison: introduce per-memory_block hwpoison counter")
>> Signed-off-by: Hui Tang <tanghui20@huawei.com>
>
> Thank you for the patch.  I have a question.
> If you disables CONFIG_MEMORY_FAILURE, mm/memory-failure.c should
> not be compiled, so I wonder why you saw the compile error.
> Could you share your .config file?
>
> Acutally I saw the similar report a few days ago
> https://lore.kernel.org/lkml/20220923095013.1151252-1-michael@walle.cc/
> , where the build error happened in aarch64,  so I likely missed some arch
> dependency.  I responded to the report by updating the patch by applying
> "#if defined(CONFIG_MEMORY_FAILURE) && defined(CONFIG_MEMORY_HOTPLUG)"
> to the definition of memblk_nr_poison_{inc,sub}.
> https://lore.kernel.org/lkml/20220923141204.GA1484969@ik1-406-35019.vs.sakura.ne.jp/
>
> I did not confirm that this fix is really right, because I can't reproduced
> the build error in my environment.  So could you check that v5 patch fixes
> the build error you're seeing?  (The current version in mm-unstable is v4,
> so that should be replaced with v5.)

   Yes, when appling the latest patch, this build error is gone, thanks.

>
>> ---
>>  mm/memory-failure.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
>> index 03479895086d..5bb9d2d20234 100644
>> --- a/mm/memory-failure.c
>> +++ b/mm/memory-failure.c
>> @@ -77,14 +77,18 @@ static bool hw_memory_failure __read_mostly = false;
>>  void num_poisoned_pages_inc(unsigned long pfn)
>>  {
>>  	atomic_long_inc(&num_poisoned_pages);
>> +#ifdef CONFIG_MEMORY_FAILURE
>>  	memblk_nr_poison_inc(pfn);
>> +#endif
>>  }
>>
>>  static inline void num_poisoned_pages_sub(unsigned long pfn, long i)
>>  {
>>  	atomic_long_sub(i, &num_poisoned_pages);
>> +#ifdef CONFIG_MEMORY_FAILURE
>>  	if (pfn != -1UL)
>>  		memblk_nr_poison_sub(pfn, i);
>> +#endif
>>  }
>>
>>  /*
>> --
>> 2.17.1
>>
>>
>>
> .
>