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 0DB31C4332F for ; Mon, 12 Dec 2022 03:29:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 07C648E0003; Sun, 11 Dec 2022 22:29:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 003C28E0002; Sun, 11 Dec 2022 22:29:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE6798E0003; Sun, 11 Dec 2022 22:29:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CB1108E0002 for ; Sun, 11 Dec 2022 22:29:29 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 97B58AAE17 for ; Mon, 12 Dec 2022 03:29:29 +0000 (UTC) X-FDA: 80232224058.12.D7AAB08 Received: from mail3-162.sinamail.sina.com.cn (mail3-162.sinamail.sina.com.cn [202.108.3.162]) by imf25.hostedemail.com (Postfix) with ESMTP id 7F04FA0003 for ; Mon, 12 Dec 2022 03:29:26 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf25.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.162 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=1670815768; 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=BplLguwjkslRoGPzyGySEocqkex1dTKhTux701Eok/E=; b=Pq5O17dADJSyu1WVR/GEAtquZbhKZQ4tffYCakHABgCSv94sUoKSveeKLTpsiIP6QZuEpN yqNKK1tXhOO9sUmVYbVgJUkYRxr+hoxZSdvmfRlptI40LBB05oD0w+eRmAVmvbACcdit52 Qs8EgKe+4vZkGkQZwSBXlGDsZG0tMzI= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf25.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.162 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670815768; a=rsa-sha256; cv=none; b=e0dcAUTS0zsnl7aF0Bju8GWio5kG+Y3fr2JClsewGLGbvmKvPYv+kLI68eDoBq0pN0eLPr pXATiV7jz2Oa7qmtdgb1sJDWvJz7dbk2HuiFkEYK8X8Boa3grr7JdY5wDH8OBV495O2Yby aHhnaxIcwiRfED3r1YpRWzwqZ/9+Gbo= Received: from unknown (HELO localhost.localdomain)([114.249.57.238]) by sina.com (172.16.97.27) with ESMTP id 63969FBD00025040; Mon, 12 Dec 2022 11:27:59 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 2433249291700 From: Hillf Danton To: Matthew Wilcox Cc: Al Viro , syzbot , linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] WARNING in do_mkdirat Date: Mon, 12 Dec 2022 11:29:11 +0800 Message-Id: <20221212032911.2965-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> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7F04FA0003 X-Stat-Signature: h8hnr6hyh816j7ui3prced1rhsky7fti X-HE-Tag: 1670815766-249666 X-HE-Meta: U2FsdGVkX192P2h/H9vRmxcy5wBTc2v354iFIToY4AV328vzAguhtnrVcwRdSJEcTBQAGAissn+d3l143otbmJ9xc2GvtnXqUk68J7UG3nmCXeuLWYq4tiz3+EH9AsLg+iA3AVqI6XkDZr8C0T3+7w+8qEbwZAlH00AC0ygoYDuCcNM3irrMS08pg+69fCGT/S7xys6SMQhhpNIXqnvQfiTRrodxe4aUf+0OHpcyjNQkoQf9LOHPnu+duJdTAvtYJJD5jTPhx7YUgi8KHliAR+DzRAn8TLNzhwBySviVv1rlDK3yOhGJUUXzNaz1mcJswYJbgHoIc+t+X5Yvys0LvnyYNauWkaMDiiC5N8/7adUGoGls9bXpC+4tS+Xyo6TQklbjixcDR6WNg/U6pJlra73o6fNK7TtD6sRycgdhJdoViTbIVBnL7jh18e2xVm5yZdCoTlAvEKBK28DLiFWy/rcJhfTi+obA6uGucWCjeVsW2AQjM+2IVp3Fr0Q25isIaI+qEO6RXyNcT7/qruyKYGQNZi6F3SPHyYtQX0s7bXenAcd7Il5MlFUNvgKtxeNHrmyvVz9tclL9enhIejhpJ7wY45w8dtKjlg7ClQUX9FI/azqXfrnE5IYX0cvYXSN0pTFa8brNFLT7DTlgy7B+PhP5b4JdoBbQtc22x0OKXKuOTa5CYw8Cxq9Erz68+n/N4EYea+KwjHrxb3hJzuxY6ShWYqw243U6GhTqaJ/0iE3Bv+bqBqa5e8CETL1IgYLTiU6/91jN+bwYUPrT70UrAhVMMY+gRdoJVRTKU9hPQmKik8fXgENpXsjsPkVWAlW/DRszZqw6v0Dzl08929jw4SDx5VyfOkdwj9bVe3byQJuLSR2hDcwu5mJPl6Ll/h5so245b1eziIK+hMOdhl1bmKCLNpf8eDrp/OhM2XHQBwjmuySs1RRxjDl6U8gac1L3 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 11 Dec 2022 15:46:12 +0000 Matthew Wilcox > On Sun, Dec 11, 2022 at 06:22:08PM +0800, Hillf Danton wrote: > > On 11 Dec 2022 08:39:18 +0000 Al Viro > > > On Sun, Dec 11, 2022 at 03:56:12PM +0800, Hillf Danton wrote: > > > > On 11 Dec 2022 02:52:57 +0000 Al Viro > > > > > On Sat, Dec 10, 2022 at 06:30:22PM -0800, syzbot wrote: > > > > > > Hello, > > > > > > > > > > > > syzbot has tested the proposed patch but the reproducer is still triggering an issue: > > > > > > WARNING in done_path_create > > > > > > > > > > How many times does it need to be repeated that ANY BUG REPORTS INVOLVING NTFS3 IN > > > > > REPRODUCER NEED TO BE CCED TO MAINTAINERS OF NTFS3? > > > > > > > > > > I'm done with any syzbot output. From now on it's getting triaged > > > > > straight to /dev/null here. > > > > > > > > Calm downnnnnn Sir even if this is not the east ender style. > > > > > > > > Frankly no interest here at all wasting any network bandwidth just to get you > > > > interrupted if it would take less than 72 hours to discover one of the beatles > > > > you created. And actually more than double check is needed to ensure who > > > > did that. > > > > > > The first iterations of the same suggestion had been a lot calmer... > > > One of the earlier examples: https://lore.kernel.org/all/YzEJ2D8kga+ZRDZx@ZenIV/ > > > And I distinctly remember similar attempts from other folks. > > > > > > It's really a matter of triage; as it is, syzkaller folks are > > > expecting that any mail from the bot will be looked into by everyone > > > on fsdevel, on the off-chance that it's relevant for them. What's > > > > FILESYSTEMS (VFS and infrastructure) > > M: Alexander Viro > > L: linux-fsdevel@vger.kernel.org > > S: Maintained > > F: fs/* > > F: include/linux/fs.h > > F: include/linux/fs_types.h > > F: include/uapi/linux/fs.h > > F: include/uapi/linux/openat2.h > > > > _> ls fs/* | grep ntfs > > fs/ntfs: > > ntfs.h > > fs/ntfs3: > > fsntfs.c > > ntfs.h > > ntfs_fs.h > > > > Why not change what you really want to cover instead of complaining once more > > and opting to triage? > > 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?