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 EF74DC4332F for ; Sun, 11 Dec 2022 10:22:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E2CBC8E0003; Sun, 11 Dec 2022 05:22:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DDC758E0001; Sun, 11 Dec 2022 05:22:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CCB348E0003; Sun, 11 Dec 2022 05:22:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id BA8E68E0001 for ; Sun, 11 Dec 2022 05:22:26 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8837B802CD for ; Sun, 11 Dec 2022 10:22:26 +0000 (UTC) X-FDA: 80229635892.07.2F7F8DB Received: from r3-19.sinamail.sina.com.cn (r3-19.sinamail.sina.com.cn [202.108.3.19]) by imf21.hostedemail.com (Postfix) with ESMTP id 6C19D1C0010 for ; Sun, 11 Dec 2022 10:22:23 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf21.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.19 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=1670754144; 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=c3N1TeCkHzD/7E4y9zuLxP0sZwGFbLecCd6Y3XJ4RBI=; b=7XbznlTOo2GPuVO6EcjbacY1G0wGJj4XXMdvstKWAjfPlJCL4sc1f17U1GLrrbDjA5XKD0 Kpgjf6TvbTR/cHY4JEimLp8pRPDRxbBIZsUlcxNHfN6Mu5LHNLtC+/sC+HVU0bvoKsvIYX xMiTXYgYRw3BExEx70cV8XcnIPY1IK8= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf21.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.19 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670754144; a=rsa-sha256; cv=none; b=BN8OUmGTqQndespFeknDkhpfNXwXSorJMsSdfGhDcOIgARkCOc8vSaF34Zw7JrlyTyZQvT 2qHPvyUrhJN/cz7dxLZiMIonCoV9tQG4QAd0kXNnWGTL4qh30112IXCfwafUmtcscoAmvS nGqOQVPM9dsaLG9GxMtGwiJWk9gmPiY= Received: from unknown (HELO localhost.localdomain)([114.249.57.238]) by sina.com (172.16.97.35) with ESMTP id 6395AEB100032D93; Sun, 11 Dec 2022 18:19:30 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 93215215073524 From: Hillf Danton To: Al Viro Cc: syzbot , linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] WARNING in do_mkdirat Date: Sun, 11 Dec 2022 18:22:08 +0800 Message-Id: <20221211102208.2600-1-hdanton@sina.com> In-Reply-To: References: <20221211002908.2210-1-hdanton@sina.com> <00000000000025ff8d05ef842be6@google.com> <20221211075612.2486-1-hdanton@sina.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 6C19D1C0010 X-Rspam-User: X-Stat-Signature: dj3qoh575u4pbjjw48fy84gp9mcpfe5z X-HE-Tag: 1670754143-998042 X-HE-Meta: U2FsdGVkX18NQkUXGoWCXZb2OUu6gdXmCQJe/tAW1ghF/K56AAN7F99fiqpliFNordfDP0Gb/or1lKqY4esDZkphBRViYf0EiPAyQOz6lbIHKlExUWIbW8JxfvoDkPGyHHjZV7oog1kRfieatZkZNUVxVEGKzvMUvGmkIJd69YGyHB8vSDqhHLLNqdP+qOMSdtuAWAlZNqS9z9CoYIj0iiuJfXbQYMk3wMRdOrMXTMY274H42jeVp0lFJpOR6Gw4IcK93zO6srUaBZ/BOUVZZjRA4SuAIUgubZOrjyttbPiwgrplZM9Rb/9Q/FIJ0zl7rBKVE7hXHqWzYa+v2JnVx7bBWzqfEWqdLO/iOo0IUjsi9IhZv5Zz8Z1FL10SyB/+JPDZmdiJ1iouOZVLnqwLqB4mCUBR76YBi14rgnyf8F+fFg3hfjX4ftpcVW05ERXhEIsGXIu4zemPHj73gUn82SFwxeo2eJPpNKitMVay4Ip8TqC/JentEjJLLzZYjG5n0zeDS9IqDkz8CMHJhgZC2RMOyRnXeeJ5WPqx3imptL1006WJPxp1DPAQPqBKmnvieNxsSGXIrRPimJSizsskVX5VSfd0xSYB49ySEjORW+C+ZlvsBrgARgWp4XeguJoEKbtm4xQPaxpktc368AfLO1816cJky6cmmTd0pG5ZEC3YK9mstYdmB2KT+X++sOgDmc/x2hg/UNLXQ5Ee5rbYrDDTUqyoYxmqy62swByFa29MQDoV0pftJnbMt3aIw3Mrl+HGhNItAlccvwwaYl13+roEJboqVtOgRKyfw19YFEEDdwwBNAcgIIJhJUE8YmteVadXkFCGED7MU4JfjEX1ZtFyHMcIHndgOreq1/Ec0GljqS787aJeUbI8AbrQbP4YBoYCR1Zlf91trZVypvgs8wpMdpmMFUle8PvGQrBiSBhuW6cnJ39YnCVU+OibUKfx X-Bogosity: Ham, tests=bogofilter, spamicity=0.000590, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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? > more, it's not just "read the mail" - information in the mail body > is next to useless in such situations. So you are asking to > * start a browser > * cut'n'paste the URL from MUA > * dig around in the files linked to the damn thing > ... all of that for an fs maintainer to see if his filesystem is > even present? Seriously? For each syzbot fsdevel posting? > > I would have looked at it anyway; granted, seeing ntfs3 I'd chalked > it up to ntfs bugs (fs/ntfs3 has not been there for long and it didn't get > outright memory corruptors beaten out of it yet). > > But how the bleeding hell are ntfs folks supposed to guess that > this report might be relevant for them? Same for XFS, ext4, orangefs, > et sodding cetera - and for most of those any of such reports would've > ended up wasted time for the good and simple reasons that it's not > any fs they'd been involved with. > > What really pisses me off is that on the sending side the > required check is trivial - if you are going to fuzz a filesystem, > put a note into report, preferably in subject. Sure, it's your > code, you get to decide what to spend your time upon (you == syzkaller > maintainers). But please keep in mind that for recepients it's > a lot of recurring work, worthless for the majority of those who > end up bothering with it. Every time they receive a mail from > that source. > > Ignore polite suggestions enough times, earn a mix of > impolite ones and .procmailrc recipes, it's that simple... >