From: Jesper Nilsson <jesper.nilsson@axis.com>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Tejun Heo <tj@kernel.org>, Guenter Roeck <linux@roeck-us.net>,
Christoph Lameter <cl@linux.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Mikael Starvik <starvik@axis.com>,
Jesper Nilsson <jespern@axis.com>,
linux-cris-kernel@axis.com
Subject: Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang)
Date: Tue, 28 Nov 2017 09:19:49 +0100 [thread overview]
Message-ID: <20171128081948.GE32368@axis.com> (raw)
In-Reply-To: <nycvar.YSQ.7.76.1711271534590.5925@knanqh.ubzr>
On Mon, Nov 27, 2017 at 03:51:04PM -0500, Nicolas Pitre wrote:
> On Mon, 27 Nov 2017, Tejun Heo wrote:
>
> > Hello,
> >
> > On Mon, Nov 27, 2017 at 03:31:52PM -0500, Nicolas Pitre wrote:
> > > So IMHO I don't think reverting the commit is the right thing to do.
> > > That commit is clearly not at fault here.
> >
> > It's not about the blame. We just want to avoid breaking boot in a
> > way which is difficult to debug. Once cris is fixed, we can re-apply
> > the patch.
>
> In that case I suggest the following instead. No point penalizing
> everyone for a single architecture's fault. And this will serve as a
> visible reminder to the cris people that they need to clean up.
>
> ----- >8
> Subject: percpu: hack to let the CRIS architecture to boot until they clean up
>
> Commit 438a506180 ("percpu: don't forget to free the temporary struct
> pcpu_alloc_info") uncovered a problem on the CRIS architecture where
> the bootmem allocator is initialized with virtual addresses. Given it
> has:
>
> #define __va(x) ((void *)((unsigned long)(x) | 0x80000000))
>
> then things just work out because the end result is the same whether you
> give this a physical or a virtual address.
>
> Untill you call memblock_free_early(__pa(address)) that is, because
> values from __pa() don't match with the virtual addresses stuffed in the
> bootmem allocator anymore.
>
> Avoid freeing the temporary pcpu_alloc_info memory on that architecture
> until they fix things up to let the kernel boot like it did before.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>
> diff --git a/mm/percpu.c b/mm/percpu.c
> index 79e3549cab..50e7fdf840 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -2719,7 +2719,11 @@ void __init setup_per_cpu_areas(void)
>
> if (pcpu_setup_first_chunk(ai, fc) < 0)
> panic("Failed to initialize percpu areas.");
> +#ifdef CONFIG_CRIS
> +#warning "the CRIS architecture has physical and virtual addresses confused"
> +#else
> pcpu_free_alloc_info(ai);
> +#endif
> }
>
> #endif /* CONFIG_SMP */
Works for me, and thanks.
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Jesper Nilsson <jesper.nilsson@axis.com>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Tejun Heo <tj@kernel.org>, Guenter Roeck <linux@roeck-us.net>,
Christoph Lameter <cl@linux.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Mikael Starvik <starvik@axis.com>,
Jesper Nilsson <jespern@axis.com>,
linux-cris-kernel@axis.com
Subject: Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang)
Date: Tue, 28 Nov 2017 09:19:49 +0100 [thread overview]
Message-ID: <20171128081948.GE32368@axis.com> (raw)
In-Reply-To: <nycvar.YSQ.7.76.1711271534590.5925@knanqh.ubzr>
On Mon, Nov 27, 2017 at 03:51:04PM -0500, Nicolas Pitre wrote:
> On Mon, 27 Nov 2017, Tejun Heo wrote:
>
> > Hello,
> >
> > On Mon, Nov 27, 2017 at 03:31:52PM -0500, Nicolas Pitre wrote:
> > > So IMHO I don't think reverting the commit is the right thing to do.
> > > That commit is clearly not at fault here.
> >
> > It's not about the blame. We just want to avoid breaking boot in a
> > way which is difficult to debug. Once cris is fixed, we can re-apply
> > the patch.
>
> In that case I suggest the following instead. No point penalizing
> everyone for a single architecture's fault. And this will serve as a
> visible reminder to the cris people that they need to clean up.
>
> ----- >8
> Subject: percpu: hack to let the CRIS architecture to boot until they clean up
>
> Commit 438a506180 ("percpu: don't forget to free the temporary struct
> pcpu_alloc_info") uncovered a problem on the CRIS architecture where
> the bootmem allocator is initialized with virtual addresses. Given it
> has:
>
> #define __va(x) ((void *)((unsigned long)(x) | 0x80000000))
>
> then things just work out because the end result is the same whether you
> give this a physical or a virtual address.
>
> Untill you call memblock_free_early(__pa(address)) that is, because
> values from __pa() don't match with the virtual addresses stuffed in the
> bootmem allocator anymore.
>
> Avoid freeing the temporary pcpu_alloc_info memory on that architecture
> until they fix things up to let the kernel boot like it did before.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>
> diff --git a/mm/percpu.c b/mm/percpu.c
> index 79e3549cab..50e7fdf840 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -2719,7 +2719,11 @@ void __init setup_per_cpu_areas(void)
>
> if (pcpu_setup_first_chunk(ai, fc) < 0)
> panic("Failed to initialize percpu areas.");
> +#ifdef CONFIG_CRIS
> +#warning "the CRIS architecture has physical and virtual addresses confused"
> +#else
> pcpu_free_alloc_info(ai);
> +#endif
> }
>
> #endif /* CONFIG_SMP */
Works for me, and thanks.
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
next prev parent reply other threads:[~2017-11-28 8:19 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-03 20:57 [PATCH] mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info Nicolas Pitre
2017-10-03 20:57 ` Nicolas Pitre
2017-10-03 21:05 ` Tejun Heo
2017-10-03 21:05 ` Tejun Heo
2017-10-03 22:29 ` Nicolas Pitre
2017-10-03 22:29 ` Nicolas Pitre
2017-10-03 22:36 ` Tejun Heo
2017-10-03 22:36 ` Tejun Heo
2017-10-03 23:48 ` Dennis Zhou
2017-10-03 23:48 ` Dennis Zhou
2017-10-04 0:13 ` Nicolas Pitre
2017-10-04 0:13 ` Nicolas Pitre
2017-10-04 14:15 ` Tejun Heo
2017-10-04 14:15 ` Tejun Heo
2017-11-18 18:25 ` mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang) Guenter Roeck
2017-11-18 18:25 ` Guenter Roeck
2017-11-19 20:36 ` Nicolas Pitre
2017-11-19 20:36 ` Nicolas Pitre
2017-11-20 2:03 ` Guenter Roeck
2017-11-20 2:03 ` Guenter Roeck
2017-11-20 4:08 ` Nicolas Pitre
2017-11-20 4:08 ` Nicolas Pitre
2017-11-20 5:05 ` Guenter Roeck
2017-11-20 5:05 ` Guenter Roeck
2017-11-20 18:18 ` Nicolas Pitre
2017-11-20 18:18 ` Nicolas Pitre
2017-11-20 18:51 ` Guenter Roeck
2017-11-20 18:51 ` Guenter Roeck
2017-11-20 20:21 ` Nicolas Pitre
2017-11-20 20:21 ` Nicolas Pitre
2017-11-20 21:11 ` Guenter Roeck
2017-11-20 21:11 ` Guenter Roeck
2017-11-21 0:28 ` Nicolas Pitre
2017-11-21 0:28 ` Nicolas Pitre
2017-11-21 1:48 ` Guenter Roeck
2017-11-21 1:48 ` Guenter Roeck
2017-11-21 3:50 ` Nicolas Pitre
2017-11-21 3:50 ` Nicolas Pitre
2017-11-22 15:34 ` Jesper Nilsson
2017-11-22 15:34 ` Jesper Nilsson
2017-11-22 20:17 ` Nicolas Pitre
2017-11-22 20:17 ` Nicolas Pitre
2017-11-23 7:56 ` Jesper Nilsson
2017-11-23 7:56 ` Jesper Nilsson
2017-11-27 19:41 ` Tejun Heo
2017-11-27 19:41 ` Tejun Heo
2017-11-27 20:31 ` Nicolas Pitre
2017-11-27 20:31 ` Nicolas Pitre
2017-11-27 20:33 ` Tejun Heo
2017-11-27 20:33 ` Tejun Heo
2017-11-27 20:51 ` Nicolas Pitre
2017-11-27 20:51 ` Nicolas Pitre
2017-11-27 20:54 ` Tejun Heo
2017-11-27 20:54 ` Tejun Heo
2017-11-27 21:11 ` Guenter Roeck
2017-11-27 21:11 ` Guenter Roeck
2017-11-28 8:19 ` Jesper Nilsson [this message]
2017-11-28 8:19 ` Jesper Nilsson
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=20171128081948.GE32368@axis.com \
--to=jesper.nilsson@axis.com \
--cc=cl@linux.com \
--cc=jespern@axis.com \
--cc=linux-cris-kernel@axis.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@roeck-us.net \
--cc=nicolas.pitre@linaro.org \
--cc=starvik@axis.com \
--cc=tj@kernel.org \
/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.