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 672A2C4345F for ; Wed, 17 Apr 2024 03:45:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A20196B0083; Tue, 16 Apr 2024 23:45:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9CFE06B0085; Tue, 16 Apr 2024 23:45:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8980D6B0087; Tue, 16 Apr 2024 23:45:23 -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 6C6246B0083 for ; Tue, 16 Apr 2024 23:45:23 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BC7F11C0E56 for ; Wed, 17 Apr 2024 03:45:22 +0000 (UTC) X-FDA: 82017633684.15.F41051D Received: from out-181.mta0.migadu.com (out-181.mta0.migadu.com [91.218.175.181]) by imf29.hostedemail.com (Postfix) with ESMTP id D09BF120002 for ; Wed, 17 Apr 2024 03:45:20 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=k0jmZZgo; spf=pass (imf29.hostedemail.com: domain of chengming.zhou@linux.dev designates 91.218.175.181 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713325521; 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=xTs1mMbb3UbD/rPzKoVGHbF5Tq9Us2waCsXSRwCo1bw=; b=NqgO9AfFFKQfXqPWAnpJNJwIlDIGGqs8nFgsMzRR7y/1YQ6B4nRORMJg6txT9w9yMVoFlq rnM+iChpgLTck2HXhFrZPg5DQRq+xoDkwmHXMlGOb2ZvdRtnIhckFUmf5r4jMQhxrvic3/ fe3V91WuZip6vtX+XttPHtlcxRo2tWY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713325521; a=rsa-sha256; cv=none; b=G7Q+aikdeTMM17PN90cn+YpD+GMc+u4xoTY9I+KfLRGOAUaSDCaU235DzVFrZzKpgTjq8g kqSYCgZ20oi4HZItgRvF8y/XX7rIe94LA9lK4vBueb97wo4Tw1tOoMyegeRZjMSNVngf3d D1mMRytjyTi9u0yJyshZvDqsxqjF+y0= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=k0jmZZgo; spf=pass (imf29.hostedemail.com: domain of chengming.zhou@linux.dev designates 91.218.175.181 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Message-ID: <246c1f4d-af13-40fa-b968-fbaf36b8f91f@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1713325518; h=from:from: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; bh=xTs1mMbb3UbD/rPzKoVGHbF5Tq9Us2waCsXSRwCo1bw=; b=k0jmZZgoV2GFZDzw9Bn9vkbsmWpcpDVCPM79jxd+IFH4TfnelpH7t1WJ2o8sZdmjPq7wgR xoyZTVuq+QzzDSKrpnBUYR9TyAECAVdfA5AeReGo4SUNNJlGqxnFiAQD8Km2/1ZhIEQ03T 3gdH8HMCdTvCEKVBp4tXoiZ4S/LFGKs= Date: Wed, 17 Apr 2024 11:44:45 +0800 MIME-Version: 1.0 Subject: Re: [REGRESSION] Null pointer dereference while shrinking zswap Content-Language: en-US To: Nhat Pham , Christian Heusel Cc: Seth Jennings , Dan Streetman , Vitaly Wool , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, David Runge , "Richard W.M. Jones" , Mark W , regressions@lists.linux.dev, Johannes Weiner , Yosry Ahmed References: <3iccc6vjl5gminut3lvpl4va2lbnsgku5ei2d7ylftoofy3n2v@gcfdvtsq6dx2> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Chengming Zhou In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: D09BF120002 X-Stat-Signature: ptf5kkg69ai4zak58awi888s1ood9ji5 X-Rspam-User: X-HE-Tag: 1713325520-204514 X-HE-Meta: U2FsdGVkX18UOOhys26z/7DqH1Qjee99vf4qE3fINriHeiubKJc9dUy2WzODVoCE3EKUDuU6QyGzxwuN2YWX6XBc9EleF/MUFK4nGxOwn/j76eyUCVQy5A0KDzOYafprKrPOhz+P7B7ikTDdsoeiivSNbl1VYo1WvpeSHSSxq5f1Ut2QGIjIoSAl5gPsSziy0GW4ZW50P0aMHTOWTO3z/nd6Hv7Qdm3eaEJJxz0NkcxotizIBJWBlFB58Y6RdutiB1EAUWeqJRCTJR2Gv3CP9U0/Ua8jYevQegJ72/mmPF/Qakf68BCp8qlZ0+CE2OhfB0UIBGWwouC7G4DnBlb1m+MIsJrhK0AxV0LgU7HIFW7E2yfqR3NRi5x16MFmRRoK2nG/lQqRfz37z2oqGPuhMnmVWeWZuG7bZhEgvMilLqjRBuwgJ9X04VTxF8LyX83YAUgSUfGu1/BjI++FGP0DFs1iF2RXXk+CQ+9AMuR5H2msBvkB0pTVtVKkOPpR4zQrTP5hMUDh6A+OErRE8xBIBRw7N1xltMlyaefPAKh6EzYrZn6etnJxpD3V34WM7t1Weah92X13p8RD3l6cdb0hjg0sxgouQ5m2ix22QgbOArTAaU+N8BAZ9tmxooWVqkNV0K5VNJ2/Sb7c99hM+VkgXN3SxcUvWHw3UVadRjfe03UNrt1HzeZDrBkVLesYhbFRW5ugCgOULPIbCFdp9+54i+hSL7TBdrz4wSn7yQPIN9n6wngPKHwmoZeORY8Z61MmWrp0ctd/dHEwl6A6+wms5U9c8YFtx5+ZztYOsUkCC0y2rGNiA7roXJgOSYT2KFowRnT/jeEvMoyzXJ6gLd3eRjrHBWG1g2JEvVYfrI+93W/8nlZP/Z1lMl5J7nEkjPG44AsT8p/78nJk8E3gCoi/Dc/KfuJGW7MIT4qDZJrjE8gUdGka3PnCXvEhj6NUK1+ddOUNZYz6hKHthvPbweN S2jYQ7Tx eQnqFRh3E2/hZNA9v/G9Rw/4S/8/g2FRQuBYkaLmReQK79fRqlQGZlC/PBTDCNyIOsvKfoTd7RKVRd8X9/QbGRKP4LTNLDIWUQIhlTWvCyOT4NXA/G3Typ8kv/Jwf+VmtLi0uNtB4DHFzWfw8UNbUFVVEim3+jx+pSHq/ 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 2024/4/17 08:22, Nhat Pham wrote: > On Tue, Apr 16, 2024 at 4:29 PM Nhat Pham wrote: >> >> On Tue, Apr 16, 2024 at 3:14 PM Nhat Pham wrote: >>> >>> On Tue, Apr 16, 2024 at 5:19 AM Christian Heusel wrote: >>>> >>>> Hello everyone, >>> >>> Thanks for the report, Christian! Looking at it now. >>> >>>> >>>> while rebuilding a few packages in Arch Linux we have recently come >>>> across a regression in the linux kernel which was made visible by a test >>>> failure in libguestfs[0], where the booted kernel showed a Call Trace >>>> like the following one: >>>> >>>> [ 218.738568] CPU: 0 PID: 167 Comm: guestfsd Not tainted 6.7.0-rc4-1-mainline-00158-gb5ba474f3f51 #1 bf39861cf50acae7a79c534e25532f28afe4e593^M >>> >>> Is this one of the kernel versions that was broken? That looks a bit >>> odd, as zswap shrinker landed on 6.8... >> >> Ah ignore this - I understand the versioning now... >> >>> >>>> [ 218.739007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014^M >>>> [ 218.739787] RIP: 0010:memcg_page_state+0x9/0x30^M >>>> [ 218.740299] Code: 0d b8 ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 <48> 8b 87 00 06 00 00 48 63 f6 31 d2 48 8b 04 f0 48 85 c0 48 0f 48^M >>>> [ 218.740727] RSP: 0018:ffffb5fa808dfc10 EFLAGS: 00000202^M >>>> [ 218.740862] RAX: 0000000000000000 RBX: ffffb5fa808dfce0 RCX: 0000000000000002^M >>>> [ 218.741016] RDX: 0000000000000001 RSI: 0000000000000033 RDI: 0000000000000000^M >>>> [ 218.741168] RBP: 0000000000000000 R08: ffff976681ff8000 R09: 0000000000000000^M >>>> [ 218.741322] R10: 0000000000000001 R11: ffff9766833f9d00 R12: ffff9766ffffe780^M >>>> [ 218.742167] R13: 0000000000000000 R14: ffff976680cc1800 R15: ffff976682204d80^M >>>> [ 218.742376] FS: 00007f1479d9f540(0000) GS:ffff9766fbc00000(0000) knlGS:0000000000000000^M >>>> [ 218.742569] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033^M >>>> [ 218.743256] CR2: 0000000000000600 CR3: 0000000103606000 CR4: 0000000000750ef0^M >>>> [ 218.743494] PKRU: 55555554^M >>>> [ 218.743593] Call Trace:^M >>>> [ 218.743733] ^M >>>> [ 218.743847] ? __die+0x23/0x70^M >>>> [ 218.743957] ? page_fault_oops+0x171/0x4e0^M >>>> [ 218.744056] ? free_unref_page+0xf6/0x180^M >>>> [ 218.744458] ? exc_page_fault+0x7f/0x180^M >>>> [ 218.744551] ? asm_exc_page_fault+0x26/0x30^M >>>> [ 218.744684] ? memcg_page_state+0x9/0x30^M >>>> [ 218.744779] zswap_shrinker_count+0x9d/0x110^M >>>> [ 218.744896] do_shrink_slab+0x3a/0x360^M >>>> [ 218.744990] shrink_slab+0xc7/0x3c0^M >>>> [ 218.745609] drop_slab+0x85/0x140^M >>>> [ 218.745691] drop_caches_sysctl_handler+0x7e/0xd0^M >>>> [ 218.745799] proc_sys_call_handler+0x1c0/0x2e0^M >>>> [ 218.745912] vfs_write+0x23d/0x400^M >>>> [ 218.745998] ksys_write+0x6f/0xf0^M >>>> [ 218.746080] do_syscall_64+0x64/0xe0^M >>>> [ 218.746169] ? exit_to_user_mode_prepare+0x132/0x1f0^M >>>> [ 218.746873] entry_SYSCALL_64_after_hwframe+0x6e/0x76^M >>>> > > Actually, inspecting the code a bit more - can memcg be null here? > > Specifically, if mem_cgroup_disabled() is true, can we see null memcg > here? Looks like in this case, mem_cgroup_iter() can return null, and > the first iteration of drop_slab_node() can have null memcg if it's > returned by mem_cgroup_iter(). > > shrink_slab() will still proceed and call do_shrink_slab() if the > memcg is null - provided that mem_cgroup_disabled() holds: > > if (!mem_cgroup_disabled() && !mem_cgroup_is_root(memcg)) > return shrink_slab_memcg(gfp_mask, nid, memcg, priority); > Ah, I think your analysis is very right, here memcg is NULL but memcg_page_state won't check. > Inside zswap_shrink_count(), all the memcg accessors in this area seem > to always check for null memcg (mem_cgroup_lruvec, > mem_cgroup_zswap_writeback_enabled), *except* memcg_page_state, which > is the one line that fail. > > If this is all to it, we can simply add a null check or > mem_cgroup_disabled() check here, and use pool stats instead? Both look ok to me. The VM could only set sc->memcg to NULL when memcg disabled, right? Thanks.