linux-kernel - Re: [PATCH v3 3/3] mm: fs: Invalidate BH LRU during page migration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <239b45ff-dad0-6cd0-4f6e-18159185cd6d@redhat.com>
Date:   Wed, 17 Mar 2021 12:18:07 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Minchan Kim <minchan@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-mm <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>,
        joaodias@...gle.com, surenb@...gle.com, cgoldswo@...eaurora.org,
        willy@...radead.org, mhocko@...e.com, vbabka@...e.cz,
        linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v3 3/3] mm: fs: Invalidate BH LRU during page migration

On 16.03.21 19:26, Minchan Kim wrote:
> On Fri, Mar 12, 2021 at 09:17:23AM -0800, Minchan Kim wrote:
>> On Fri, Mar 12, 2021 at 10:33:48AM +0100, David Hildenbrand wrote:
>>> On 12.03.21 10:03, David Hildenbrand wrote:
>>>> On 10.03.21 17:14, Minchan Kim wrote:
>>>>> ffer_head LRU caches will be pinned and thus cannot be migrated.
>>>>> This can prevent CMA allocations from succeeding, which are often used
>>>>> on platforms with co-processors (such as a DSP) that can only use
>>>>> physically contiguous memory. It can also prevent memory
>>>>> hot-unplugging from succeeding, which involves migrating at least
>>>>> MIN_MEMORY_BLOCK_SIZE bytes of memory, which ranges from 8 MiB to 1
>>>>> GiB based on the architecture in use.
>>>>
>>>> Actually, it's memory_block_size_bytes(), which can be even bigger
>>>> (IIRC, 128MiB..2 GiB on x86-64) that fails to get offlined. But that
>>>> will prevent bigger granularity (e.g., a whole DIMM) from getting unplugged.
>>>>
>>>>>
>>>>> Correspondingly, invalidate the BH LRU caches before a migration
>>>>> starts and stop any buffer_head from being cached in the LRU caches,
>>>>> until migration has finished.
>>>>
>>>> Sounds sane to me.
>>>>
>>>
>>> Diving a bit into the code, I am wondering:
>>>
>>>
>>> a) Are these buffer head pages marked as movable?
>>>
>>> IOW, are they either PageLRU() or __PageMovable()?
>>>
>>>
>>> b) How do these pages end up on ZONE_MOVABLE or MIGRATE_CMA?
>>>
>>> I assume these pages come via
>>> alloc_page_buffers()->alloc_buffer_head()->kmem_cache_zalloc(GFP_NOFS |
>>> __GFP_ACCOUNT)
>>>
>>
>> It's indirect it was not clear
>>
>> try_to_release_page
>>      try_to_free_buffers
>>          buffer_busy
>>              failed
>>
>> Yeah, comment is misleading. This one would be better.
>>
>>          /*
>>           * the refcount of buffer_head in bh_lru prevents dropping the
>>           * attached page(i.e., try_to_free_buffers) so it could cause
>>           * failing page migrationn.
>>           * Skip putting upcoming bh into bh_lru until migration is done.
>>           */
> 

Thanks, that makes more sense to me now :)

> Hi Andrew,
> 
> Could you fold this comment fix patch? If you prefer formal patch,
> let me know. I will resend it.
> 
> Thank you.
> 
>  From 0774f21e2dc8220fc2be80c25f711cb061363519 Mon Sep 17 00:00:00 2001
> From: Minchan Kim <minchan@...nel.org>
> Date: Fri, 12 Mar 2021 09:17:34 -0800
> Subject: [PATCH] comment fix
> 
> Signed-off-by: Minchan Kim <minchan@...nel.org>
> ---
>   fs/buffer.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/buffer.c b/fs/buffer.c
> index ca9dd736bcb8..8602dcbe0327 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -1265,8 +1265,9 @@ static void bh_lru_install(struct buffer_head *bh)
>   
>   	check_irqs_on();
>   	/*
> -	 * buffer_head in bh_lru could increase refcount of the page
> -	 * until it will be invalidated. It causes page migraion failure.
> +	 * the refcount of buffer_head in bh_lru prevents dropping the
> +	 * attached page(i.e., try_to_free_buffers) so it could cause
> +	 * failing page migratoin.

s/migratoin/migration/

>   	 * Skip putting upcoming bh into bh_lru until migration is done.
>   	 */
>   	if (lru_cache_disabled())
> 

Acked-by: David Hildenbrand <david@...hat.com>

-- 
Thanks,

David / dhildenb