2021-07-13 13:57:55

by Mel Gorman

[permalink] [raw]
Subject: [PATCH 0/4] 5.14-rc1 mm/page_alloc.c stray patches

This series is some fixes that would have likely have been included in
the 5.14-rc1 merge window if they were on time. Mail indicates that some
may already be picked up for mmotm but the tree is not up to date yet so
I'm including them just in case.

Three are fixes to the bulk memory allocator and one is a fallout from
cleaning up warnings that trips BTF that expected a symbol to be global.

mm/page_alloc.c | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)

--
2.26.2


2021-07-13 13:58:00

by Mel Gorman

[permalink] [raw]
Subject: [PATCH 4/4] Revert "mm/page_alloc: make should_fail_alloc_page() static"

From: Matteo Croce <[email protected]>

This reverts commit f7173090033c70886d925995e9dfdfb76dbb2441.

Fix an unresolved symbol error when CONFIG_DEBUG_INFO_BTF=y:

LD vmlinux
BTFIDS vmlinux
FAILED unresolved symbol should_fail_alloc_page
make: *** [Makefile:1199: vmlinux] Error 255
make: *** Deleting file 'vmlinux'

Fixes: f7173090033c ("mm/page_alloc: make should_fail_alloc_page() static")
Signed-off-by: Matteo Croce <[email protected]>
Acked-by: Mel Gorman <[email protected]>
Signed-off-by: Mel Gorman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
---
mm/page_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e0eeb7391ec7..147bbd467214 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3820,7 +3820,7 @@ static inline bool __should_fail_alloc_page(gfp_t gfp_mask, unsigned int order)

#endif /* CONFIG_FAIL_PAGE_ALLOC */

-static noinline bool should_fail_alloc_page(gfp_t gfp_mask, unsigned int order)
+noinline bool should_fail_alloc_page(gfp_t gfp_mask, unsigned int order)
{
return __should_fail_alloc_page(gfp_mask, order);
}
--
2.26.2

2021-07-13 14:00:13

by Mel Gorman

[permalink] [raw]
Subject: [PATCH 2/4] mm/page_alloc: correct return value when failing at preparing

From: Yanfei Xu <[email protected]>

If the array passed in is already partially populated, we should
return "nr_populated" even failing at preparing arguments stage.

Signed-off-by: Yanfei Xu <[email protected]>
Signed-off-by: Mel Gorman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
---
mm/page_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6ef86f338151..803414ce9264 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5255,7 +5255,7 @@ unsigned long __alloc_pages_bulk(gfp_t gfp, int preferred_nid,
gfp &= gfp_allowed_mask;
alloc_gfp = gfp;
if (!prepare_alloc_pages(gfp, 0, preferred_nid, nodemask, &ac, &alloc_gfp, &alloc_flags))
- return 0;
+ return nr_populated;
gfp = alloc_gfp;

/* Find an allowed local zone that meets the low watermark. */
--
2.26.2

2021-07-13 14:24:14

by Chuck Lever

[permalink] [raw]
Subject: Re: [PATCH 2/4] mm/page_alloc: correct return value when failing at preparing



> On Jul 13, 2021, at 9:56 AM, Mel Gorman <[email protected]> wrote:
>
> From: Yanfei Xu <[email protected]>
>
> If the array passed in is already partially populated, we should
> return "nr_populated" even failing at preparing arguments stage.
>
> Signed-off-by: Yanfei Xu <[email protected]>
> Signed-off-by: Mel Gorman <[email protected]>
> Link: https://lore.kernel.org/r/[email protected]
> ---
> mm/page_alloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 6ef86f338151..803414ce9264 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5255,7 +5255,7 @@ unsigned long __alloc_pages_bulk(gfp_t gfp, int preferred_nid,
> gfp &= gfp_allowed_mask;
> alloc_gfp = gfp;
> if (!prepare_alloc_pages(gfp, 0, preferred_nid, nodemask, &ac, &alloc_gfp, &alloc_flags))
> - return 0;
> + return nr_populated;

Can you restore the hunk in patch 3/4 that changes this "return nr_populated;"
to "goto out;" ?


> gfp = alloc_gfp;
>
> /* Find an allowed local zone that meets the low watermark. */
> --
> 2.26.2
>

--
Chuck Lever



2021-07-13 14:57:21

by Mel Gorman

[permalink] [raw]
Subject: Re: [PATCH 2/4] mm/page_alloc: correct return value when failing at preparing

On Tue, Jul 13, 2021 at 02:21:58PM +0000, Chuck Lever III wrote:
>
>
> > On Jul 13, 2021, at 9:56 AM, Mel Gorman <[email protected]> wrote:
> >
> > From: Yanfei Xu <[email protected]>
> >
> > If the array passed in is already partially populated, we should
> > return "nr_populated" even failing at preparing arguments stage.
> >
> > Signed-off-by: Yanfei Xu <[email protected]>
> > Signed-off-by: Mel Gorman <[email protected]>
> > Link: https://lore.kernel.org/r/[email protected]
> > ---
> > mm/page_alloc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 6ef86f338151..803414ce9264 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -5255,7 +5255,7 @@ unsigned long __alloc_pages_bulk(gfp_t gfp, int preferred_nid,
> > gfp &= gfp_allowed_mask;
> > alloc_gfp = gfp;
> > if (!prepare_alloc_pages(gfp, 0, preferred_nid, nodemask, &ac, &alloc_gfp, &alloc_flags))
> > - return 0;
> > + return nr_populated;
>
> Can you restore the hunk in patch 3/4 that changes this "return nr_populated;"
> to "goto out;" ?
>

I fixed that up in the series I sent out. I applied this patch first
then reconciled the collision with your patch.

--
Mel Gorman
SUSE Labs

2021-07-13 15:03:28

by Chuck Lever

[permalink] [raw]
Subject: Re: [PATCH 2/4] mm/page_alloc: correct return value when failing at preparing



> On Jul 13, 2021, at 10:56 AM, Mel Gorman <[email protected]> wrote:
>
> On Tue, Jul 13, 2021 at 02:21:58PM +0000, Chuck Lever III wrote:
>>
>>
>>> On Jul 13, 2021, at 9:56 AM, Mel Gorman <[email protected]> wrote:
>>>
>>> From: Yanfei Xu <[email protected]>
>>>
>>> If the array passed in is already partially populated, we should
>>> return "nr_populated" even failing at preparing arguments stage.
>>>
>>> Signed-off-by: Yanfei Xu <[email protected]>
>>> Signed-off-by: Mel Gorman <[email protected]>
>>> Link: https://lore.kernel.org/r/[email protected]
>>> ---
>>> mm/page_alloc.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>> index 6ef86f338151..803414ce9264 100644
>>> --- a/mm/page_alloc.c
>>> +++ b/mm/page_alloc.c
>>> @@ -5255,7 +5255,7 @@ unsigned long __alloc_pages_bulk(gfp_t gfp, int preferred_nid,
>>> gfp &= gfp_allowed_mask;
>>> alloc_gfp = gfp;
>>> if (!prepare_alloc_pages(gfp, 0, preferred_nid, nodemask, &ac, &alloc_gfp, &alloc_flags))
>>> - return 0;
>>> + return nr_populated;
>>
>> Can you restore the hunk in patch 3/4 that changes this "return nr_populated;"
>> to "goto out;" ?
>>
>
> I fixed that up in the series I sent out. I applied this patch first
> then reconciled the collision with your patch.

3/4 still needs to change this "return nr_populated;" to "goto out;"
as part of the clean up.


--
Chuck Lever



2021-07-13 15:24:13

by Mel Gorman

[permalink] [raw]
Subject: Re: [PATCH 2/4] mm/page_alloc: correct return value when failing at preparing

On Tue, Jul 13, 2021 at 03:01:24PM +0000, Chuck Lever III wrote:
>
>
> > On Jul 13, 2021, at 10:56 AM, Mel Gorman <[email protected]> wrote:
> >
> > On Tue, Jul 13, 2021 at 02:21:58PM +0000, Chuck Lever III wrote:
> >>
> >>
> >>> On Jul 13, 2021, at 9:56 AM, Mel Gorman <[email protected]> wrote:
> >>>
> >>> From: Yanfei Xu <[email protected]>
> >>>
> >>> If the array passed in is already partially populated, we should
> >>> return "nr_populated" even failing at preparing arguments stage.
> >>>
> >>> Signed-off-by: Yanfei Xu <[email protected]>
> >>> Signed-off-by: Mel Gorman <[email protected]>
> >>> Link: https://lore.kernel.org/r/[email protected]
> >>> ---
> >>> mm/page_alloc.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> >>> index 6ef86f338151..803414ce9264 100644
> >>> --- a/mm/page_alloc.c
> >>> +++ b/mm/page_alloc.c
> >>> @@ -5255,7 +5255,7 @@ unsigned long __alloc_pages_bulk(gfp_t gfp, int preferred_nid,
> >>> gfp &= gfp_allowed_mask;
> >>> alloc_gfp = gfp;
> >>> if (!prepare_alloc_pages(gfp, 0, preferred_nid, nodemask, &ac, &alloc_gfp, &alloc_flags))
> >>> - return 0;
> >>> + return nr_populated;
> >>
> >> Can you restore the hunk in patch 3/4 that changes this "return nr_populated;"
> >> to "goto out;" ?
> >>
> >
> > I fixed that up in the series I sent out. I applied this patch first
> > then reconciled the collision with your patch.
>
> 3/4 still needs to change this "return nr_populated;" to "goto out;"
> as part of the clean up.
>

Sorry, I had that in my git tree but didn't refresh the broken-out
series properly before sending. I've sent a v2.

--
Mel Gorman
SUSE Labs

2021-07-15 09:51:46

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 4/4] Revert "mm/page_alloc: make should_fail_alloc_page() static"

On Tue, Jul 13, 2021 at 02:56:25PM +0100, Mel Gorman wrote:
> From: Matteo Croce <[email protected]>
>
> This reverts commit f7173090033c70886d925995e9dfdfb76dbb2441.
>
> Fix an unresolved symbol error when CONFIG_DEBUG_INFO_BTF=y:

I still fundamentally disagreed with this "fix". Whatever code requires
a function to be non-static without a prototype and reference is
completely fucked up beyond rescue and needs to be disabled util
it can be fixed instead of worked around like this.

2021-07-15 10:32:27

by Mel Gorman

[permalink] [raw]
Subject: Re: [PATCH 4/4] Revert "mm/page_alloc: make should_fail_alloc_page() static"

On Thu, Jul 15, 2021 at 07:34:53AM +0100, Christoph Hellwig wrote:
> On Tue, Jul 13, 2021 at 02:56:25PM +0100, Mel Gorman wrote:
> > From: Matteo Croce <[email protected]>
> >
> > This reverts commit f7173090033c70886d925995e9dfdfb76dbb2441.
> >
> > Fix an unresolved symbol error when CONFIG_DEBUG_INFO_BTF=y:
>
> I still fundamentally disagreed with this "fix". Whatever code requires
> a function to be non-static without a prototype and reference is
> completely fucked up beyond rescue and needs to be disabled util
> it can be fixed instead of worked around like this.

I'm definitely not happy with the fix but the breakage was unintentional
and given that it was done for a W=1 warning, the patch was low priority
and I felt that users that do error injection to stress failure paths at
least had some value. If I was fixing something important, I would feel
differently and we've slammed patches before that fixed warnings while
introducing worse problems. I'm still hoping that BTF gets fixed because
it's the right thing to do.

--
Mel Gorman
SUSE Labs