archive mirror
 help / color / mirror / Atom feed
From: Mike Kravetz <>
To: Matthew Wilcox <>,
	Andrew Morton <>
Cc: "Aneesh Kumar K.V" <>,,
Subject: Re: [RFC PATCH] mm/hugetlb: make hugetlb_lock irq safe
Date: Wed, 5 Sep 2018 16:51:00 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 09/05/2018 04:07 PM, Matthew Wilcox wrote:
> On Wed, Sep 05, 2018 at 03:00:08PM -0700, Andrew Morton wrote:
>> On Wed, 5 Sep 2018 14:35:11 -0700 Mike Kravetz <> wrote:
>>>>                                            so perhaps we could put some
>>>> stopgap workaround into that site and add a runtime warning into the
>>>> put_page() code somewhere to detect puttage of huge pages from hardirq
>>>> and softirq contexts.
>>> I think we would add the warning/etc at free_huge_page.  The issue would
>>> only apply to hugetlb pages, not THP.
>>> But, the more I think about it the more I think Aneesh's patch to do
>>> spin_lock/unlock_irqsave is the right way to go.  Currently, we only
>>> know of one place where a put_page of hugetlb pages is done from softirq
>>> context.  So, we could take the spin_lock/unlock_bh as Matthew suggested.
>>> When the powerpc iommu code was added, I doubt this was taken into account.
>>> I would be afraid of someone adding put_page from hardirq context.
>> Me too.  If we're going to do this, surely we should make hugepages
>> behave in the same fashion as PAGE_SIZE pages.
> But these aren't vanilla hugepages, they're specifically hugetlbfs pages.
> I don't believe there's any problem with calling put_page() on a normally
> allocated huge page or THP.

The powerpc iommu code (at least) treated hugetlbfs pages as any other page
(huge, THP or base) and called put_page from softirq context.

It seems there are at least two ways to address this:
1) Prohibit this behavior for hugetlbfs pages
2) Try to make hugetlbfs pages behave like other pages WRT put_page

Aneesh's patch went further than allowing put_page of hugetlbfs pages
from softirq context.  It allowed them from hardirq context as well:
admittedly at a cost of disabling irqs.

This issue has probably existed since the addition of powerpc iommu code.
IMO, we should make hugetlbfs pages behave more like other pages in this

BTW, free_huge_page called by put_page for hugetlbfs pages may also take
a subpool specific lock via spin_lock().  See hugepage_subpool_put_pages.
So, this would also need to take irq context into account.
Mike Kravetz

  reply	other threads:[~2018-09-05 23:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05 11:23 [RFC PATCH] mm/hugetlb: make hugetlb_lock irq safe Aneesh Kumar K.V
2018-09-05 13:04 ` Matthew Wilcox
2018-09-05 13:26   ` Aneesh Kumar K.V
2018-09-05 13:48     ` Matthew Wilcox
2018-09-05 19:58       ` Andrew Morton
2018-09-05 21:35         ` Mike Kravetz
2018-09-05 22:00           ` Andrew Morton
2018-09-05 23:07             ` Matthew Wilcox
2018-09-05 23:51               ` Mike Kravetz [this message]
2018-09-06  4:03                 ` Aneesh Kumar K.V
2018-09-06 11:19                 ` Michal Hocko
2018-09-06  3:58           ` Aneesh Kumar K.V
2018-09-06  3:54         ` Aneesh Kumar K.V
2018-09-06  4:00       ` Aneesh Kumar K.V

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).