Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 25 May 2022 11:34:16 +0200
From:   Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To:     Ira Weiny <ira.weiny@intel.com>
Cc:     "Fabio M. De Francesco" <fmdefrancesco@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        "Matthew Wilcox (Oracle)" <willy@infradead.org>,
        Will Deacon <will@kernel.org>,
        Peter Collingbourne <pcc@google.com>,
        Vlastimil Babka <vbabka@suse.cz>, linux-kernel@vger.kernel.org,
        Jonathan Corbet <corbet@lwn.net>, linux-doc@vger.kernel.org,
        outreachy@lists.linux.dev,
        "Acked-by : Mike Rapoport" <rppt@linux.ibm.com>
Subject: Re: [PATCH v2 1/4] mm/highmem: Fix kernel-doc warnings in highmem*.h
Message-ID: <Yo34GGK62yVkPzZy@linutronix.de>
References: <20220425162400.11334-1-fmdefrancesco@gmail.com>
 <20220425162400.11334-2-fmdefrancesco@gmail.com>
 <YmeYzKT8Ikq5SfdE@linutronix.de>
 <YmwLXvtSgl2BA2mC@iweiny-desk3>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <YmwLXvtSgl2BA2mC@iweiny-desk3>
Precedence: bulk

On 2022-04-29 08:59:26 [-0700], Ira Weiny wrote:
> I think some discussion needs to happen around this API.
> 
> Highmem has little use.  I don't think anyone disagrees with Linus there.
> (Although I think there are still a few users out there.)

arm32 is still built and they have sometimes 1 - 2 GiB of memory.

> kmap may be a poor name for an API without the highmem functionality.  But
> perhaps not.  One could interpret it to mean simply getting the kernel mapping
> of the page rather than creating one.  After all that is what 64bit has done
> all along.
> 
> This interpretation helps when you consider features which attempt to layer the
> direct map with additional protections like PKS.[1]  Those protections mean
> that a simple page_address() is insufficient to access the direct map.
> 
> As far as calling kmap() and kmap_atomic() deprecated I'm ok with that if the
> community is.
> 
> The current kmap() call sites need work and Fabio's work on auditing them is
> extremely helpful.  That said, if we officially deprecate kmap_atomic() then
> those sites could be added to the list for rework.

Maybe I oversee something obvious but there is no problem with removing
kmap_atomic*() and keeping only kmap_local*() around, is there?
I never intended to deprecated kmap(), only kmap_atomic*() in favour of
kmap_local*().

> Ira

Sebastian