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 90C49C4332F for ; Tue, 13 Dec 2022 01:47:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1C38E8E0003; Mon, 12 Dec 2022 20:47:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 173788E0002; Mon, 12 Dec 2022 20:47:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 062928E0003; Mon, 12 Dec 2022 20:47:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E72698E0002 for ; Mon, 12 Dec 2022 20:47:32 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B8CB41C3D26 for ; Tue, 13 Dec 2022 01:47:32 +0000 (UTC) X-FDA: 80235595944.13.0180AC7 Received: from r3-20.sinamail.sina.com.cn (r3-20.sinamail.sina.com.cn [202.108.3.20]) by imf13.hostedemail.com (Postfix) with ESMTP id 6D05D2000B for ; Tue, 13 Dec 2022 01:47:30 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.20 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670896051; a=rsa-sha256; cv=none; b=onxacZY8Tiwjtexpa9+Lc4or2Byjn4CweRqZy+9mj52aTzHzQA7F7si6pLXz60NpReOEIL n+ZjjgGeyrr/031iXhNcOmE+WExpB5AnaLhfYKy2P7lvayJcbj8aOKGrpPXzQhScdUdILk +3cJVxMcChuZWiDZs+7EwucjwdyMjtQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf13.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.20 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670896051; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=M+VZ2DKPNuFQPuySYs6MiIWXuT9SMFI5wP+8kKXrKlg=; b=Qpja5rFs1Ie2IS9AM0mTRxwevZHRGdD5+8h79d1ZfWShzDiOOAF5wy8CT55BdTQ5FbmTBF 8GDdEkun6VMDOAbsk8pnBWGWecwF8/+ZhXiMCiuvF03oAy7ui8rp5iO9rtivpF0M1PcqgU MBTlIYFIXSuf+u3brdKrTePay0MEvho= Received: from unknown (HELO localhost.localdomain)([114.249.57.238]) by sina.com (172.16.97.35) with ESMTP id 6397D902000285E2; Tue, 13 Dec 2022 09:44:36 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 21271015074439 From: Hillf Danton To: "Theodore Ts'o" Cc: Matthew Wilcox , Al Viro , syzbot , linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] WARNING in do_mkdirat Date: Tue, 13 Dec 2022 09:47:16 +0800 Message-Id: <20221213014716.3347-1-hdanton@sina.com> In-Reply-To: References: <20221211002908.2210-1-hdanton@sina.com> <00000000000025ff8d05ef842be6@google.com> <20221211075612.2486-1-hdanton@sina.com> <20221211102208.2600-1-hdanton@sina.com> <20221212032911.2965-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 6D05D2000B X-Stat-Signature: wyi7gc7b3e5obi6gspuzxgh9pk74efbb X-HE-Tag: 1670896050-694652 X-HE-Meta: U2FsdGVkX1+DIFzo7Nr+6tHSK9nCoFQ3Uk6oGMfK8iSY5M6qQyb1YNzYZ0AzTsA3BqZ044wNikUIb5XDLNOSJp7z1v314jVYp45RGSEMGC73L7uO2k24+I6KNz0BaTofyvHI8FMo8G1Co9YSWkKNiump4kjIOkycqPwiL0IfJR1qGlcM2XEwzIU+HMb/u/KZ+VN+dHAQFRjaHPtuxp8HwwDefA7k4FRdcYRWnBObxw2O9JdW8Fibv6ZUfIxsSi2+B2fa/2orept4hANdk2CV5Y1tBX7IFYN6ZJOQn1SYMoFF5EaQlSOK0LQFQnGgxuBIRXBmNO/5a64hVNwCojEwuQpsH390QUqg1o3iHUh9sVRb7uIir9tBA//fNSWHsl4cvtwJuWuq0ox3nOXdc7M5hdlXWnxMHFJT+xlg2BwmA8eUZk4TMGBB7zYjfMhxuPXbYmsFlJIO5dg6/t9UOd9uY1WVFLDHTio4+e8S4YWOwpz2V6GBNO/g6K8ObVEkozC8eQ3YrfYuRmgx5bJnZZq6gI+NsVBpOF6xRNRbcPvc+KGopyVdYBphFYFcHslSRTjyLsfyBrE6Im/q74epDScNpKzBUcz3B64Ek0lyYXVnU2Ey82fUMRAWtrNvWCQf2JMGs/ZJvjftcNxXxIPvxhyf5osIeskEiQFY4PLUw9EB4BiPhHN2gsUa1peRv6dHXmnR/MVCDdlVhZqaCi5ISNPhJe0grS6bZdRVTJ1ckM8rLFQPE1w7+Zn8EA83FzJpsY2bnJCuV1K9yQm7+eIJMq21Qf2y6QBd1Ut0wemXuUj74ffxNPZRbRj+ioV6NRp1qF9ZW7Wqy93lF1r4vLjDIZ8M5tC1IKqG92OflJBUIh3E2o62HlGPbVSq9hdpxTJhxBENYruqg3jmpL+8P/nbCK5KcNd+oHI7l/nSw89ZKHF35nQ9DQtIqTq9sbmLCslTBQ8z 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: On 12 Dec 2022 13:58:51 -0500 Theodore Ts'o > On Mon, Dec 12, 2022 at 11:29:11AM +0800, Hillf Danton wrote: > > > You've completely misunderstood Al's point. He's not whining about > > > being cc'd, he's pointing at this is ONLY USEFUL IF THE NTFS3 > > > MAINTAINERS ARE CC'd. And they're not. So this is just noise. > > > And enough noise means that signal is lost. > > > > Call Trace: > > > > inode_unlock include/linux/fs.h:761 [inline] > > done_path_create fs/namei.c:3857 [inline] > > do_mkdirat+0x2de/0x550 fs/namei.c:4064 > > __do_sys_mkdirat fs/namei.c:4076 [inline] > > __se_sys_mkdirat fs/namei.c:4074 [inline] > > __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4074 > > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > > do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 > > entry_SYSCALL_64_after_hwframe+0x63/0xcd > > > > Given the call trace above, how do you know the ntfs3 guys should be also > > Cced in addition to AV? What if it would take more than three months for > > syzbot to learn the skills in your mind? What is preventing you routing > > the report to ntfs3? > > If it takes 3 months for syzbot to take a look at the source code in > their own #!@?! reproducer, or just to take a look at the strace link > in the dashboard: > > [pid 3639] mount("/dev/loop0", "./file2", "ntfs3", MS_NOSUID|MS_NOEXEC|MS_DIRSYNC|MS_I_VERSION, "") = 0 > > There's something really wrong. The point Al has been making (and > I've been making for multiple years) is that Syzbot has the > information, but unfortunately, at the moment, it is only analyzing > the the stack trace, and it is not doing things that really could be > done automatically --- and cloud VM time is cheap, and upstream Another case of easy talk instead of patching hard? What is preventing you from making the syzbot more automatic? Is it sane to teach the bot to patch ext4 because you are a maintainer? > maintainer time is expensive. So by not improving syzbot in a way > that really shouldn't be all that difficult, the syzbot maintainers is > disrespectiving the time of the upstream maintainers. Are upstream maintainers prefering to spend weeks and months creating ext4 beatles for example over taking a couple of hours scanning the syzbot reports like this one? Why does the bot kick you if you have a clean butt? Why are usb people irrelevant in this case? > > So sure, we could ask Linus to triage all syzbot reports --- or we > could ask Al to triage all syzbot file system reports --- but that is > not a good use of upstream resources. Lolll who is preventing you from doing so? Who care/complain if you do? Why not directly fix today what was reported instead and issue a PR?