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 04D74CEF14D for ; Tue, 8 Oct 2024 10:25:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2A9CE6B0083; Tue, 8 Oct 2024 06:25:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 258B86B0085; Tue, 8 Oct 2024 06:25:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0ABF46B0088; Tue, 8 Oct 2024 06:25:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E49DF6B0083 for ; Tue, 8 Oct 2024 06:25:37 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 779011C73CB for ; Tue, 8 Oct 2024 10:25:36 +0000 (UTC) X-FDA: 82650053514.10.6DAF999 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf20.hostedemail.com (Postfix) with ESMTP id 0B5CD1C000A for ; Tue, 8 Oct 2024 10:25:34 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=q+DdWF5+; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Rc3uv1i7; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=q+DdWF5+; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Rc3uv1i7; spf=pass (imf20.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728383066; a=rsa-sha256; cv=none; b=OmzeJE/0WpvVCbMr8oqebRdjR4nu7DmiXnTBOocuyhlsBVvn319WpQAH9kTT2jrup2fxXM PLr2EQLWS7Y88wsQ2hvAqCbghzgYeRLFT2Do+cGANmAEgDdXUoc7IhYUoCP/3/JX6Rv9k3 ETrYFPR3s98l6oYoM2UHamr3qYQ2rTY= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=q+DdWF5+; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Rc3uv1i7; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=q+DdWF5+; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Rc3uv1i7; spf=pass (imf20.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728383066; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Bs+wB4ARjzJ6DuArhuiBMRFt2CgFM4qsZXVRe6iWT6Y=; b=LE7vyvuawWgHMl/sLu3slIQsy9TArQSCXbqkIIUtjPMRsEUCl8RpT78KNpJlre+UWntfNs bAoJhzuuXeLqLqDvt+RA7kNMykGi8hm0RnnAdpktli116V2j17cuJaz8tBuHDT5jVHlTMt hHgHN2p5czqxfFX05xh4s09AcA1lb+I= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 460DC1F7A5; Tue, 8 Oct 2024 10:25:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1728383133; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Bs+wB4ARjzJ6DuArhuiBMRFt2CgFM4qsZXVRe6iWT6Y=; b=q+DdWF5+BXM1SLm7aO2Ftz8bpNmP+Tv0Fa/G2yoHA8VVlOOkmm1cljw2l8/h/zJB8Wkm9h da8/9ycCmu6jIQB+w4cIIoqOQvmdQ0a+kPKgrUQMzs1oiDnQWcu8KzYVhZzGHr7PR901+n OB1iL/TsBoa3/zEIr1z9bcyuDsaD5fk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1728383133; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Bs+wB4ARjzJ6DuArhuiBMRFt2CgFM4qsZXVRe6iWT6Y=; b=Rc3uv1i7oO1oHW17xDmL5XmTRNFpWAk0OtzxQnDVxpGqNySJbBifZq/8LfchcWMIStqPxt UX8EIRX4+LGtVPBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1728383133; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Bs+wB4ARjzJ6DuArhuiBMRFt2CgFM4qsZXVRe6iWT6Y=; b=q+DdWF5+BXM1SLm7aO2Ftz8bpNmP+Tv0Fa/G2yoHA8VVlOOkmm1cljw2l8/h/zJB8Wkm9h da8/9ycCmu6jIQB+w4cIIoqOQvmdQ0a+kPKgrUQMzs1oiDnQWcu8KzYVhZzGHr7PR901+n OB1iL/TsBoa3/zEIr1z9bcyuDsaD5fk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1728383133; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Bs+wB4ARjzJ6DuArhuiBMRFt2CgFM4qsZXVRe6iWT6Y=; b=Rc3uv1i7oO1oHW17xDmL5XmTRNFpWAk0OtzxQnDVxpGqNySJbBifZq/8LfchcWMIStqPxt UX8EIRX4+LGtVPBw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 24861137CF; Tue, 8 Oct 2024 10:25:33 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id yySPCJ0IBWcnSwAAD6G6ig (envelope-from ); Tue, 08 Oct 2024 10:25:33 +0000 Message-ID: Date: Tue, 8 Oct 2024 12:25:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mm/slub: Avoid list corruption when removing a slab from the full list Content-Language: en-US To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: "yuan.gao" , cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20241007091850.16959-1-yuan.gao@ucloud.cn> From: Vlastimil Babka Autocrypt: addr=vbabka@suse.cz; keydata= xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+ 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSBWbGFzdGltaWwg QmFia2EgPHZiYWJrYUBzdXNlLmN6PsLBlAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgBYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJkBREIBQkRadznAAoJECJPp+fMgqZkNxIQ ALZRqwdUGzqL2aeSavbum/VF/+td+nZfuH0xeWiO2w8mG0+nPd5j9ujYeHcUP1edE7uQrjOC Gs9sm8+W1xYnbClMJTsXiAV88D2btFUdU1mCXURAL9wWZ8Jsmz5ZH2V6AUszvNezsS/VIT87 AmTtj31TLDGwdxaZTSYLwAOOOtyqafOEq+gJB30RxTRE3h3G1zpO7OM9K6ysLdAlwAGYWgJJ V4JqGsQ/lyEtxxFpUCjb5Pztp7cQxhlkil0oBYHkudiG8j1U3DG8iC6rnB4yJaLphKx57NuQ PIY0Bccg+r9gIQ4XeSK2PQhdXdy3UWBr913ZQ9AI2usid3s5vabo4iBvpJNFLgUmxFnr73SJ KsRh/2OBsg1XXF/wRQGBO9vRuJUAbnaIVcmGOUogdBVS9Sun/Sy4GNA++KtFZK95U7J417/J Hub2xV6Ehc7UGW6fIvIQmzJ3zaTEfuriU1P8ayfddrAgZb25JnOW7L1zdYL8rXiezOyYZ8Fm ZyXjzWdO0RpxcUEp6GsJr11Bc4F3aae9OZtwtLL/jxc7y6pUugB00PodgnQ6CMcfR/HjXlae h2VS3zl9+tQWHu6s1R58t5BuMS2FNA58wU/IazImc/ZQA+slDBfhRDGYlExjg19UXWe/gMcl De3P1kxYPgZdGE2eZpRLIbt+rYnqQKy8UxlszsBNBFsZNTUBCACfQfpSsWJZyi+SHoRdVyX5 J6rI7okc4+b571a7RXD5UhS9dlVRVVAtrU9ANSLqPTQKGVxHrqD39XSw8hxK61pw8p90pg4G /N3iuWEvyt+t0SxDDkClnGsDyRhlUyEWYFEoBrrCizbmahOUwqkJbNMfzj5Y7n7OIJOxNRkB IBOjPdF26dMP69BwePQao1M8Acrrex9sAHYjQGyVmReRjVEtv9iG4DoTsnIR3amKVk6si4Ea X/mrapJqSCcBUVYUFH8M7bsm4CSxier5ofy8jTEa/CfvkqpKThTMCQPNZKY7hke5qEq1CBk2 wxhX48ZrJEFf1v3NuV3OimgsF2odzieNABEBAAHCwXwEGAEKACYCGwwWIQSpQNQ0mSwujpkQ PVAiT6fnzIKmZAUCZAUSmwUJDK5EZgAKCRAiT6fnzIKmZOJGEACOKABgo9wJXsbWhGWYO7mD 8R8mUyJHqbvaz+yTLnvRwfe/VwafFfDMx5GYVYzMY9TWpA8psFTKTUIIQmx2scYsRBUwm5VI EurRWKqENcDRjyo+ol59j0FViYysjQQeobXBDDE31t5SBg++veI6tXfpco/UiKEsDswL1WAr tEAZaruo7254TyH+gydURl2wJuzo/aZ7Y7PpqaODbYv727Dvm5eX64HCyyAH0s6sOCyGF5/p eIhrOn24oBf67KtdAN3H9JoFNUVTYJc1VJU3R1JtVdgwEdr+NEciEfYl0O19VpLE/PZxP4wX PWnhf5WjdoNI1Xec+RcJ5p/pSel0jnvBX8L2cmniYnmI883NhtGZsEWj++wyKiS4NranDFlA HdDM3b4lUth1pTtABKQ1YuTvehj7EfoWD3bv9kuGZGPrAeFNiHPdOT7DaXKeHpW9homgtBxj 8aX/UkSvEGJKUEbFL9cVa5tzyialGkSiZJNkWgeHe+jEcfRT6pJZOJidSCdzvJpbdJmm+eED w9XOLH1IIWh7RURU7G1iOfEfmImFeC3cbbS73LQEFGe1urxvIH5K/7vX+FkNcr9ujwWuPE9b 1C2o4i/yZPLXIVy387EjA6GZMqvQUFuSTs/GeBcv0NjIQi8867H3uLjz+mQy63fAitsDwLmR EP+ylKVEKb0Q2A== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Action: no action X-Stat-Signature: cdqf3ay1g53np3bw7656mi4uf6ks8cd3 X-Rspamd-Queue-Id: 0B5CD1C000A X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1728383134-289155 X-HE-Meta: U2FsdGVkX19ampRpHYDkffMQndEVPQ2Jo/U3pK7AR56EMpM9t/pHZ41SPvcc9vsjNHyhoV6s9lYn6Ze6Z7DLS70mMvZSkhxcrLkP/rck7OcyZhWkYN9IRwoNj1iRzUDL/WD57kt5qCEqeXd8syNbDjNTgGCoZPstQgbjB4Akk2zGzsTFku+u21MY3sgwpoK5pl8SH1eU53ZXHr+kpyI7xJtxBCjAKyKCA58PzcPplspjrWv11pbnSmRem1d9To8izFkFQk+DMB37XttvD0UIIT6XvYq11Cz737lsP0c1xw1jTKIyLcyt9JtzbeFY3gjzJ9oi4QS9tK7JpQ8qPdbO0Bul1YkTkBMFj+HNFTAFbxa3gPbHd7wEFg5k4oTaDJGmO+LQ/nQzTMQe/MrzQLUyL1yIYltCQqevBkbWvLib0rSJ9QgNrvOmLlVdIJVRpzde8Dfl1us0ooVhcwh2UPzyJEE5zodYIinttJH/PLMqwNoO4ySXRMfQQb3rbGw/Lc53q8M20xdJBwpremdD8MCPp8CMzMq7QP05bvO0HJTXIEUNRwZU1XUtbCc/4IwJuQA41l2QPItvMO8LsLkGvfsG+g1DnwZlwBA8ljNmcW1nn/erXDCpLZXNXicDM40YHcxZOY/ehZ8ZOdjFvMn7Hfe8KC5g+3Sz0q+xyMWUPGBm5ODwOZdNOO1I+gFqx8Sm0BzUt/qiq1IHvnmYs7N+/80COv9BsoVu6hGVO0Bn9gECuoUZszY7eVCJInX1r+vCMxsMX1OPb/diAwpHR2H/zDkD3bVBRP5AJ6KHWNb+GX+x/j1hgzbIRDPwvJH4d9+WxBJXIUuFVfQYn5ZwCSWPMoDoHucjyLYWRokX2RPugIEza3dNlyOAOhTJhTHysCVEpvl5SuFbIBZa1xphTTLYWXJP0JBZzoCbRTVRHKZ6m+2StWVp76B102l2E4hPjf36gzFt0Cz3tKVggEzugXnN0v+ GgfQpced 209lkfSbRzFNI2PS/7mWxBNU6GN1N81B9AY4qScD8nu8M9obk9sOlWJpH49a7/U6d5KXKjffxswvdU7cxRqlOYh6nwv0B9LmXOaMYJXBbf27WdtWn+sh/7cpGiXWxIlQMVUtqu5dkSw8nAH5uymPGCpzJ7lDs0ntLmguQhB/R7In2lE1GJwdDgeWjFdzDPmxL+H2maV1L7aIrnKCh/w4ET5NzdC6r7JDw4Rz8MTowUCntHQAqxZidNk/MsefqK21TKEWOeP2Rjp3dvWeu5/OHKdYIsIYTba74R8DpPgjl/Y/2t8POLAgkYyrTu0hHbmh9ybaf+ahDmsQkbd/s9DFzYfVwU+6eHzaYxSj3DE5heM6W+/UU4irGk1SHbcJMe5O3FDBjwyViWh/a0Z+N6k2YYGFOx1lhl4zzOqW0rvYPORpLCzAR2WdIXAp2+g== 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 10/7/24 17:03, Hyeonggon Yoo wrote: > On Mon, Oct 7, 2024 at 11:29 PM Vlastimil Babka wrote: >> >> On 10/7/24 11:18 AM, yuan.gao wrote: >> > boot with slub_debug=UFPZ. >> > >> > If allocated object failed in alloc_consistency_checks, all objects of >> > the slab will be marked as used, and then the slab will be removed from >> > the partial list. >> > >> > When an object belonging to the slab got freed later, the remove_full() >> > function is called. Because the slab is neither on the partial list nor >> > on the full list, it eventually lead to a list corruption. >> > >> > So we need to add the slab to full list in this case. >> > >> > [ 4277.385669] list_del corruption, ffffea00044b3e50->next is LIST_POISON1 (dead000000000100) >> > [ 4277.387023] ------------[ cut here ]------------ >> > [ 4277.387880] kernel BUG at lib/list_debug.c:56! >> > [ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI >> > [ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G OE 6.6.1-1 #1 >> > [ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs] >> > [ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0 >> > [ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91 >> > [ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082 >> > [ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000 >> > [ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff >> > [ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0 >> > [ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910 >> > [ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0 >> > [ 4277.404049] FS: 0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000 >> > [ 4277.405357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> > [ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0 >> > [ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >> > [ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 >> > [ 4277.410000] PKRU: 55555554 >> > [ 4277.410645] Call Trace: >> > [ 4277.411234] >> > [ 4277.411777] ? die+0x32/0x80 >> > [ 4277.412439] ? do_trap+0xd6/0x100 >> > [ 4277.413150] ? __list_del_entry_valid_or_report+0x7b/0xc0 >> > [ 4277.414158] ? do_error_trap+0x6a/0x90 >> > [ 4277.414948] ? __list_del_entry_valid_or_report+0x7b/0xc0 >> > [ 4277.415915] ? exc_invalid_op+0x4c/0x60 >> > [ 4277.416710] ? __list_del_entry_valid_or_report+0x7b/0xc0 >> > [ 4277.417675] ? asm_exc_invalid_op+0x16/0x20 >> > [ 4277.418482] ? __list_del_entry_valid_or_report+0x7b/0xc0 >> > [ 4277.419466] ? __list_del_entry_valid_or_report+0x7b/0xc0 >> > [ 4277.420410] free_to_partial_list+0x515/0x5e0 >> > [ 4277.421242] ? xfs_iext_remove+0x41a/0xa10 [xfs] >> > [ 4277.422298] xfs_iext_remove+0x41a/0xa10 [xfs] >> > [ 4277.423316] ? xfs_inodegc_worker+0xb4/0x1a0 [xfs] >> > [ 4277.424383] xfs_bmap_del_extent_delay+0x4fe/0x7d0 [xfs] >> > [ 4277.425490] __xfs_bunmapi+0x50d/0x840 [xfs] >> > [ 4277.426445] xfs_itruncate_extents_flags+0x13a/0x490 [xfs] >> > [ 4277.427553] xfs_inactive_truncate+0xa3/0x120 [xfs] >> > [ 4277.428567] xfs_inactive+0x22d/0x290 [xfs] >> > [ 4277.429500] xfs_inodegc_worker+0xb4/0x1a0 [xfs] >> > [ 4277.430479] process_one_work+0x171/0x340 >> > [ 4277.431227] worker_thread+0x277/0x390 >> > [ 4277.431962] ? __pfx_worker_thread+0x10/0x10 >> > [ 4277.432752] kthread+0xf0/0x120 >> > [ 4277.433382] ? __pfx_kthread+0x10/0x10 >> > [ 4277.434134] ret_from_fork+0x2d/0x50 >> > [ 4277.434837] ? __pfx_kthread+0x10/0x10 >> > [ 4277.435566] ret_from_fork_asm+0x1b/0x30 >> > [ 4277.436280] >> > >> > v2: >> > * Call remove_partial() and add_full() only for slab folios. >> > >> > v1: >> > https://lore.kernel.org/linux-mm/20241006044755.79634-1-yuan.gao@ucloud.cn/ >> > >> > Signed-off-by: yuan.gao >> >> Is it possible to determine which commit introduced this issue, for a >> stable cc? > > By code inspection I suspect it's around when SLUB's first introduced in 2007, > more specifically commit 643b113849d8 ("slub: enable tracking of full slabs"). > Even v2.6 kernels do not seem to handle this case correctly. > >> Also in addition to what Hyeonggon proposed, we should perhaps mark >> these consistency-failed slabs in a way that further freeing of objects >> in them will also don't actually free anything, and thus not move the >> slab back from full to partial list for further reuse. > > Yeah I was thinking of that too. > > If that is feasible Yuan you may use one bit from (in mm/slab.h) > struct slab's 'inuse' field > and change it to 15 bits to mark consistency-failed slabs. > > IIUC 'inuse' doesn't have to be 16 bits and 'objects' is already 15 > bits, so I think it should be fine. AFAICS we are in a rather comfortable position for the debug caches which avoid all the fastpaths, and we could simply reuse the frozen bit or invent a special value for slab->freelist? Either way it should boil down to free_debug_processing() detecting such a slab (or perhaps in check_slab()) and returning false/0 immediately which would avoid further actions on the slab. If it was done in check_slab() then free_debug_processing() would at least report which of the objects in a broken slab were attempted to be freed after it was marked broken, which could perhaps be useful: slab_fix(s, "Object at 0x%p not freed", object); Vlastimil >> Right now the >> (understandable) attempt to not use the corrupted slab further is only >> partially successful. > > Best, > Hyeonggon > >> > --- >> > mm/slub.c | 5 ++++- >> > 1 file changed, 4 insertions(+), 1 deletion(-) >> > >> > diff --git a/mm/slub.c b/mm/slub.c >> > index 21f71cb6cc06..2992388c00f4 100644 >> > --- a/mm/slub.c >> > +++ b/mm/slub.c >> > @@ -2745,7 +2745,10 @@ static void *alloc_single_from_partial(struct kmem_cache *s, >> > slab->inuse++; >> > >> > if (!alloc_debug_processing(s, slab, object, orig_size)) { >> > - remove_partial(n, slab); >> > + if (folio_test_slab(slab_folio(slab))) { >> > + remove_partial(n, slab); >> > + add_full(s, n, slab); >> > + } >> > return NULL; >> > } >> >