Message ID | 20230421174054.3434533-1-roman.gushchin@linux.dev |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1241930vqo; Fri, 21 Apr 2023 10:49:27 -0700 (PDT) X-Google-Smtp-Source: AKy350buhiXPN2sbRMle1qk1lEJf2pNxvimdCfLDyeKeLcVQZpBbRXfZhNarfrvLhhuuvBLXTIrX X-Received: by 2002:a17:90b:4a10:b0:246:bb61:4a56 with SMTP id kk16-20020a17090b4a1000b00246bb614a56mr5947607pjb.27.1682099367228; Fri, 21 Apr 2023 10:49:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682099367; cv=none; d=google.com; s=arc-20160816; b=jGshqWKvQJs0eL2rwpbm7vGufQwVtJbPcjpH0Qz7jmsd4tzQVmsrTD7zULpzz2XCc1 zj9z1G/Fkp8ZZvabnbx1pTVXwXxeT8MnhXPxMdDhV6HXS4IN8t4q5wXpvh+2PDYSdK7P ow+F3UQiK+fNn/kFDzhLHNtex9fFyMJP1a/hagR1FTgJMFY/V6YRMYE0QuNiNKuQoVfP zZIUWaaX/vFtjVNxfnLvIPf0pjLx+mOgTf1yHyGaFeCqOU25UsTePdeBs/iKsCnq+8nI EhtmxylTVJyh+3UsoWTZeUdXiXgMOUIMi/k1WIikU9b/4iro0n1eP0Nnl6aJaBnCQitm fQFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=8lsVSCZFASjGj882L2SUq8X57TGcITsPyPXAfEkTLgs=; b=RkmzXnFZg1lDxFPPiRNR6X9n+HXwiXI3YDLptTAtGp6FUf4SwPNEG0CRPCPYcaIzjX hc9Fjm4/MPvKa8W/pau2GLqJdTE0kxNXu1p0Lckrulpa5Ok+9Lh3t0R14VcLqR504tEa Qo77Kywm4hrR9UPrOzbLM6bygoWrmXsjvRpEZZYoxUSxr0nDLiGuEvtZjaOud2qrfs8W Llu9hqJPgDwkHrgTvk/nmzOJ9ysq70lHx0wbqCvgUvFJ/9oY17EacupXgJ/PtKCHGJqO AtIwIDV7CxfRi9uKPCctAu9n3naGVqMcT9hSdObCf0cJ9SME6/SbdOfTI2NCfDvfeqoK ygDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b="PFr/EZar"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e7-20020a17090a9a8700b0024981e98175si5028026pjp.75.2023.04.21.10.49.15; Fri, 21 Apr 2023 10:49:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b="PFr/EZar"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232646AbjDURmQ (ORCPT <rfc822;cjcooper78@gmail.com> + 99 others); Fri, 21 Apr 2023 13:42:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41668 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233450AbjDURmJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 21 Apr 2023 13:42:09 -0400 Received: from out-18.mta1.migadu.com (out-18.mta1.migadu.com [95.215.58.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0DE615A35 for <linux-kernel@vger.kernel.org>; Fri, 21 Apr 2023 10:41:37 -0700 (PDT) X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1682098890; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8lsVSCZFASjGj882L2SUq8X57TGcITsPyPXAfEkTLgs=; b=PFr/EZaro7ssLUyyiZMxEP8YjsXfPwxeIaTBtv49tB58yI+pA+FCiq9xPo1wG91VUqogAG FyfKBvQ9Z2R68a2BgzhattI724YLKBAbj5PronSuPVAPPPW8Z0PtgStuMgWLu5uwlluwGl HlqkPYGxLE4udEvViO3aTzpvtlubx/U= From: Roman Gushchin <roman.gushchin@linux.dev> To: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org> Cc: Johannes Weiner <hannes@cmpxchg.org>, Michal Hocko <mhocko@kernel.org>, Shakeel Butt <shakeelb@google.com>, Muchun Song <muchun.song@linux.dev>, linux-kernel@vger.kernel.org, Roman Gushchin <roman.gushchin@linux.dev>, syzbot+774c29891415ab0fd29d@syzkaller.appspotmail.com, Dmitry Vyukov <dvyukov@google.com> Subject: [PATCH] mm: kmem: fix a NULL pointer dereference in obj_stock_flush_required() Date: Fri, 21 Apr 2023 10:40:54 -0700 Message-Id: <20230421174054.3434533-1-roman.gushchin@linux.dev> In-Reply-To: <00000000000058b63f05f9d98811@google.com> References: <00000000000058b63f05f9d98811@google.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763809025848376906?= X-GMAIL-MSGID: =?utf-8?q?1763809025848376906?= |
Series |
mm: kmem: fix a NULL pointer dereference in obj_stock_flush_required()
|
|
Commit Message
Roman Gushchin
April 21, 2023, 5:40 p.m. UTC
KCSAN found an issue in obj_stock_flush_required():
stock->cached_objcg can be reset between the check and dereference:
==================================================================
BUG: KCSAN: data-race in drain_all_stock / drain_obj_stock
write to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0:
drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306
refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340
obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408
memcg_slab_free_hook mm/slab.h:587 [inline]
__cache_free mm/slab.c:3373 [inline]
__do_kmem_cache_free mm/slab.c:3577 [inline]
kmem_cache_free+0x105/0x280 mm/slab.c:3602
__d_free fs/dcache.c:298 [inline]
dentry_free fs/dcache.c:375 [inline]
__dentry_kill+0x422/0x4a0 fs/dcache.c:621
dentry_kill+0x8d/0x1e0
dput+0x118/0x1f0 fs/dcache.c:913
__fput+0x3bf/0x570 fs/file_table.c:329
____fput+0x15/0x20 fs/file_table.c:349
task_work_run+0x123/0x160 kernel/task_work.c:179
resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171
exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203
__syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296
do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x63/0xcd
read to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1:
obj_stock_flush_required mm/memcontrol.c:3319 [inline]
drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361
try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703
try_charge mm/memcontrol.c:2837 [inline]
mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290
sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025
sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525
udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692
udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817
sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668
__sys_setsockopt+0x1c3/0x230 net/socket.c:2271
__do_sys_setsockopt net/socket.c:2282 [inline]
__se_sys_setsockopt net/socket.c:2279 [inline]
__x64_sys_setsockopt+0x66/0x80 net/socket.c:2279
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
value changed: 0xffff8881382d52c0 -> 0xffff888138893740
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
Fix it by reading the cached_objcg with READ_ONCE().
Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API")
Reported-by: syzbot+774c29891415ab0fd29d@syzkaller.appspotmail.com
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Link: https://lore.kernel.org/linux-mm/CACT4Y+ZfucZhM60YPphWiCLJr6+SGFhT+jjm8k1P-a_8Kkxsjg@mail.gmail.com/T/#t
Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev>
---
mm/memcontrol.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Comments
On Fri, Apr 21, 2023 at 10:41 AM Roman Gushchin <roman.gushchin@linux.dev> wrote: > > KCSAN found an issue in obj_stock_flush_required(): > stock->cached_objcg can be reset between the check and dereference: > > ================================================================== > BUG: KCSAN: data-race in drain_all_stock / drain_obj_stock > > write to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0: > drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306 > refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340 > obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408 > memcg_slab_free_hook mm/slab.h:587 [inline] > __cache_free mm/slab.c:3373 [inline] > __do_kmem_cache_free mm/slab.c:3577 [inline] > kmem_cache_free+0x105/0x280 mm/slab.c:3602 > __d_free fs/dcache.c:298 [inline] > dentry_free fs/dcache.c:375 [inline] > __dentry_kill+0x422/0x4a0 fs/dcache.c:621 > dentry_kill+0x8d/0x1e0 > dput+0x118/0x1f0 fs/dcache.c:913 > __fput+0x3bf/0x570 fs/file_table.c:329 > ____fput+0x15/0x20 fs/file_table.c:349 > task_work_run+0x123/0x160 kernel/task_work.c:179 > resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] > exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171 > exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203 > __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] > syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296 > do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > read to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1: > obj_stock_flush_required mm/memcontrol.c:3319 [inline] > drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361 > try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703 > try_charge mm/memcontrol.c:2837 [inline] > mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290 > sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025 > sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525 > udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692 > udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817 > sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668 > __sys_setsockopt+0x1c3/0x230 net/socket.c:2271 > __do_sys_setsockopt net/socket.c:2282 [inline] > __se_sys_setsockopt net/socket.c:2279 [inline] > __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > value changed: 0xffff8881382d52c0 -> 0xffff888138893740 > > Reported by Kernel Concurrency Sanitizer on: > CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 > > Fix it by reading the cached_objcg with READ_ONCE(). IIUC reading an outdated objcg is fine here, and the real problem is a potential NULL dereference, which isn't shown by this report. Is this correct? > > Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API") > Reported-by: syzbot+774c29891415ab0fd29d@syzkaller.appspotmail.com > Reported-by: Dmitry Vyukov <dvyukov@google.com> > Link: https://lore.kernel.org/linux-mm/CACT4Y+ZfucZhM60YPphWiCLJr6+SGFhT+jjm8k1P-a_8Kkxsjg@mail.gmail.com/T/#t > Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev> > --- > mm/memcontrol.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 5abffe6f8389..9426a1ddc190 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -3314,10 +3314,11 @@ static struct obj_cgroup *drain_obj_stock(struct memcg_stock_pcp *stock) > static bool obj_stock_flush_required(struct memcg_stock_pcp *stock, > struct mem_cgroup *root_memcg) > { > + struct obj_cgroup *objcg = READ_ONCE(stock->cached_objcg); > struct mem_cgroup *memcg; > > - if (stock->cached_objcg) { > - memcg = obj_cgroup_memcg(stock->cached_objcg); > + if (objcg) { > + memcg = obj_cgroup_memcg(objcg); > if (memcg && mem_cgroup_is_descendant(memcg, root_memcg)) > return true; > } > -- > 2.40.0 > >
On Fri, Apr 21, 2023 at 03:16:02PM -0700, Yosry Ahmed wrote: > On Fri, Apr 21, 2023 at 10:41 AM Roman Gushchin > <roman.gushchin@linux.dev> wrote: > > > > KCSAN found an issue in obj_stock_flush_required(): > > stock->cached_objcg can be reset between the check and dereference: > > > > ================================================================== > > BUG: KCSAN: data-race in drain_all_stock / drain_obj_stock > > > > write to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0: > > drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306 > > refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340 > > obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408 > > memcg_slab_free_hook mm/slab.h:587 [inline] > > __cache_free mm/slab.c:3373 [inline] > > __do_kmem_cache_free mm/slab.c:3577 [inline] > > kmem_cache_free+0x105/0x280 mm/slab.c:3602 > > __d_free fs/dcache.c:298 [inline] > > dentry_free fs/dcache.c:375 [inline] > > __dentry_kill+0x422/0x4a0 fs/dcache.c:621 > > dentry_kill+0x8d/0x1e0 > > dput+0x118/0x1f0 fs/dcache.c:913 > > __fput+0x3bf/0x570 fs/file_table.c:329 > > ____fput+0x15/0x20 fs/file_table.c:349 > > task_work_run+0x123/0x160 kernel/task_work.c:179 > > resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] > > exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171 > > exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203 > > __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] > > syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296 > > do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86 > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > > > read to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1: > > obj_stock_flush_required mm/memcontrol.c:3319 [inline] > > drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361 > > try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703 > > try_charge mm/memcontrol.c:2837 [inline] > > mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290 > > sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025 > > sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525 > > udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692 > > udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817 > > sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668 > > __sys_setsockopt+0x1c3/0x230 net/socket.c:2271 > > __do_sys_setsockopt net/socket.c:2282 [inline] > > __se_sys_setsockopt net/socket.c:2279 [inline] > > __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279 > > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > > do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > > > value changed: 0xffff8881382d52c0 -> 0xffff888138893740 > > > > Reported by Kernel Concurrency Sanitizer on: > > CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 > > > > Fix it by reading the cached_objcg with READ_ONCE(). > > IIUC reading an outdated objcg is fine here, and the real problem is a > potential NULL dereference, which isn't shown by this report. Is this > correct? My understanding of the problem: 1) we are reading stock->cached_objcg and checking for being NULL, it's not NULL. 2) we're reading it again and dereferencing it without a check. If stock->cached_objcg is zeroed between 1) and 2), we're in trouble. The fix makes sure we're dereferencing exactly what we check. > > > > > Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API") > > Reported-by: syzbot+774c29891415ab0fd29d@syzkaller.appspotmail.com > > Reported-by: Dmitry Vyukov <dvyukov@google.com> > > Link: https://lore.kernel.org/linux-mm/CACT4Y+ZfucZhM60YPphWiCLJr6+SGFhT+jjm8k1P-a_8Kkxsjg@mail.gmail.com/T/#t > > Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev> > > --- > > mm/memcontrol.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 5abffe6f8389..9426a1ddc190 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -3314,10 +3314,11 @@ static struct obj_cgroup *drain_obj_stock(struct memcg_stock_pcp *stock) > > static bool obj_stock_flush_required(struct memcg_stock_pcp *stock, > > struct mem_cgroup *root_memcg) > > { > > + struct obj_cgroup *objcg = READ_ONCE(stock->cached_objcg); > > struct mem_cgroup *memcg; > > > > - if (stock->cached_objcg) { > > - memcg = obj_cgroup_memcg(stock->cached_objcg); > > + if (objcg) { > > + memcg = obj_cgroup_memcg(objcg); > > if (memcg && mem_cgroup_is_descendant(memcg, root_memcg)) > > return true; > > } > > -- > > 2.40.0 > > > >
On Fri, Apr 21, 2023 at 3:55 PM Roman Gushchin <roman.gushchin@linux.dev> wrote: > > On Fri, Apr 21, 2023 at 03:16:02PM -0700, Yosry Ahmed wrote: > > On Fri, Apr 21, 2023 at 10:41 AM Roman Gushchin > > <roman.gushchin@linux.dev> wrote: > > > > > > KCSAN found an issue in obj_stock_flush_required(): > > > stock->cached_objcg can be reset between the check and dereference: > > > > > > ================================================================== > > > BUG: KCSAN: data-race in drain_all_stock / drain_obj_stock > > > > > > write to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0: > > > drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306 > > > refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340 > > > obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408 > > > memcg_slab_free_hook mm/slab.h:587 [inline] > > > __cache_free mm/slab.c:3373 [inline] > > > __do_kmem_cache_free mm/slab.c:3577 [inline] > > > kmem_cache_free+0x105/0x280 mm/slab.c:3602 > > > __d_free fs/dcache.c:298 [inline] > > > dentry_free fs/dcache.c:375 [inline] > > > __dentry_kill+0x422/0x4a0 fs/dcache.c:621 > > > dentry_kill+0x8d/0x1e0 > > > dput+0x118/0x1f0 fs/dcache.c:913 > > > __fput+0x3bf/0x570 fs/file_table.c:329 > > > ____fput+0x15/0x20 fs/file_table.c:349 > > > task_work_run+0x123/0x160 kernel/task_work.c:179 > > > resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] > > > exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171 > > > exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203 > > > __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] > > > syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296 > > > do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86 > > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > > > > > read to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1: > > > obj_stock_flush_required mm/memcontrol.c:3319 [inline] > > > drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361 > > > try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703 > > > try_charge mm/memcontrol.c:2837 [inline] > > > mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290 > > > sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025 > > > sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525 > > > udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692 > > > udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817 > > > sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668 > > > __sys_setsockopt+0x1c3/0x230 net/socket.c:2271 > > > __do_sys_setsockopt net/socket.c:2282 [inline] > > > __se_sys_setsockopt net/socket.c:2279 [inline] > > > __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279 > > > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > > > do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 > > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > > > > > value changed: 0xffff8881382d52c0 -> 0xffff888138893740 > > > > > > Reported by Kernel Concurrency Sanitizer on: > > > CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0 > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 > > > > > > Fix it by reading the cached_objcg with READ_ONCE(). > > > > IIUC reading an outdated objcg is fine here, and the real problem is a > > potential NULL dereference, which isn't shown by this report. Is this > > correct? > > My understanding of the problem: > 1) we are reading stock->cached_objcg and checking for being NULL, it's not NULL. > 2) we're reading it again and dereferencing it without a check. > > If stock->cached_objcg is zeroed between 1) and 2), we're in trouble. > > The fix makes sure we're dereferencing exactly what we check. I see. This matches my understanding. The bug report does not show a NULL dereference but it shows a data race that can very well lead to one. FWIW, Reviewed-by: Yosry Ahmed <yosryahmed@google.com> > > > > > > > > > Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API") > > > Reported-by: syzbot+774c29891415ab0fd29d@syzkaller.appspotmail.com > > > Reported-by: Dmitry Vyukov <dvyukov@google.com> > > > Link: https://lore.kernel.org/linux-mm/CACT4Y+ZfucZhM60YPphWiCLJr6+SGFhT+jjm8k1P-a_8Kkxsjg@mail.gmail.com/T/#t > > > Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev> > > > --- > > > mm/memcontrol.c | 5 +++-- > > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > > index 5abffe6f8389..9426a1ddc190 100644 > > > --- a/mm/memcontrol.c > > > +++ b/mm/memcontrol.c > > > @@ -3314,10 +3314,11 @@ static struct obj_cgroup *drain_obj_stock(struct memcg_stock_pcp *stock) > > > static bool obj_stock_flush_required(struct memcg_stock_pcp *stock, > > > struct mem_cgroup *root_memcg) > > > { > > > + struct obj_cgroup *objcg = READ_ONCE(stock->cached_objcg); > > > struct mem_cgroup *memcg; > > > > > > - if (stock->cached_objcg) { > > > - memcg = obj_cgroup_memcg(stock->cached_objcg); > > > + if (objcg) { > > > + memcg = obj_cgroup_memcg(objcg); > > > if (memcg && mem_cgroup_is_descendant(memcg, root_memcg)) > > > return true; > > > } > > > -- > > > 2.40.0 > > > > > >
> On Apr 22, 2023, at 01:40, Roman Gushchin <roman.gushchin@linux.dev> wrote: > > KCSAN found an issue in obj_stock_flush_required(): > stock->cached_objcg can be reset between the check and dereference: > > ================================================================== > BUG: KCSAN: data-race in drain_all_stock / drain_obj_stock > > write to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0: > drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306 > refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340 > obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408 > memcg_slab_free_hook mm/slab.h:587 [inline] > __cache_free mm/slab.c:3373 [inline] > __do_kmem_cache_free mm/slab.c:3577 [inline] > kmem_cache_free+0x105/0x280 mm/slab.c:3602 > __d_free fs/dcache.c:298 [inline] > dentry_free fs/dcache.c:375 [inline] > __dentry_kill+0x422/0x4a0 fs/dcache.c:621 > dentry_kill+0x8d/0x1e0 > dput+0x118/0x1f0 fs/dcache.c:913 > __fput+0x3bf/0x570 fs/file_table.c:329 > ____fput+0x15/0x20 fs/file_table.c:349 > task_work_run+0x123/0x160 kernel/task_work.c:179 > resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] > exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171 > exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203 > __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] > syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296 > do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > read to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1: > obj_stock_flush_required mm/memcontrol.c:3319 [inline] > drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361 > try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703 > try_charge mm/memcontrol.c:2837 [inline] > mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290 > sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025 > sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525 > udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692 > udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817 > sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668 > __sys_setsockopt+0x1c3/0x230 net/socket.c:2271 > __do_sys_setsockopt net/socket.c:2282 [inline] > __se_sys_setsockopt net/socket.c:2279 [inline] > __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > value changed: 0xffff8881382d52c0 -> 0xffff888138893740 > > Reported by Kernel Concurrency Sanitizer on: > CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 > > Fix it by reading the cached_objcg with READ_ONCE(). > > Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API") > Reported-by: syzbot+774c29891415ab0fd29d@syzkaller.appspotmail.com > Reported-by: Dmitry Vyukov <dvyukov@google.com> > Link: https://lore.kernel.org/linux-mm/CACT4Y+ZfucZhM60YPphWiCLJr6+SGFhT+jjm8k1P-a_8Kkxsjg@mail.gmail.com/T/#t > Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev> Acked-by: Muchun Song <songmuchun@bytedance.com> Thanks.
On Sun, 23 Apr 2023 at 04:26, Muchun Song <muchun.song@linux.dev> wrote: > > On Apr 22, 2023, at 01:40, Roman Gushchin <roman.gushchin@linux.dev> wrote: > > > > KCSAN found an issue in obj_stock_flush_required(): > > stock->cached_objcg can be reset between the check and dereference: > > > > ================================================================== > > BUG: KCSAN: data-race in drain_all_stock / drain_obj_stock > > > > write to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0: > > drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306 > > refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340 > > obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408 > > memcg_slab_free_hook mm/slab.h:587 [inline] > > __cache_free mm/slab.c:3373 [inline] > > __do_kmem_cache_free mm/slab.c:3577 [inline] > > kmem_cache_free+0x105/0x280 mm/slab.c:3602 > > __d_free fs/dcache.c:298 [inline] > > dentry_free fs/dcache.c:375 [inline] > > __dentry_kill+0x422/0x4a0 fs/dcache.c:621 > > dentry_kill+0x8d/0x1e0 > > dput+0x118/0x1f0 fs/dcache.c:913 > > __fput+0x3bf/0x570 fs/file_table.c:329 > > ____fput+0x15/0x20 fs/file_table.c:349 > > task_work_run+0x123/0x160 kernel/task_work.c:179 > > resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] > > exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171 > > exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203 > > __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] > > syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296 > > do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86 > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > > > read to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1: > > obj_stock_flush_required mm/memcontrol.c:3319 [inline] > > drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361 > > try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703 > > try_charge mm/memcontrol.c:2837 [inline] > > mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290 > > sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025 > > sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525 > > udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692 > > udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817 > > sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668 > > __sys_setsockopt+0x1c3/0x230 net/socket.c:2271 > > __do_sys_setsockopt net/socket.c:2282 [inline] > > __se_sys_setsockopt net/socket.c:2279 [inline] > > __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279 > > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > > do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > > > value changed: 0xffff8881382d52c0 -> 0xffff888138893740 > > > > Reported by Kernel Concurrency Sanitizer on: > > CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 > > > > Fix it by reading the cached_objcg with READ_ONCE(). > > > > Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API") > > Reported-by: syzbot+774c29891415ab0fd29d@syzkaller.appspotmail.com > > Reported-by: Dmitry Vyukov <dvyukov@google.com> > > Link: https://lore.kernel.org/linux-mm/CACT4Y+ZfucZhM60YPphWiCLJr6+SGFhT+jjm8k1P-a_8Kkxsjg@mail.gmail.com/T/#t > > Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev> > > Acked-by: Muchun Song <songmuchun@bytedance.com> > > Thanks. This improves things, but strictly speaking the write side also needs WRITE_ONCE. Ordering is always a game of two. It's not possible to order things on one side, if the other side messes up the ordering.
On Sun, Apr 23, 2023 at 11:51 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Sun, 23 Apr 2023 at 04:26, Muchun Song <muchun.song@linux.dev> wrote: > > > On Apr 22, 2023, at 01:40, Roman Gushchin <roman.gushchin@linux.dev> wrote: > > > > > > KCSAN found an issue in obj_stock_flush_required(): > > > stock->cached_objcg can be reset between the check and dereference: > > > > > > ================================================================== > > > BUG: KCSAN: data-race in drain_all_stock / drain_obj_stock > > > > > > write to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0: > > > drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306 > > > refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340 > > > obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408 > > > memcg_slab_free_hook mm/slab.h:587 [inline] > > > __cache_free mm/slab.c:3373 [inline] > > > __do_kmem_cache_free mm/slab.c:3577 [inline] > > > kmem_cache_free+0x105/0x280 mm/slab.c:3602 > > > __d_free fs/dcache.c:298 [inline] > > > dentry_free fs/dcache.c:375 [inline] > > > __dentry_kill+0x422/0x4a0 fs/dcache.c:621 > > > dentry_kill+0x8d/0x1e0 > > > dput+0x118/0x1f0 fs/dcache.c:913 > > > __fput+0x3bf/0x570 fs/file_table.c:329 > > > ____fput+0x15/0x20 fs/file_table.c:349 > > > task_work_run+0x123/0x160 kernel/task_work.c:179 > > > resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] > > > exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171 > > > exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203 > > > __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] > > > syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296 > > > do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86 > > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > > > > > read to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1: > > > obj_stock_flush_required mm/memcontrol.c:3319 [inline] > > > drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361 > > > try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703 > > > try_charge mm/memcontrol.c:2837 [inline] > > > mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290 > > > sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025 > > > sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525 > > > udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692 > > > udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817 > > > sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668 > > > __sys_setsockopt+0x1c3/0x230 net/socket.c:2271 > > > __do_sys_setsockopt net/socket.c:2282 [inline] > > > __se_sys_setsockopt net/socket.c:2279 [inline] > > > __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279 > > > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > > > do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 > > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > > > > > value changed: 0xffff8881382d52c0 -> 0xffff888138893740 > > > > > > Reported by Kernel Concurrency Sanitizer on: > > > CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0 > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 > > > > > > Fix it by reading the cached_objcg with READ_ONCE(). > > > > > > Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API") > > > Reported-by: syzbot+774c29891415ab0fd29d@syzkaller.appspotmail.com > > > Reported-by: Dmitry Vyukov <dvyukov@google.com> > > > Link: https://lore.kernel.org/linux-mm/CACT4Y+ZfucZhM60YPphWiCLJr6+SGFhT+jjm8k1P-a_8Kkxsjg@mail.gmail.com/T/#t > > > Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev> > > > > Acked-by: Muchun Song <songmuchun@bytedance.com> > > > > Thanks. > > This improves things, but strictly speaking the write side also needs > WRITE_ONCE. Ordering is always a game of two. It's not possible to > order things on one side, if the other side messes up the ordering. > It looks like most other accesses use memcg_stock.stock_lock for synchronization. Based on the output of obj_stock_flush_required() we call drain_local_stock(), which acquires that lock as well. Should we refactor the code to extend the lock section to cover both obj_stock_flush_required() and drain_local_stock()? IIUC this may unify the synchronization handling and READ_ONCE/WRITE_ONCE may no longer be needed. This should also avoid any inaccuracies (e.g. unnecessary flushes) that may happen if the cached objcg changes between obj_stock_flush_required() and drain_local_stock(). Did I miss anything here?
On Mon, Apr 24, 2023 at 2:13 AM Yosry Ahmed <yosryahmed@google.com> wrote: > > On Sun, Apr 23, 2023 at 11:51 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > On Sun, 23 Apr 2023 at 04:26, Muchun Song <muchun.song@linux.dev> wrote: > > > > On Apr 22, 2023, at 01:40, Roman Gushchin <roman.gushchin@linux.dev> wrote: > > > > > > > > KCSAN found an issue in obj_stock_flush_required(): > > > > stock->cached_objcg can be reset between the check and dereference: > > > > > > > > ================================================================== > > > > BUG: KCSAN: data-race in drain_all_stock / drain_obj_stock > > > > > > > > write to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0: > > > > drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306 > > > > refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340 > > > > obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408 > > > > memcg_slab_free_hook mm/slab.h:587 [inline] > > > > __cache_free mm/slab.c:3373 [inline] > > > > __do_kmem_cache_free mm/slab.c:3577 [inline] > > > > kmem_cache_free+0x105/0x280 mm/slab.c:3602 > > > > __d_free fs/dcache.c:298 [inline] > > > > dentry_free fs/dcache.c:375 [inline] > > > > __dentry_kill+0x422/0x4a0 fs/dcache.c:621 > > > > dentry_kill+0x8d/0x1e0 > > > > dput+0x118/0x1f0 fs/dcache.c:913 > > > > __fput+0x3bf/0x570 fs/file_table.c:329 > > > > ____fput+0x15/0x20 fs/file_table.c:349 > > > > task_work_run+0x123/0x160 kernel/task_work.c:179 > > > > resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] > > > > exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171 > > > > exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203 > > > > __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] > > > > syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296 > > > > do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86 > > > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > > > > > > > read to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1: > > > > obj_stock_flush_required mm/memcontrol.c:3319 [inline] > > > > drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361 > > > > try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703 > > > > try_charge mm/memcontrol.c:2837 [inline] > > > > mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290 > > > > sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025 > > > > sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525 > > > > udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692 > > > > udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817 > > > > sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668 > > > > __sys_setsockopt+0x1c3/0x230 net/socket.c:2271 > > > > __do_sys_setsockopt net/socket.c:2282 [inline] > > > > __se_sys_setsockopt net/socket.c:2279 [inline] > > > > __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279 > > > > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > > > > do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 > > > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > > > > > > > value changed: 0xffff8881382d52c0 -> 0xffff888138893740 > > > > > > > > Reported by Kernel Concurrency Sanitizer on: > > > > CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0 > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 > > > > > > > > Fix it by reading the cached_objcg with READ_ONCE(). > > > > > > > > Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API") > > > > Reported-by: syzbot+774c29891415ab0fd29d@syzkaller.appspotmail.com > > > > Reported-by: Dmitry Vyukov <dvyukov@google.com> > > > > Link: https://lore.kernel.org/linux-mm/CACT4Y+ZfucZhM60YPphWiCLJr6+SGFhT+jjm8k1P-a_8Kkxsjg@mail.gmail.com/T/#t > > > > Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev> > > > > > > Acked-by: Muchun Song <songmuchun@bytedance.com> > > > > > > Thanks. > > > > This improves things, but strictly speaking the write side also needs > > WRITE_ONCE. Ordering is always a game of two. It's not possible to > > order things on one side, if the other side messes up the ordering. > > > > It looks like most other accesses use memcg_stock.stock_lock for > synchronization. Based on the output of obj_stock_flush_required() > we call drain_local_stock(), which acquires that lock as well. Should > we refactor the code to extend the lock section to cover both > obj_stock_flush_required() and drain_local_stock()? > > IIUC this may unify the synchronization handling and > READ_ONCE/WRITE_ONCE may no longer be needed. This should also avoid > any inaccuracies (e.g. unnecessary flushes) that may happen if the > cached objcg changes between obj_stock_flush_required() and > drain_local_stock(). > > Did I miss anything here? Yes, drain_local_stock only works on local cpu and obj_stock_flush_required can touch the stock of all the cpus. The patch is good but I agree with Dmitry that we should add the WRITE_ONCE as well.
On Mon, Apr 24, 2023 at 10:10 AM Shakeel Butt <shakeelb@google.com> wrote: > > On Mon, Apr 24, 2023 at 2:13 AM Yosry Ahmed <yosryahmed@google.com> wrote: > > > > On Sun, Apr 23, 2023 at 11:51 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > > > On Sun, 23 Apr 2023 at 04:26, Muchun Song <muchun.song@linux.dev> wrote: > > > > > On Apr 22, 2023, at 01:40, Roman Gushchin <roman.gushchin@linux.dev> wrote: > > > > > > > > > > KCSAN found an issue in obj_stock_flush_required(): > > > > > stock->cached_objcg can be reset between the check and dereference: > > > > > > > > > > ================================================================== > > > > > BUG: KCSAN: data-race in drain_all_stock / drain_obj_stock > > > > > > > > > > write to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0: > > > > > drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306 > > > > > refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340 > > > > > obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408 > > > > > memcg_slab_free_hook mm/slab.h:587 [inline] > > > > > __cache_free mm/slab.c:3373 [inline] > > > > > __do_kmem_cache_free mm/slab.c:3577 [inline] > > > > > kmem_cache_free+0x105/0x280 mm/slab.c:3602 > > > > > __d_free fs/dcache.c:298 [inline] > > > > > dentry_free fs/dcache.c:375 [inline] > > > > > __dentry_kill+0x422/0x4a0 fs/dcache.c:621 > > > > > dentry_kill+0x8d/0x1e0 > > > > > dput+0x118/0x1f0 fs/dcache.c:913 > > > > > __fput+0x3bf/0x570 fs/file_table.c:329 > > > > > ____fput+0x15/0x20 fs/file_table.c:349 > > > > > task_work_run+0x123/0x160 kernel/task_work.c:179 > > > > > resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] > > > > > exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171 > > > > > exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203 > > > > > __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] > > > > > syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296 > > > > > do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86 > > > > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > > > > > > > > > read to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1: > > > > > obj_stock_flush_required mm/memcontrol.c:3319 [inline] > > > > > drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361 > > > > > try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703 > > > > > try_charge mm/memcontrol.c:2837 [inline] > > > > > mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290 > > > > > sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025 > > > > > sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525 > > > > > udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692 > > > > > udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817 > > > > > sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668 > > > > > __sys_setsockopt+0x1c3/0x230 net/socket.c:2271 > > > > > __do_sys_setsockopt net/socket.c:2282 [inline] > > > > > __se_sys_setsockopt net/socket.c:2279 [inline] > > > > > __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279 > > > > > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > > > > > do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 > > > > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > > > > > > > > > value changed: 0xffff8881382d52c0 -> 0xffff888138893740 > > > > > > > > > > Reported by Kernel Concurrency Sanitizer on: > > > > > CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0 > > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 > > > > > > > > > > Fix it by reading the cached_objcg with READ_ONCE(). > > > > > > > > > > Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API") > > > > > Reported-by: syzbot+774c29891415ab0fd29d@syzkaller.appspotmail.com > > > > > Reported-by: Dmitry Vyukov <dvyukov@google.com> > > > > > Link: https://lore.kernel.org/linux-mm/CACT4Y+ZfucZhM60YPphWiCLJr6+SGFhT+jjm8k1P-a_8Kkxsjg@mail.gmail.com/T/#t > > > > > Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev> > > > > > > > > Acked-by: Muchun Song <songmuchun@bytedance.com> > > > > > > > > Thanks. > > > > > > This improves things, but strictly speaking the write side also needs > > > WRITE_ONCE. Ordering is always a game of two. It's not possible to > > > order things on one side, if the other side messes up the ordering. > > > > > > > It looks like most other accesses use memcg_stock.stock_lock for > > synchronization. Based on the output of obj_stock_flush_required() > > we call drain_local_stock(), which acquires that lock as well. Should > > we refactor the code to extend the lock section to cover both > > obj_stock_flush_required() and drain_local_stock()? > > > > IIUC this may unify the synchronization handling and > > READ_ONCE/WRITE_ONCE may no longer be needed. This should also avoid > > any inaccuracies (e.g. unnecessary flushes) that may happen if the > > cached objcg changes between obj_stock_flush_required() and > > drain_local_stock(). > > > > Did I miss anything here? > > Yes, drain_local_stock only works on local cpu and > obj_stock_flush_required can touch the stock of all the cpus. Oh right, for other cpus this is infeasible as we schedule the work to be done later. > > The patch is good but I agree with Dmitry that we should add the > WRITE_ONCE as well. Agreed. I guess WRITE_ONCE will be needed in multiple places that update the cached objcg. Thanks.
diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 5abffe6f8389..9426a1ddc190 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -3314,10 +3314,11 @@ static struct obj_cgroup *drain_obj_stock(struct memcg_stock_pcp *stock) static bool obj_stock_flush_required(struct memcg_stock_pcp *stock, struct mem_cgroup *root_memcg) { + struct obj_cgroup *objcg = READ_ONCE(stock->cached_objcg); struct mem_cgroup *memcg; - if (stock->cached_objcg) { - memcg = obj_cgroup_memcg(stock->cached_objcg); + if (objcg) { + memcg = obj_cgroup_memcg(objcg); if (memcg && mem_cgroup_is_descendant(memcg, root_memcg)) return true; }