From: Matthew Wilcox <willy@infradead.org>
To: NeilBrown <neilb@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>,
Thierry Reding <thierry.reding@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] MM: discard __GFP_ATOMIC
Date: Wed, 17 Nov 2021 13:18:25 +0000 [thread overview]
Message-ID: <YZUBIbALcSHn4Rub@casper.infradead.org> (raw)
In-Reply-To: <163712397076.13692.4727608274002939094@noble.neil.brown.name>
On Wed, Nov 17, 2021 at 03:39:30PM +1100, NeilBrown wrote:
> +++ b/drivers/iommu/tegra-smmu.c
> @@ -676,12 +676,12 @@ static struct page *as_get_pde_page(struct tegra_smmu_as *as,
> * allocate page in a sleeping context if GFP flags permit. Hence
> * spinlock needs to be unlocked and re-locked after allocation.
> */
> - if (!(gfp & __GFP_ATOMIC))
> + if (gfp & __GFP_DIRECT_RECLAIM)
> spin_unlock_irqrestore(&as->lock, *flags);
>
> page = alloc_page(gfp | __GFP_DMA | __GFP_ZERO);
>
> - if (!(gfp & __GFP_ATOMIC))
> + if (gfp & __GFP_DIRECT_RECLAIM)
> spin_lock_irqsave(&as->lock, *flags);
>
> /*
Surely this should be gfpflags_allow_blocking() instead of poking about
in the innards of gfp flags?
This patch seems like a good simplification to me.
Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
next prev parent reply other threads:[~2021-11-17 13:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-17 4:39 [PATCH] MM: discard __GFP_ATOMIC NeilBrown
2021-11-17 13:18 ` Matthew Wilcox [this message]
2021-11-18 23:14 ` NeilBrown
2021-11-19 14:10 ` Matthew Wilcox
2021-11-20 10:51 ` NeilBrown
2021-11-22 16:54 ` Michal Hocko
2021-11-23 4:15 ` NeilBrown
2021-11-23 14:27 ` Michal Hocko
2021-11-18 9:22 ` Michal Hocko
2021-11-18 13:27 ` Mel Gorman
2021-11-18 23:02 ` NeilBrown
2021-11-22 16:43 ` Michal Hocko
2021-11-23 4:33 ` NeilBrown
2021-11-23 13:41 ` Michal Hocko
2022-04-30 18:30 ` Andrew Morton
2022-05-01 15:45 ` Michal Hocko
2022-09-06 7:35 ` Michal Hocko
2022-09-07 9:47 ` Mel Gorman
2022-10-17 2:38 ` Andrew Morton
2022-10-18 12:11 ` Mel Gorman
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=YZUBIbALcSHn4Rub@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=neilb@suse.de \
--cc=thierry.reding@gmail.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 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).