Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
MIME-Version: 1.0
References: <VI1P193MB075256E076A09E5B2EF7A16F99D6A@VI1P193MB0752.EURP193.PROD.OUTLOOK.COM>
 <CA+fCnZfn0RnnhifNxctrUaLEptE=z9L=e3BY_8tRH2UXZWAO6Q@mail.gmail.com>
 <VI1P193MB07524EFBE97632D575A91EDB99A2A@VI1P193MB0752.EURP193.PROD.OUTLOOK.COM>
 <CACT4Y+a+xfzXBgqVz3Gxv4Ri1CqHTV1m=i=h4j5KWxsmdP+t5A@mail.gmail.com>
 <VI1P193MB075221DDE87BE09A4E7CBB1A99A1A@VI1P193MB0752.EURP193.PROD.OUTLOOK.COM>
 <CACT4Y+bxMKEVUhu-RDvOMcbah=iYCWdXFZDU0JN3D7OP26Q_Dw@mail.gmail.com>
 <VI1P193MB0752753CB059C9A4420C875799A1A@VI1P193MB0752.EURP193.PROD.OUTLOOK.COM>
 <CACT4Y+ZS5cz9wZgxLVo2EsGtt-tkFXkFPA6CGAA8Gy7+sEyDUQ@mail.gmail.com>
In-Reply-To: <CACT4Y+ZS5cz9wZgxLVo2EsGtt-tkFXkFPA6CGAA8Gy7+sEyDUQ@mail.gmail.com>
From:   Andrey Konovalov <andreyknvl@gmail.com>
Date:   Thu, 2 Nov 2023 15:58:45 +0100
Message-ID: <CA+fCnZdRWs=P4EgzC9sSDLfO=Bxbs9FyeOcqAiY8pzvMLUX=Aw@mail.gmail.com>
Subject: Re: [RFC] mm/kasan: Add Allocation, Free, Error timestamps to KASAN report
To:     Dmitry Vyukov <dvyukov@google.com>,
        Juntong Deng <juntong.deng@outlook.com>
Cc:     ryabinin.a.a@gmail.com, glider@google.com,
        vincenzo.frascino@arm.com, akpm@linux-foundation.org,
        kasan-dev@googlegroups.com, linux-mm@kvack.org,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-kernel-mentees@lists.linuxfoundation.org" 
        <linux-kernel-mentees@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Oct 31, 2023 at 10:46=E2=80=AFAM Dmitry Vyukov <dvyukov@google.com>=
 wrote:
>
> > >>> There is also an aspect of memory consumption. KASAN headers increa=
se
> > >>> the size of every heap object. So we tried to keep them as compact =
as
> > >>> possible. At some point CPU numbers and timestamps (IIRC) were alre=
ady
> > >>> part of the header, but we removed them to shrink the header to 16
> > >>> bytes.

> > Do you think it is worth using the extra bytes to record more
> > information? If this is a user-configurable feature.
>
> If it's user-configurable, then it is OK.

FWIW, Generic KASAN already stores the auxiliary stack handles in the
redzone, so the size of the redzone header is 24 bytes. Perhaps, we
should hide them under a config as well.

However, the increase of the redzone header size will only affect
small kmalloc allocations (<=3D 16 bytes, as kmalloc allocations are
aligned to the size of the object and the redzone is thus as big as
the object anyway) and small non-kmalloc slab allocations (<=3D 64
bytes, for which optimal_redzone returns 16). So I don't think adding
new fields to the redzone will increase the memory usage by much. But
this needs to be tested to make sure.