From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751619AbdK1ITz (ORCPT ); Tue, 28 Nov 2017 03:19:55 -0500 Received: from bastet.se.axis.com ([195.60.68.11]:54047 "EHLO bastet.se.axis.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750829AbdK1ITy (ORCPT ); Tue, 28 Nov 2017 03:19:54 -0500 Date: Tue, 28 Nov 2017 09:19:49 +0100 From: Jesper Nilsson To: Nicolas Pitre Cc: Tejun Heo , Guenter Roeck , Christoph Lameter , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mikael Starvik , Jesper Nilsson , linux-cris-kernel@axis.com Subject: Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang) Message-ID: <20171128081948.GE32368@axis.com> References: <20171118182542.GA23928@roeck-us.net> <20171127194105.GM983427@devbig577.frc2.facebook.com> <20171127203335.GQ983427@devbig577.frc2.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-TM-AS-GCONF: 00 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > 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