linux-kernel - Re: [PATCH] mm/zswap: Replace kmap_atomic() with kmap_local

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]

Message-ID: <ZWX0h9JEAuw4qGyV@casper.infradead.org>
Date:   Tue, 28 Nov 2023 14:09:11 +0000
From:   Matthew Wilcox <willy@...radead.org>
To:     Chris Li <chrisl@...nel.org>
Cc:     "Fabio M. De Francesco" <fabio.maria.de.francesco@...ux.intel.com>,
        Seth Jennings <sjenning@...hat.com>,
        Dan Streetman <ddstreet@...e.org>,
        Vitaly Wool <vitaly.wool@...sulko.com>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Ira Weiny <ira.weiny@...el.com>,
        Nhat Pham <nphamcs@...il.com>
Subject: Re: [PATCH] mm/zswap: Replace kmap_atomic() with kmap_local_page()

On Mon, Nov 27, 2023 at 12:16:56PM -0800, Chris Li wrote:
> Hi Fabio,
> 
> On Mon, Nov 27, 2023 at 8:01 AM Fabio M. De Francesco
> <fabio.maria.de.francesco@...ux.intel.com> wrote:
> >
> > kmap_atomic() has been deprecated in favor of kmap_local_page().
> >
> > Therefore, replace kmap_atomic() with kmap_local_page() in
> > zswap.c.
> >
> > kmap_atomic() is implemented like a kmap_local_page() which also
> > disables page-faults and preemption (the latter only in !PREEMPT_RT
> > kernels). The kernel virtual addresses returned by these two API are
> > only valid in the context of the callers (i.e., they cannot be handed to
> > other threads).
> >
> > With kmap_local_page() the mappings are per thread and CPU local like
> > in kmap_atomic(); however, they can handle page-faults and can be called
> > from any context (including interrupts). The tasks that call
> > kmap_local_page() can be preempted and, when they are scheduled to run
> > again, the kernel virtual addresses are restored and are still valid.
> 
> As far as I can tell, the kmap_atomic() is the same as
> kmap_local_page() with the following additional code before calling to
> "__kmap_local_page_prot(page, prot)", which is common between these
> two functions.
> 
>         if (IS_ENABLED(CONFIG_PREEMPT_RT))
>                 migrate_disable();
>         else
>                 preempt_disable();
> 
>         pagefault_disable();
> 
> >From the performance perspective, kmap_local_page() does less so it
> has some performance gain. I am trying to think would it have another
> unwanted side effect of enabling interrupt and page fault while zswap
> decompressing a page.
> The decompression should not generate page fault. The interrupt
> enabling might introduce extra latency, but most of the page fault was
> having interrupt enabled anyway. The time spent in decompression is
> relatively small compared to the whole duration of the page fault. So
> the interrupt enabling during those short windows should be fine.
> "Should" is the famous last word.

Interrupts are enabled with kmap_atomic() too.  The difference is
whether we can be preempted by a higher-priority process.