[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87y2ji1d17.fsf@nanos.tec.linutronix.de>
Date: Tue, 03 Nov 2020 20:00:20 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Paul McKenney <paulmck@...nel.org>,
Christoph Hellwig <hch@....de>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux-MM <linux-mm@...ck.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Benjamin LaHaise <bcrl@...ck.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-aio@...ck.org, Chris Mason <clm@...com>,
Josef Bacik <josef@...icpanda.com>,
David Sterba <dsterba@...e.com>,
linux-btrfs <linux-btrfs@...r.kernel.org>,
the arch/x86 maintainers <x86@...nel.org>,
Vineet Gupta <vgupta@...opsys.com>,
"open list\:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@...ts.infradead.org>,
Russell King <linux@...linux.org.uk>,
Arnd Bergmann <arnd@...db.de>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
linux-csky@...r.kernel.org, Michal Simek <monstr@...str.eu>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
linux-mips@...r.kernel.org, Nick Hu <nickhu@...estech.com>,
Greentime Hu <green.hu@...il.com>,
Vincent Chen <deanbo422@...il.com>,
Michael Ellerman <mpe@...erman.id.au>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
"David S. Miller" <davem@...emloft.net>,
linux-sparc <sparclinux@...r.kernel.org>,
Chris Zankel <chris@...kel.net>,
Max Filippov <jcmvbkbc@...il.com>,
linux-xtensa@...ux-xtensa.org, Ingo Molnar <mingo@...nel.org>,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Christian Koenig <christian.koenig@....com>,
Huang Rui <ray.huang@....com>, David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
dri-devel <dri-devel@...ts.freedesktop.org>,
VMware Graphics <linux-graphics-maintainer@...are.com>,
Roland Scheidegger <sroland@...are.com>,
Dave Airlie <airlied@...hat.com>,
Gerd Hoffmann <kraxel@...hat.com>,
virtualization@...ts.linux-foundation.org,
spice-devel@...ts.freedesktop.org, Ben Skeggs <bskeggs@...hat.com>,
nouveau@...ts.freedesktop.org,
Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
intel-gfx <intel-gfx@...ts.freedesktop.org>
Subject: Re: [patch V3 22/37] highmem: High implementation details and document API
On Tue, Nov 03 2020 at 09:48, Linus Torvalds wrote:
> I have no complaints about the patch, but it strikes me that if people
> want to actually have much better debug coverage, this is where it
> should be (I like the "every other address" thing too, don't get me
> wrong).
>
> In particular, instead of these PageHighMem(page) tests, I think
> something like this would be better:
>
> #ifdef CONFIG_DEBUG_HIGHMEM
> #define page_use_kmap(page) ((page),1)
> #else
> #define page_use_kmap(page) PageHighMem(page)
> #endif
>
> adn then replace those "if (!PageHighMem(page))" tests with "if
> (!page_use_kmap())" instead.
>
> IOW, in debug mode, it would _always_ remap the page, whether it's
> highmem or not. That would really stress the highmem code and find any
> fragilities.
Yes, that makes a lot of sense. We just have to avoid that for the
architectures with aliasing issues.
> Anyway, this is all sepatrate from the series, which still looks fine
> to me. Just a reaction to seeing the patch, and Thomas' earlier
> mention that the highmem debugging doesn't actually do much.
Right, forcing it for both kmap and kmap_local is straight forward. I'll
cook a patch on top for that.
Thanks,
tglx
Powered by blists - more mailing lists