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 DFDE8CFA749 for ; Fri, 4 Oct 2024 06:45:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EC9216B0417; Fri, 4 Oct 2024 02:45:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E52416B0418; Fri, 4 Oct 2024 02:45:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CCBEB6B041A; Fri, 4 Oct 2024 02:45:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A54AA6B0417 for ; Fri, 4 Oct 2024 02:45:36 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 42954120D8D for ; Fri, 4 Oct 2024 06:45:36 +0000 (UTC) X-FDA: 82634983872.12.A808F98 Received: from mail-oa1-f43.google.com (mail-oa1-f43.google.com [209.85.160.43]) by imf08.hostedemail.com (Postfix) with ESMTP id 812EC160014 for ; Fri, 4 Oct 2024 06:45:34 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=33RHt4f2; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of elver@google.com designates 209.85.160.43 as permitted sender) smtp.mailfrom=elver@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728024238; a=rsa-sha256; cv=none; b=lE5eqLxU5ZD816ytFtXvO7N1azPYEKa+vCyha1ow3r7BaQakRkUvMIFJi4HpTZXIgMwxcx x8yJNVaGg0OerXCTXwjY/Kwi7Qc4TFJaTaoy6g93NwG4a2Grh6vqxqkcuXx950si8OkU1X htYnj1FV3GhwJ4TNrqVykxgLz90Vk9E= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=33RHt4f2; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of elver@google.com designates 209.85.160.43 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728024238; 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=mL2W2tJrDMQeo1z+yDtY45KIaV/M8fHOjbAIS4+Vjz4=; b=gPpyyqMByKiJXx+en4QBJURWshD+LKHT5TPP33s69fKBONKbgtUqaKBdAf9vmp5VvRU8Vs hX1CZHdZpiLmjjakTa3gzHyrzZjmQUovq+gCxSW9QKtWrSepAR1JoVfdhRJnQjrnTKeq7t VFoc1qjP2HP+6KLqFEb8UiL7TPFEA0o= Received: by mail-oa1-f43.google.com with SMTP id 586e51a60fabf-2870bd5e1f7so785499fac.3 for ; Thu, 03 Oct 2024 23:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1728024333; x=1728629133; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mL2W2tJrDMQeo1z+yDtY45KIaV/M8fHOjbAIS4+Vjz4=; b=33RHt4f2XHQ5GqYskKdHL+uNbT/rtIVeXiQu/5yZ4JDNl7ijJi1UdMDJgZIAW7rux2 mLmAX+vGaHuARLlTBg2Y5/QxRuqR5ywlQSNucJBfCt0QrwSF2uc0bYm3h+LDBINFDWqd rRcove53XXWqISkfUsMZ30ibpVvbAEkZcPTbuIg9+f2Qh976s7xXjBbdMmlS7txG33lH zum3KYQ5mHh1/orerTDj7alVYinHIKGhpUM6/BU+o9twLwuvSnKWHUK793AtCUDutpDP d0FNgOQjwnlt/2+ud4vJRoOjNZMAkDzCFMaiv5hMKXv+kwP+Yv7lsQgNy7qXYffGWgrN wCWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728024333; x=1728629133; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mL2W2tJrDMQeo1z+yDtY45KIaV/M8fHOjbAIS4+Vjz4=; b=HHYPzPkagV//fexlaqAqbTpq/SQSk8IBE8l3B+2qS9LAO/mzxzo6hbsHVctn14RANT R+iuufYTtC34G+2kI0gBJlqqfuzF5v8KFTnXFsf9GV49wv4IOVtfeDzYoVQgEgbK+u1D MqPWcPPzLerx315/DGY/OV/RuhG+nqBQ8pGxypvsMRvUenQkNLv9NfJZMrrDxZZhGR52 a1HuqQiDBJfZDvwLm7Q9tCvR8X42wAHFy1N6Ut0MGrFWLaAX+3ZcJNLcdjSdyeIb9Fn1 WwXDcazCzKD4f2npqCpscR2SSKzrrjbbGd6voWVhC53DN+OQM49TgaLZPgMHCXiOzqYx GNrw== X-Forwarded-Encrypted: i=1; AJvYcCX2M85hFEQPV7Z8gJX7aJMynC0RlNppaJA5aGaFTto6MH9GsCLPjH728foNgmEzLgudJ6G+iEuTRg==@kvack.org X-Gm-Message-State: AOJu0YyNk/n45qekr1vsYh2krjG4vFFkwIIt/vT1tSEvSx1iEzD0JgaH bsM+MG2sxElHUJKUaSx4E22SMBeMtjaiclzrbzFJLdbwLGBgWq0qE833R4kxONCY65DcPwKWQiv HN0DuGvzj/GuNxCQVGFkTTbgf/3JN4TzSoNrD X-Google-Smtp-Source: AGHT+IH4Qhk7cAgNm6q1FriBC0eeLIQyCLkkZYNvfP5aKV2GbglNqvRSEqLE9XFLJqJynYRgllNS+XWQ5R7JRKSBfyU= X-Received: by 2002:a05:6870:364e:b0:278:14b6:a8f7 with SMTP id 586e51a60fabf-287c20219d4mr1335084fac.42.1728024333180; Thu, 03 Oct 2024 23:45:33 -0700 (PDT) MIME-Version: 1.0 References: <20240911064535.557650-1-feng.tang@intel.com> In-Reply-To: From: Marco Elver Date: Fri, 4 Oct 2024 08:44:54 +0200 Message-ID: Subject: Re: [PATCH v2 0/5] mm/slub: Improve data handling of krealloc() when orig_size is enabled To: Vlastimil Babka Cc: Feng Tang , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Andrey Konovalov , Shuah Khan , David Gow , Danilo Krummrich , Alexander Potapenko , Andrey Ryabinin , Dmitry Vyukov , Vincenzo Frascino , linux-mm@kvack.org, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, Eric Dumazet Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 812EC160014 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 5m5u1agmn9oazjs3g5qag3u3h1hxahfp X-HE-Tag: 1728024334-307781 X-HE-Meta: U2FsdGVkX1/SZiB0y7Z3PBQDBMQJEhqmcyPEAozeph+X5cXECL2CH0YBNBJSInPdB4jtB9ws4Yn3v6uLHKwc6b13kcysPYGkfgOqtHZYQgOFLvunRjCDYqV403zQcjCPa9WovY9OOLR/jpkuAX6exj3VnrlQrLGor+9apKzQ6BvFLthrsNffbbB2N0IwpDW9ehXzO2CUHpnry2rhulaXTioegCuoAvNhbMW1v2SZujPNBgksl4D5eHD4td+8+azt2B0JJY4P9yQqIGnMSHhzjWacUWIV13oWMcxnXXsUNDqcdZr2t9LaMRd5RTJkc8k0gNFyCukEINUsdW9KwkQ2V3JYFtL4UHA5ZKVWBgN0zua18/ZAWxMdTmiuNTPZkVwTnhy+BBWBzimPxVTRYYkxHKgvl5xrhvhcUR+WdoSS/aMRnd1iLjyY2G1qC1Lo9P0Hvv7q0IhgUpaGvB5dm/EfWeEMVJvEn3utRd/0Hcx5HpicZPkFqX8BlPNg3GmUjUAcSWneqYn7X2wH177BS5SRGBhp8tTgTYLF4cFhSm0o4vgvtNFQyQVUnMWczWVgKfcTPRLfUGdFOxE2mv3ifFGtcj1gOd0Rt7GOMsdFXrmQLb1BSNGiA5xMuDucZ59FWTrYouIogE/qUuG6J4sKrpBuYEhDfeO1AfgYFbT6KMJ+9zRuxpTDWxdYZEOUzq+lJKQQoTY2toC1bdyVqwW3GKDnmL+KDWnBmQ+jaJZKyb40YxpKbyhlfRa6j7syg2SO/zeN7sR3WnJEi6iaGKthftZrLLBpJFPdNXtQJKk5KhMvuZl6BvFEFoycqWAkTg3Jc5lngaWD90eqCMYQPDenZxej1Wqp7pXoxrL7TcQMl+o3aHSGcyMuSfolwo+rNS85jsvDQkKqTLmA/RY++2MXdzOgLD7t2TifZrilirk5dJ1yQTIMKOWfVaOX1pzAlbAHiHCvitWm1msgyzttUvtTkcM 9OQ1ftqp msv1MdCk29uNbw9hNNvDctoC7uvSNJ49797JYJEiWmzVGGxnY8rnFsZHmV4NcObxB7A0PlKnYPxZY1FDTBA2YnIxy7kFHeTVGlO4/Q2MrIAFMR6bsplDVdobVFk+j5/EZmQLjzW5lOg6dWKyChAqM4j/1lCAV5lBN0mC5RZNkznFj87R6AmeOXu5a5XfE0YZ35+psSTLCMK5K+4ztoXvB+V5yK92yet6d22pwnFZIqIgTyN9bNi40kkafviPgzfcoqKBw1zRJnItzDHLW8/4m6tfqwRoUpFMWF5VdHQ21xpyMKap8caNrL77vw71ZAhURytJgDVJmJR87wRQke3DpzPDg4pbho+DfTEp5hlYO1US2odc= 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: List-Subscribe: List-Unsubscribe: On Wed, 2 Oct 2024 at 12:42, Vlastimil Babka wrote: > > On 9/11/24 08:45, Feng Tang wrote: > > Danilo Krummrich's patch [1] raised one problem about krealloc() that > > its caller doesn't pass the old request size, say the object is 64 > > bytes kmalloc one, but caller originally only requested 48 bytes. Then > > when krealloc() shrinks or grows in the same object, or allocate a new > > bigger object, it lacks this 'original size' information to do accurate > > data preserving or zeroing (when __GFP_ZERO is set). > > > > Thus with slub debug redzone and object tracking enabled, parts of the > > object after krealloc() might contain redzone data instead of zeroes, > > which is violating the __GFP_ZERO guarantees. Good thing is in this > > case, kmalloc caches do have this 'orig_size' feature, which could be > > used to improve the situation here. > > > > To make the 'orig_size' accurate, we adjust some kasan/slub meta data > > handling. Also add a slub kunit test case for krealloc(). > > > > This patchset has dependency over patches in both -mm tree and -slab > > trees, so it is written based on linux-next tree '20240910' version. > > > > [1]. https://lore.kernel.org/lkml/20240812223707.32049-1-dakr@kernel.org/ > > Thanks, added to slab/for-next This series just hit -next, and we're seeing several "KFENCE: memory corruption ...". Here's one: https://lore.kernel.org/all/66ff8bf6.050a0220.49194.0453.GAE@google.com/ One more (no link): > ================================================================== > BUG: KFENCE: memory corruption in xfs_iext_destroy_node+0xab/0x670 fs/xfs/libxfs/xfs_iext_tree.c:1051 > > Corrupted memory at 0xffff88823bf5a0d0 [ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ] (in kfence-#172): > xfs_iext_destroy_node+0xab/0x670 fs/xfs/libxfs/xfs_iext_tree.c:1051 > xfs_iext_destroy+0x66/0x100 fs/xfs/libxfs/xfs_iext_tree.c:1062 > xfs_inode_free_callback+0x91/0x1d0 fs/xfs/xfs_icache.c:145 > rcu_do_batch kernel/rcu/tree.c:2567 [inline] [...] > > kfence-#172: 0xffff88823bf5a000-0xffff88823bf5a0cf, size=208, cache=kmalloc-256 > > allocated by task 5494 on cpu 0 at 101.266046s (0.409225s ago): > __do_krealloc mm/slub.c:4784 [inline] > krealloc_noprof+0xd6/0x2e0 mm/slub.c:4838 > xfs_iext_realloc_root fs/xfs/libxfs/xfs_iext_tree.c:613 [inline] [...] > > freed by task 16 on cpu 0 at 101.573936s (0.186416s ago): > xfs_iext_destroy_node+0xab/0x670 fs/xfs/libxfs/xfs_iext_tree.c:1051 > xfs_iext_destroy+0x66/0x100 fs/xfs/libxfs/xfs_iext_tree.c:1062 > xfs_inode_free_callback+0x91/0x1d0 fs/xfs/xfs_icache.c:145 [...] > > CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc1-next-20241003-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 > ================================================================== Unfortunately there's no reproducer yet it seems. Unless it's immediately obvious to say what's wrong, is it possible to take this series out of -next to confirm this series is causing the memory corruptions? Syzbot should then stop finding these crashes. Thanks, -- Marco