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 91262C02194 for ; Fri, 7 Feb 2025 03:43:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D4F7E6B007B; Thu, 6 Feb 2025 22:43:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CFF1A6B0082; Thu, 6 Feb 2025 22:43:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B9FD76B0083; Thu, 6 Feb 2025 22:43:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 9C21B6B007B for ; Thu, 6 Feb 2025 22:43:14 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 47FB11A15C7 for ; Fri, 7 Feb 2025 03:43:14 +0000 (UTC) X-FDA: 83091753108.05.CB5F66D Received: from mailout4.samsung.com (mailout4.samsung.com [203.254.224.34]) by imf05.hostedemail.com (Postfix) with ESMTP id D3B0110000D for ; Fri, 7 Feb 2025 03:43:10 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=M8s8AMSm; dmarc=pass (policy=none) header.from=samsung.com; spf=pass (imf05.hostedemail.com: domain of hyesoo.yu@samsung.com designates 203.254.224.34 as permitted sender) smtp.mailfrom=hyesoo.yu@samsung.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738899792; a=rsa-sha256; cv=none; b=rwOZaWHGX6UMp6eNca2hU8L/+frbyTztPoGMuKKxKF/vGOKD8LRjLllXROq0tSh3rpJAGo 0LSeWEG27qi2HGuuJBIWlzG9gm1NLVmckFqUHoPG1Vn3l03jEkQZWBsHTOZ6hsacRhGcmA r2bNipN/XdUGzc+CH8K+itzTzXN5q8c= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=M8s8AMSm; dmarc=pass (policy=none) header.from=samsung.com; spf=pass (imf05.hostedemail.com: domain of hyesoo.yu@samsung.com designates 203.254.224.34 as permitted sender) smtp.mailfrom=hyesoo.yu@samsung.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738899792; 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=XzP4NKg91izVt81d0t10hKnI2+gFIJePspVeYoHJZY0=; b=cbrPJ71KJRbYM7UlvjKRyKzXJKqIl/tz4PMoTPFb0Rutoo2Qcdf+2QUeE2JsGeC1ou+ecr Cs2PfA/4uPfTdBJuXLOE5j8tTxzLQ2JKDemT89aycvnpZqrCIhMXhEgbE2Gd1Z1OnLZt5W ZPyHWMAsGsLsOZWQH625degbW96V6GM= Received: from epcas2p1.samsung.com (unknown [182.195.41.53]) by mailout4.samsung.com (KnoxPortal) with ESMTP id 20250207034307epoutp04eaad9c8478a8c7353fb441336baac7e6~h0CTSQ8h83073830738epoutp04V for ; Fri, 7 Feb 2025 03:43:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout4.samsung.com 20250207034307epoutp04eaad9c8478a8c7353fb441336baac7e6~h0CTSQ8h83073830738epoutp04V DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1738899787; bh=XzP4NKg91izVt81d0t10hKnI2+gFIJePspVeYoHJZY0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=M8s8AMSmfeYzQlpWQaaJ0txE+mrftAkVHUt5gSEaEOCiHms3q3MlNoQ2ZoevO2wyM SOgmoGjBYQvWs1Yz3Gwt7HXyJQUFsX6FdD4qTvmK3lwU0r8orb8V/HW+wWCvPa/qwA d4CzSH4rBz/H2futVxniALzsBlgDA9TubYJPb5/U= Received: from epsnrtp3.localdomain (unknown [182.195.42.164]) by epcas2p2.samsung.com (KnoxPortal) with ESMTP id 20250207034307epcas2p2c98375c72e4ddb4c911a29ade027029e~h0CSzT5Fm0055200552epcas2p2V; Fri, 7 Feb 2025 03:43:07 +0000 (GMT) Received: from epsmges2p1.samsung.com (unknown [182.195.36.92]) by epsnrtp3.localdomain (Postfix) with ESMTP id 4Yq0DV4C09z4x9Pw; Fri, 7 Feb 2025 03:43:06 +0000 (GMT) Received: from epcas2p3.samsung.com ( [182.195.41.55]) by epsmges2p1.samsung.com (Symantec Messaging Gateway) with SMTP id D5.C3.23368.A4185A76; Fri, 7 Feb 2025 12:43:06 +0900 (KST) Received: from epsmtrp2.samsung.com (unknown [182.195.40.14]) by epcas2p1.samsung.com (KnoxPortal) with ESMTPA id 20250207034306epcas2p1e0fe6fc78b01fe7b3a55d19f1aaf24db~h0CRxgywb1436814368epcas2p1h; Fri, 7 Feb 2025 03:43:06 +0000 (GMT) Received: from epsmgms1p1new.samsung.com (unknown [182.195.42.41]) by epsmtrp2.samsung.com (KnoxPortal) with ESMTP id 20250207034306epsmtrp2cc06bbaa6bdd99544a01168f616ca094~h0CRwonEc2049520495epsmtrp2j; Fri, 7 Feb 2025 03:43:06 +0000 (GMT) X-AuditID: b6c32a45-dc9f070000005b48-52-67a5814a2dc4 Received: from epsmtip2.samsung.com ( [182.195.34.31]) by epsmgms1p1new.samsung.com (Symantec Messaging Gateway) with SMTP id 56.2B.18729.94185A76; Fri, 7 Feb 2025 12:43:05 +0900 (KST) Received: from tiffany (unknown [10.229.95.142]) by epsmtip2.samsung.com (KnoxPortal) with ESMTPA id 20250207034305epsmtip2e17e29df9ef16e25f085ac43faaab771~h0CRhSyxb1232912329epsmtip2K; Fri, 7 Feb 2025 03:43:05 +0000 (GMT) Date: Fri, 7 Feb 2025 12:41:43 +0900 From: Hyesoo Yu To: Vlastimil Babka Cc: janghyuck.kim@samsung.com, chengming.zhou@linux.dev, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: slub: Print the broken data before restoring slub. Message-ID: <20250207034143.GB491394@tiffany> MIME-Version: 1.0 In-Reply-To: <0d4360b1-0010-45b4-a6d9-94941be89107@suse.cz> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPJsWRmVeSWpSXmKPExsWy7bCmua5X49J0g1kL5Swm9hhYzFm/hs1i 45lPrBbXv71htFjZ3cxmsXlOscXlXXPYLO6t+c9q0fb5H5BYspHJYuIaUYvZjX2MDjweO2fd ZfdYsKnUY9OqTjaPTZ8msXt0vb3C5HFixm8WjydXpjN5LGyYyuzRt2UVo8eZBUfYPT5vkgvg jsq2yUhNTEktUkjNS85PycxLt1XyDo53jjc1MzDUNbS0MFdSyEvMTbVVcvEJ0HXLzAG6XEmh LDGnFCgUkFhcrKRvZ1OUX1qSqpCRX1xiq5RakJJTYF6gV5yYW1yal66Xl1piZWhgYGQKVJiQ nbHx0Hemgg7jigk3rjM1MB5T72Lk4JAQMJHYe4Oti5GLQ0hgB6NE265fzBDOJ0aJjt0dUM43 Rom7l+4ClXGCdfx/9YsVIrGXUeLZl3XsEM5TRolLv06zgFSxCKhI/Nv0hBHEZhNQlzixZRmY LQIUf7ThKFg3s8B/Jom1VzawgySEBQIkbp49CFbEK6Ar8X/yNShbUOLkzCcsIMdyClhLHP2h B9IrIbCFQ+J0625miJNcJA5O+cAKYQtLvDq+hR3ClpL4/G4v1NnFEtsWH2aCaG5glNjccR+q 2Vhi1rN2sGXMAhkSJy4uZIKEjLLEkVssEGE+iY7Df9khwrwSHW1CEJ3KEvuXzWOBsCUlHq1t hzrBQ6L52GwWSKAcZJSYNLODZQKj3Cwk78xCsg3C1pFYsPsT2yygFcwC0hLL/3FAmJoS63fp L2BkXcUollpQnJueWmxUYAiP4eT83E2M4JSs5bqDcfLbD3qHGJk4GA8xSnAwK4nwTlmzJF2I NyWxsiq1KD++qDQntfgQoykwciYyS4km5wOzQl5JvKGJpYGJmZmhuZGpgbmSOG/1jpZ0IYH0 xJLU7NTUgtQimD4mDk6pBqYlq6Zd3/+pKsjhnqznnI67ygHLc06Jyhr/81W41Dwv5pXGXMuj oh9PLFRKu77j8sd/7vrBU++zVq3cnx8hnevCV6rFx2Kya8HD7vz/EVuOMiXk37e4tiXK/cDH FeVvnVzCi6e6LIqVW2eV+CrpeduE3ku8PNtvv5wsfWbT2S1TleucNnbsieHtbjzgsPzsnuOy SzkmJ9w+OMW5x71QbpLrMRHTYjWDy0mbklasfM4pIjtfl++tueZG1ebDdRxWueyvcj9Zbmn0 kI434Xnu4iYe/mOCSbnsOf+42S8TqyZ0Bss/vuPxjvX9my8FLgx8lwsFyjVPMnxyZJ17ft6O 5UzlWbu31+/J47LZGzGpxV2JpTgj0VCLuag4EQB4HgprUgQAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42LZdlhJXtezcWm6weY+S4uJPQYWc9avYbPY eOYTq8X1b28YLVZ2N7NZbJ5TbHF51xw2i3tr/rNatH3+BySWbGSymLhG1GJ2Yx+jA4/Hzll3 2T0WbCr12LSqk81j06dJ7B5db68weZyY8ZvF48mV6UweCxumMnv0bVnF6HFmwRF2j8+b5AK4 o7hsUlJzMstSi/TtErgylr7bwlxwwqBif0sfawPjfNUuRk4OCQETif+vfrGC2EICuxklpk42 hIhLSsz6fJIJwhaWuN9yBKiGC6jmMaPEzGWXmEESLAIqEv82PWEEsdkE1CVObFkGZosAxR9t OArWwCzQzCxxcPsisISwgJ/EnIPfwWxeAV2J/5OvMUJsPsgo8eGGNURcUOLkzCcsIDazgJbE jX8vga7gALKlJZb/4wAxOQWsJY7+0JvAKDALScMsJA2zEBoWMDKvYpRMLSjOTc8tNiwwzEst 1ytOzC0uzUvXS87P3cQIjictzR2M21d90DvEyMTBeIhRgoNZSYR3ypol6UK8KYmVValF+fFF pTmpxYcYpTlYlMR5xV/0pggJpCeWpGanphakFsFkmTg4pRqYir684VMw2qX1Jv/06osZ//JO 9qZECzm3f27vTi8z6ww0PMhUPrPiyHTxlesd+2u2zdjMxHChndPQi/+ZnTzj9Z7Ny2PybZdf 36ud1Gmkv0IyW2Jt5aYnW16EXMjY8/xrj+emOvfO2Kc2JjnMlvuXnn4VKePDk7G5aU1VhGrN iktKa4IlNH/tfbK2krd40oKYHF6Of7Gup/4LOE7/7Bz1iqdjvce8Y7J/XQUCZX72mHYZ3Zpy +/zh5bOZnXfGNHnpbhGKusLCN6P24P3HNeVf3U4H3L+4gi1FdjLbqifGmiLOws8VxeMmBb3X i3t/On6+64cLL29s//5Qf4KOdqL9g+SZ8815A6pKuGNMyhSVWIozEg21mIuKEwEdTxIiFgMA AA== X-CMS-MailID: 20250207034306epcas2p1e0fe6fc78b01fe7b3a55d19f1aaf24db X-Msg-Generator: CA Content-Type: multipart/mixed; boundary="----RdGIdtKpq9gE1V3j7PuPL63Cok.9YsQMFtrTWahmlx-pp0Iy=_7fe54_" X-Sendblock-Type: AUTO_CONFIDENTIAL CMS-TYPE: 102P DLP-Filter: Pass X-CFilter-Loop: Reflected X-CMS-RootMailID: 20250205004552epcas2p43c15afa1e9c3e290693bc4921d46b6f5 References: <20250205004424.1214826-1-hyesoo.yu@samsung.com> <0d4360b1-0010-45b4-a6d9-94941be89107@suse.cz> X-Rspam-User: X-Rspamd-Queue-Id: D3B0110000D X-Rspamd-Server: rspam12 X-Stat-Signature: rrfuzyjtc8ixo9bngsto5xspmqiknez7 X-HE-Tag: 1738899790-681092 X-HE-Meta: U2FsdGVkX19zjxqmFN/VpU8/VGcXvm2FObwXd6tbQAr29cGr6njVwxTmx0QYV9Rr1nOv0wN9JFUdcDHCFVA4Q/xqOopYTc+78XpAHZSnseTahC9owW9US0WaLB6divSp3WjgHpaVVUgwLkP0YRQl+UIhWV9EF6/xMOnJf3dGp1QLCA91JcXB8WkgiVa+24jHxZYSwBBhmgtK5T0ZGPuMZEb5ChDRfHoAcPh1lkBkIxM21GNj+d7N7OGFdCCL3quBR+BL3Hv83HfdhipnWWJ4m1OrslYZA3emefb194W87V/Q+/mMolOBiXBtorj/9APpGn3zteBgcfxq/x5+nO85/h6UBGc3YLZEaBG7p9Aj8fbZtf49ydxoZbjKPbUeh2Gbr567mDoGmc4FLXrNSrqx+bEHVx2JmnZt+pdH2UBtJ6OlbfPlzgZBODagXFJAwkVyZRwHl4h7ytjOs6UpxGagk9zyt4tcXRXy6Epu79OBQwxDPGsEJwXtqvcc09i/r5FpI2RhcU4vonHGk8LrmYmCgodusRqpyTly4Srq9CtoP8WinmP4nOn0xEVyxZxoU4+PgTlppZbVkjg/wA1NsllgL70WGt0MBjndDjNqHO/X/FEPUu9K0DzgPrGK5X6/+F8OpFaanumQb+w5wKgvWQUhkMlFRgmtpYDWaVJ/E0w2Q0IgLDvbEeEa/M6QwW67sho+x5YxfpR9zFiV65vG5zhZMa0pwP8dm/SunBXxOI+v+By+j0EgdImKzYVcP3X96rLPypZ3hReCGWPnGbkQmAQwB4jbZBaRiFImeVt+LSvZM58CThjejlzatYncclS57S28FKS7hWXPxw+is3LxPndmWcNsQ4GhkdjU2RoV6/zp7hphLwejQMTiVJva66y9Uv/1Rsw+tSPXFFZ27zKmpT2nbiyI8ZZaV5YyIVNxiIOuXzDA9SZtEr5zHe2nsDG12QXj+sqE+LOGRTZLIWzWc9T QJAmhf3f fpe3KsTAZp+u+m4d1xLjQP2a9GwLgAwgMFeOqRgNr8GOQeYDYjol5VKh2FGXrlf2eUR6EDHGti7E+EzVvgQY/UQ9adLPo6mmx3Jyqd4MJ+X/ragf1XjGcBHisLLe69qrnmdDTNRfdgWHXh34dqnkqbufbVH9nejlmfe3TX101vnIX3t1eACwaLOrXHm/h62XP8CHlvoZm4Y9uszoLknTd3+fVHt6AjbXKabWmPyj1ADU6x9fuL83mlYsXZGingqCJ38ihiKWZW0fX73E= 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: ------RdGIdtKpq9gE1V3j7PuPL63Cok.9YsQMFtrTWahmlx-pp0Iy=_7fe54_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline On Thu, Feb 06, 2025 at 03:08:48PM +0100, Vlastimil Babka wrote: > On 2/5/25 01:44, Hyesoo Yu wrote: > > Previously, the restore occured after printing the object in slub. > > After commit 47d911b02cbe ("slab: make check_object() more consistent"), > > the bytes are printed after the restore. This information about the bytes > > before the restore is highly valuable for debugging purpose. > > For instance, in a event of cache issue, it displays byte patterns > > by breaking them down into 64-bytes units. Without this information, > > we can only speculate on how it was broken. Hence the corrupted regions > > should be printed prior to the restoration process. However if an object breaks > > in multiple places, the same log may be output multiple times. > > Therefore the slub log is reported only once to prevent redundant printing, > > by sending a parameter indicating whether an error has occurred previously. > > > > Changes in v2: > > - Instead of using print_section every time on check_bytes_and_report, > > just print it once for the entire slub object before the restore. > > > > Signed-off-by: Hyesoo Yu > > --- > > mm/slub.c | 25 ++++++++++++------------- > > 1 file changed, 12 insertions(+), 13 deletions(-) > > > > diff --git a/mm/slub.c b/mm/slub.c > > index ea956cb4b8be..7a9f7a2c17d7 100644 > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -1182,7 +1182,7 @@ static void restore_bytes(struct kmem_cache *s, char *message, u8 data, > > static pad_check_attributes int > > check_bytes_and_report(struct kmem_cache *s, struct slab *slab, > > u8 *object, char *what, > > - u8 *start, unsigned int value, unsigned int bytes) > > + u8 *start, unsigned int value, unsigned int bytes, int slab_obj_print) > > It would be better to redistribute the arguments among lines to fit each <80 > chars. The previous line is underutilized. Also could the new argument be bool? > I used interger to make the types match, but it does seem like using a boolean would be more readable. I will change it to a boolean and modify it to pass !!ret from check_objects(). > > { > > u8 *fault; > > u8 *end; > > @@ -1205,6 +1205,10 @@ check_bytes_and_report(struct kmem_cache *s, struct slab *slab, > > pr_err("0x%p-0x%p @offset=%tu. First byte 0x%x instead of 0x%x\n", > > fault, end - 1, fault - addr, > > fault[0], value); > > Hm we have slab_bug() above this, not slab_err(). So this is another place > that would need to take care a WARN is called with your other patch. > > > + if (slab_obj_print) { > > + print_trailer(s, slab, object); > > + add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE); > > I guess we could do the WARN here. If panic_on_warn is enabled it will not > report all problems that check_object() could find and panic on the first > one. But that would have happened too with your slab_fix() approach > (slab_fix() called from restore_bytes() below). I think we can live with > that instead of needing two separate reporting and fixing rounds from > check_object(). > > Could you send the two patches as a series in v3, as they are > inter-dependent? Thanks. > I guess we can call object_err() here. That would include the WARN() from other patch. I will send the two pathces as a series in v3. Thanks, Regards. > > + } > > > > skip_bug_print: > > restore_bytes(s, what, value, fault, end); > > @@ -1268,7 +1272,7 @@ static int check_pad_bytes(struct kmem_cache *s, struct slab *slab, u8 *p) > > return 1; > > > > return check_bytes_and_report(s, slab, p, "Object padding", > > - p + off, POISON_INUSE, size_from_object(s) - off); > > + p + off, POISON_INUSE, size_from_object(s) - off, 1); > > } > > > > /* Check the pad bytes at the end of a slab page */ > > @@ -1318,11 +1322,11 @@ static int check_object(struct kmem_cache *s, struct slab *slab, > > > > if (s->flags & SLAB_RED_ZONE) { > > if (!check_bytes_and_report(s, slab, object, "Left Redzone", > > - object - s->red_left_pad, val, s->red_left_pad)) > > + object - s->red_left_pad, val, s->red_left_pad, ret)) > > ret = 0; > > > > if (!check_bytes_and_report(s, slab, object, "Right Redzone", > > - endobject, val, s->inuse - s->object_size)) > > + endobject, val, s->inuse - s->object_size, ret)) > > ret = 0; > > > > if (slub_debug_orig_size(s) && val == SLUB_RED_ACTIVE) { > > @@ -1331,7 +1335,7 @@ static int check_object(struct kmem_cache *s, struct slab *slab, > > if (s->object_size > orig_size && > > !check_bytes_and_report(s, slab, object, > > "kmalloc Redzone", p + orig_size, > > - val, s->object_size - orig_size)) { > > + val, s->object_size - orig_size, ret)) { > > ret = 0; > > } > > } > > @@ -1339,7 +1343,7 @@ static int check_object(struct kmem_cache *s, struct slab *slab, > > if ((s->flags & SLAB_POISON) && s->object_size < s->inuse) { > > if (!check_bytes_and_report(s, slab, p, "Alignment padding", > > endobject, POISON_INUSE, > > - s->inuse - s->object_size)) > > + s->inuse - s->object_size, ret)) > > ret = 0; > > } > > } > > @@ -1355,11 +1359,11 @@ static int check_object(struct kmem_cache *s, struct slab *slab, > > if (kasan_meta_size < s->object_size - 1 && > > !check_bytes_and_report(s, slab, p, "Poison", > > p + kasan_meta_size, POISON_FREE, > > - s->object_size - kasan_meta_size - 1)) > > + s->object_size - kasan_meta_size - 1, ret)) > > ret = 0; > > if (kasan_meta_size < s->object_size && > > !check_bytes_and_report(s, slab, p, "End Poison", > > - p + s->object_size - 1, POISON_END, 1)) > > + p + s->object_size - 1, POISON_END, 1, ret)) > > ret = 0; > > } > > /* > > @@ -1385,11 +1389,6 @@ static int check_object(struct kmem_cache *s, struct slab *slab, > > ret = 0; > > } > > > > - if (!ret && !slab_in_kunit_test()) { > > - print_trailer(s, slab, object); > > - add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE); > > - } > > - > > return ret; > > } > > > > ------RdGIdtKpq9gE1V3j7PuPL63Cok.9YsQMFtrTWahmlx-pp0Iy=_7fe54_ Content-Type: text/plain; charset="utf-8" ------RdGIdtKpq9gE1V3j7PuPL63Cok.9YsQMFtrTWahmlx-pp0Iy=_7fe54_--