From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6058DC433FE for ; Fri, 22 Oct 2021 03:39:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D4B206103E for ; Fri, 22 Oct 2021 03:39:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D4B206103E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 5984894000F; Thu, 21 Oct 2021 23:39:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 547B7900002; Thu, 21 Oct 2021 23:39:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 45D7B94000F; Thu, 21 Oct 2021 23:39:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0220.hostedemail.com [216.40.44.220]) by kanga.kvack.org (Postfix) with ESMTP id 37966900002 for ; Thu, 21 Oct 2021 23:39:01 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D9CD68249980 for ; Fri, 22 Oct 2021 03:39:00 +0000 (UTC) X-FDA: 78722667240.01.F3536CF Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf07.hostedemail.com (Postfix) with ESMTP id 1ED8110000AC for ; Fri, 22 Oct 2021 03:39:05 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id DB75D610A4; Fri, 22 Oct 2021 03:38:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1634873939; bh=9TMOq2xQPIJH4U6BSsyCI1yOB5IvYFxcsxgSaPT7PFY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=nO0WJv17dRlACHIr/0GNZYQnsy6tXHHuwlZjcd6so1f3kCb3EvbBJHg4fkhQJg+7G O2kyXtKYneEt0ZLHZrHz4hrrKuI9UZqLBMfY3OoMRZg9Bz7xWV8Mpmk0UWDVOOFWX0 Cf7x8TnbV/CLoKsyzLHZvgX+bod9cAwaAcGHJMuI= Date: Thu, 21 Oct 2021 20:38:56 -0700 From: Andrew Morton To: Vlastimil Babka Cc: Jani Nikula , Naresh Kamboju , open list , Linux-Next Mailing List , linux-mm , dri-devel@lists.freedesktop.org, Marco Elver , Vijayanand Jitta , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Geert Uytterhoeven , Oliver Glitta , Imran Khan , lkft-triage@lists.linaro.org, Stephen Rothwell Subject: Re: [next] [dragonboard 410c] Unable to handle kernel paging request at virtual address 00000000007c4240 Message-Id: <20211021203856.1151daebedef7b180fdfec22@linux-foundation.org> In-Reply-To: <2a692365-cfa1-64f2-34e0-8aa5674dce5e@suse.cz> References: <80ab567d-74f3-e14b-3c30-e64bbd64b354@suse.cz> <87fssuojoc.fsf@intel.com> <2a692365-cfa1-64f2-34e0-8aa5674dce5e@suse.cz> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 1ED8110000AC X-Stat-Signature: f5sx9tpo5p779o6yhp83d9hii3tr51ot Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=nO0WJv17; dmarc=none; spf=pass (imf07.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-HE-Tag: 1634873945-667123 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 21 Oct 2021 19:51:20 +0200 Vlastimil Babka wrote: > >> Then we have to figure out how to order a fix between DRM and mmotm... > > > > That is the question! The problem exists only in the merge of the > > two. On current DRM side stack_depot_init() exists but it's __init and > > does not look safe to call multiple times. And obviously my changes > > don't exist at all in mmotm. > > > > I guess one (admittedly hackish) option is to first add a patch in > > drm-next (or drm-misc-next) that makes it safe to call > > stack_depot_init() multiple times in non-init context. It would be > > dropped in favour of your changes once the trees get merged together. > > > > Or is there some way for __drm_stack_depot_init() to detect whether it > > should call stack_depot_init() or not, i.e. whether your changes are > > there or not? > > Let's try the easiest approach first. AFAIK mmotm series is now split to > pre-next and post-next part It has been this way for many years! > and moving my patch > lib-stackdepot-allow-optional-init-and-stack_table-allocation-by-kvmalloc.patch > with the following fixup to the post-next part should solve this. Would that > work, Andrew? Thanks. For this reason. No probs, thanks. I merge up the post-linux-next parts late in the merge window. I do need to manually check that the prerequisites are in mainline, because sometimes the patches apply OK but don't make sense.