linux-kernel - Re: [next] [dragonboard 410c] Unable to handle kernel paging request at virtual address 00000000007c4240

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 21 Oct 2021 20:38:56 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Vlastimil Babka <vbabka@...e.cz>
Cc:     Jani Nikula <jani.nikula@...el.com>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        open list <linux-kernel@...r.kernel.org>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>, dri-devel@...ts.freedesktop.org,
        Marco Elver <elver@...gle.com>,
        Vijayanand Jitta <vjitta@...eaurora.org>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Andrey Ryabinin <ryabinin.a.a@...il.com>,
        Alexander Potapenko <glider@...gle.com>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Oliver Glitta <glittao@...il.com>,
        Imran Khan <imran.f.khan@...cle.com>,
        lkft-triage@...ts.linaro.org,
        Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [next] [dragonboard 410c] Unable to handle kernel paging
 request at virtual address 00000000007c4240

On Thu, 21 Oct 2021 19:51:20 +0200 Vlastimil Babka <vbabka@...e.cz> 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.