From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9D299C19F2B for ; Tue, 2 Aug 2022 07:06:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2812D6B0071; Tue, 2 Aug 2022 03:06:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 230BC8E0001; Tue, 2 Aug 2022 03:06:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F8F56B0073; Tue, 2 Aug 2022 03:06:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id F31A56B0071 for ; Tue, 2 Aug 2022 03:06:54 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B32DEA0DEA for ; Tue, 2 Aug 2022 07:06:54 +0000 (UTC) X-FDA: 79753770348.27.0C14032 Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by imf13.hostedemail.com (Postfix) with ESMTP id 5BA1920113 for ; Tue, 2 Aug 2022 07:06:54 +0000 (UTC) Received: by mail-lj1-f182.google.com with SMTP id r14so14693770ljp.2 for ; Tue, 02 Aug 2022 00:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=6vKqhsUzixhYOBMktOXVTY43Yh0tm2BA/2sZ3OGVl9Q=; b=gHKO1or5+vev0QVbmdNrUU3OWjemyPo5ATbnfrhdrg+z5WzYXVlmiVbesXNNH9cm6J oNQ0nQJ91NrjdrfG4mTjQZfZtTdkI7nb9GgSwltsvT5oz8ze9yT/3DmZ4xieCeJXG9CK OvNJ1ftbi7solG2Uvq2i/Ri3u9Fg4PMurXlf8KJjTxy4s82f1tEX5aNn0CMyLa2mLmdF 2tbopaFMnfsa8CrGZCURw14BDYsYhJfID/wJdg8PK93GnS6VtfumI3FynONlX8rsbVkU mws4og1LhI8BgJO53mu0BDE5wXmqJhgy922KcysQlLcDfVXw8fXiFWgac9U74xKr+Tqi 5xnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=6vKqhsUzixhYOBMktOXVTY43Yh0tm2BA/2sZ3OGVl9Q=; b=pYEy4F8V8GjpqcTCLd/q9UBIkVCuuPzsRlJuKljD/FJCeVSu8SkjtcBZNGX9pblgxj M4UkReSopcblQCY2ivVtbUaW31Z/GM0I4E2voGGQkbJ/9L5aLG9a99LlDi9s/ZjhpBIr cypVNK/eMtQzpYgOYxZ5CL1UoBuas7G/U6I+G7Y1AXp+UxKG4uKiQtWFvZJotJSpN1ki ddULWzZ1hAy9wYoV3fHjEmf+v2gEVb03YI0OZqStAP4mLwDaowYy5WH22c7/ZSFtz6rR irRz7w1XhC/VwiWxk6If92SHxyx7lfd4BQxo79HE3SQ9IVNOc6SLcRj94E6m7Fovlfk+ dG7g== X-Gm-Message-State: AJIora9OBkoWiiH6oG6Ehb0SF2+NYZw5++MRGQgtvSzaQKQ0ZhC38qBn FTX6Fqc6E3R9vF/HE5B5Jl81mjGN1Qa+kY42DHZC0A== X-Google-Smtp-Source: AGRyM1uu3u/qpdrNyzjyshWfnEcQZbwqrLkjhmgmxi3K7JdPl+gexE02YnhZrUSSE34pQK8U85LL+xKybJ55P/G/FpQ= X-Received: by 2002:a2e:bd0e:0:b0:25a:88b3:9af6 with SMTP id n14-20020a2ebd0e000000b0025a88b39af6mr6507869ljq.363.1659424012668; Tue, 02 Aug 2022 00:06:52 -0700 (PDT) MIME-Version: 1.0 References: <20220727071042.8796-4-feng.tang@intel.com> <0e545088-d140-4c84-bbb2-a3be669740b2@suse.cz> In-Reply-To: From: Dmitry Vyukov Date: Tue, 2 Aug 2022 09:06:41 +0200 Message-ID: Subject: Re: [mm/slub] 3616799128: BUG_kmalloc-#(Not_tainted):kmalloc_Redzone_overwritten To: Feng Tang Cc: Vlastimil Babka , "Sang, Oliver" , lkp , LKML , "linux-mm@kvack.org" , "lkp@lists.01.org" , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "Hansen, Dave" , Robin Murphy , John Garry , Kefeng Wang , Andrey Konovalov , Andrey Ryabinin , Alexander Potapenko , "kasan-dev@googlegroups.com" Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=gHKO1or5; spf=pass (imf13.hostedemail.com: domain of dvyukov@google.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=dvyukov@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1659424014; a=rsa-sha256; cv=none; b=MQIQRn6zY6qi0jaeyh0bl/V/UHAoWw6siZqztS48C2j0Hn3MHXkE9aLLaKyrT4g5qpdOR0 0h4YWluV4RZJcX5B6bEy8EYn8sJyJIhG1h6anWktu3srG6E0QOeiS7FgvL9LrWdN6/Tlm2 FECOoxdfHOjModG1udpy5ScXqQjW9Fo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659424014; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6vKqhsUzixhYOBMktOXVTY43Yh0tm2BA/2sZ3OGVl9Q=; b=hyUiKKjSWsywpfQA6gYJttNGVe91u9KHTVo9ISgRImqQ3giFHSxCuv84VJYz/5ZxRazf8H mKBZu40qLyN7woQ29ReMqy5vvPuB3Ma1YetHi4iQdxXkahJ9Nc/4aWRkahlPHxlxtotRqX imA4sSkVTv3MT0qVZJeczznbYGIoq+k= Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=gHKO1or5; spf=pass (imf13.hostedemail.com: domain of dvyukov@google.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=dvyukov@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: 1gbc79nkemkp4qtpb8rqo1eenqdh9wax X-Rspamd-Queue-Id: 5BA1920113 X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1659424014-793175 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 2 Aug 2022 at 08:55, Feng Tang wrote: > > On Mon, Aug 01, 2022 at 10:23:23PM +0800, Vlastimil Babka wrote: > > On 8/1/22 08:21, Feng Tang wrote: > [snip] > > > Cc kansan mail list. > > > > > > This is really related with KASAN debug, that in free path, some > > > kmalloc redzone ([orig_size+1, object_size]) area is written by > > > kasan to save free meta info. > > > > > > The callstack is: > > > > > > kfree > > > slab_free > > > slab_free_freelist_hook > > > slab_free_hook > > > __kasan_slab_free > > > ____kasan_slab_free > > > kasan_set_free_info > > > kasan_set_track > > > > > > And this issue only happens with "kmalloc-16" slab. Kasan has 2 > > > tracks: alloc_track and free_track, for x86_64 test platform, most > > > of the slabs will reserve space for alloc_track, and reuse the > > > 'object' area for free_track. The kasan free_track is 16 bytes > > > large, that it will occupy the whole 'kmalloc-16's object area, > > > so when kmalloc-redzone is enabled by this patch, the 'overwritten' > > > error is triggered. > > > > > > But it won't hurt other kmalloc slabs, as kasan's free meta won't > > > conflict with kmalloc-redzone which stay in the latter part of > > > kmalloc area. > > > > > > So the solution I can think of is: > > > * skip the kmalloc-redzone for kmalloc-16 only, or > > > * skip kmalloc-redzone if kasan is enabled, or > > > * let kasan reserve the free meta (16 bytes) outside of object > > > just like for alloc meta > > > > Maybe we could add some hack that if both kasan and SLAB_STORE_USER is > > enabled, we bump the stored orig_size from <16 to 16? Similar to what > > __ksize() does. > > How about the following patch: > > --- > diff --git a/mm/slub.c b/mm/slub.c > index added2653bb0..33bbac2afaef 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -830,6 +830,16 @@ static inline void set_orig_size(struct kmem_cache *s, > if (!slub_debug_orig_size(s)) > return; > > +#ifdef CONFIG_KASAN > + /* > + * When kasan is enabled, it could save its free meta data in the > + * start part of object area, so skip the kmalloc redzone check > + * for small kmalloc slabs to avoid the data conflict. > + */ > + if (s->object_size <= 32) > + orig_size = s->object_size; > +#endif > + > p += get_info_end(s); > p += sizeof(struct track) * 2; > > I extend the size to 32 for potential's kasan meta data size increase. > This is tested locally, if people are OK with it, I can ask for 0Day's > help to verify this. Where is set_orig_size() function defined? Don't see it upstream nor in linux-next. This looks fine but my only concern is that this should not increase memory consumption when slub debug tracking is not enabled, which should be the main operation mode when KASAN is enabled. But I can't figure this out w/o context. > Thanks, > Feng > > > > > > I don't have way to test kasan's SW/HW tag configuration, which > > > is only enabled on arm64 now. And I don't know if there will > > > also be some conflict. > > > > > > Thanks, > > > Feng > > > > > > > -- > You received this message because you are subscribed to the Google Groups "kasan-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/YujKCxu2lJJFm73P%40feng-skl.