linux-kernel - Re: [PATCH v9 0/4] Implement MTE tag compression for swapped pages

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: <CAG_fn=WsYJmcABW3aXDyGrd04Sh2Hi7_2rReLc5xXPjQ4paScQ@mail.gmail.com>
Date:   Wed, 13 Dec 2023 15:01:17 +0100
From:   Alexander Potapenko <glider@...gle.com>
To:     Will Deacon <will@...nel.org>
Cc:     catalin.marinas@....com, pcc@...gle.com, andreyknvl@...il.com,
        andriy.shevchenko@...ux.intel.com, aleksander.lobakin@...el.com,
        linux@...musvillemoes.dk, yury.norov@...il.com,
        alexandru.elisei@....com, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, eugenis@...gle.com,
        syednwaris@...il.com, william.gray@...aro.org
Subject: Re: [PATCH v9 0/4] Implement MTE tag compression for swapped pages

On Wed, Dec 13, 2023 at 1:31 PM Will Deacon <will@...nel.org> wrote:
>
> On Mon, Nov 13, 2023 at 11:52:29AM +0100, Alexander Potapenko wrote:
> > Currently, when MTE pages are swapped out, the tags are kept in the
> > memory, occupying PAGE_SIZE/32 bytes per page. This is especially
> > problematic for devices that use zram-backed in-memory swap, because
> > tags stored uncompressed in the heap effectively reduce the available
> > amount of swap memory.
> >
> > The RLE-based algorithm suggested by Evgenii Stepanov and implemented in
> > this patch series is able to efficiently compress fixed-size tag buffers,
> > resulting in practical compression ratio of 2x. In many cases it is
> > possible to store the compressed data in 63-bit Xarray values, resulting
> > in no extra memory allocations.
> >
> > This patch series depends on "lib/bitmap: add bitmap_{read,write}()"
> > (https://lore.kernel.org/linux-arm-kernel/20231030153210.139512-1-glider@google.com/T/)
> > that is mailed separately.
>
> That's a shame, because it means I can't apply the series as-is:
>

Uh-oh, sorry about that. There was another series depending on the
bitmap_read/bitmap_write API, and I thought mailing those patches
separately would speed things up.
But in fact Yury requested them to have at least one user, so now that
the MTE series is also acked I'd better bring everything back
together.
Let me send out another version.

>
> arch/arm64/mm/mtecomp.c: In function ‘mte_bitmap_write’:
> arch/arm64/mm/mtecomp.c:105:2: error: implicit declaration of function ‘bitmap_write’; did you mean ‘bitmap_free’? [-Werror=implicit-function-declaration]
>   105 |  bitmap_write(bitmap, value, *pos, bits);
>       |  ^~~~~~~~~~~~
>       |  bitmap_free
> arch/arm64/mm/mtecomp.c: In function ‘mte_bitmap_read’:
> arch/arm64/mm/mtecomp.c:198:9: error: implicit declaration of function ‘bitmap_read’; did you mean ‘bitmap_remap’? [-Werror=implicit-function-declaration]
>   198 |  return bitmap_read(bitmap, start, bits);
>       |         ^~~~~~~~~~~
>       |         bitmap_remap
> cc1: some warnings being treated as errors
> make[5]: *** [scripts/Makefile.build:243: arch/arm64/mm/mtecomp.o] Error 1
>
>
> Do you really have such a hard dependency on those new bitmap ops?

Having them in bitmap.h seems natural - this way they can be reused by
other people.