From: David Hildenbrand <david@redhat.com>
To: Hugh Dickins <hughd@google.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>,
linux-mm@kvack.org, Tony Luck <tony.luck@intel.com>,
Miaohe Lin <linmiaohe@huawei.com>,
nao.horiguchi@gmail.com, Matthew Wilcox <willy@infradead.org>,
Muchun Song <muchun.song@linux.dev>,
Benjamin LaHaise <bcrl@kvack.org>,
jglisse@redhat.com, Zi Yan <ziy@nvidia.com>,
Jiaqi Yan <jiaqiyan@google.com>,
Vishal Moola <vishal.moola@gmail.com>,
Alistair Popple <apopple@nvidia.com>,
Jane Chu <jane.chu@oracle.com>,
Oscar Salvador <osalvador@suse.de>
Subject: Re: [PATCH mm-unstable] mm: migrate: folio_ref_freeze() under xas_lock_irq()
Date: Tue, 25 Jun 2024 22:01:51 +0200 [thread overview]
Message-ID: <d21975fb-fb19-4ed1-8e26-046ffca2cc03@redhat.com> (raw)
In-Reply-To: <07edaae7-ea5d-b6ae-3a10-f611946f9688@google.com>
On 25.06.24 07:04, Hugh Dickins wrote:
> Commit "mm: migrate: split folio_migrate_mapping()" drew attention to
> "Note, the folio_ref_freeze() is moved out of xas_lock_irq(), Since the
> folio is already isolated and locked during migration, so suppose that
> there is no functional change."
>
> That was a mistake. Freezing a folio's refcount to 0 is much like taking
> a spinlock: see how filemap_get_entry() takes rcu_read_lock() then spins
> around until the folio is unfrozen. If the task freezing is preempted (or
> calls cond_resched(), as folio_mc_copy() may do), then it risks deadlock:
> in my case, one CPU in zap_pte_range() with free_swap_and_cache_nr()
> trying to reclaim swap while PTL is held, all the other CPUs in reclaim
> spinning for that PTL.
Very much agreed. I think we should add a proper comment to
folio_ref_freeze() to spell that out.
--
Cheers,
David / dhildenb
prev parent reply other threads:[~2024-06-25 20:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-25 5:04 [PATCH mm-unstable] mm: migrate: folio_ref_freeze() under xas_lock_irq() Hugh Dickins
2024-06-25 9:01 ` Kefeng Wang
2024-06-25 19:23 ` Andrew Morton
2024-06-25 19:51 ` Hugh Dickins
2024-06-26 7:24 ` Kefeng Wang
2024-06-25 20:01 ` David Hildenbrand [this message]
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=d21975fb-fb19-4ed1-8e26-046ffca2cc03@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=bcrl@kvack.org \
--cc=hughd@google.com \
--cc=jane.chu@oracle.com \
--cc=jglisse@redhat.com \
--cc=jiaqiyan@google.com \
--cc=linmiaohe@huawei.com \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=nao.horiguchi@gmail.com \
--cc=osalvador@suse.de \
--cc=tony.luck@intel.com \
--cc=vishal.moola@gmail.com \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/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.