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 BF914C46467 for ; Tue, 3 Jan 2023 13:37:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EAF018E0002; Tue, 3 Jan 2023 08:37:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E5F5D8E0001; Tue, 3 Jan 2023 08:37:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D00D28E0002; Tue, 3 Jan 2023 08:37:06 -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 BD7588E0001 for ; Tue, 3 Jan 2023 08:37:06 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8748840AAA for ; Tue, 3 Jan 2023 13:37:06 +0000 (UTC) X-FDA: 80313588852.07.2C5726B Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) by imf24.hostedemail.com (Postfix) with ESMTP id 07178180002 for ; Tue, 3 Jan 2023 13:37:03 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=SpOfI22J; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of nogikh@google.com designates 209.85.217.54 as permitted sender) smtp.mailfrom=nogikh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672753024; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/ZC/4CfEoCP84h65P9/vsWymefu0+WCG960hCYZnBdU=; b=L3INrjnBXIRskB8LvEhQdlV9sNkupBep3U8VO6+Fnh9KSIcvxpLJEu4HMBwqgbbQK8Y44P 6uYLAakJF+IANgzx2nHBJiCf+dmciwmMiM2yn698E9/3peHkkRj0SCWwPvDlYaRU5cJdBs iqhPqGyRmEnTQOC0eiAGdA22ejG4CGk= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=SpOfI22J; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of nogikh@google.com designates 209.85.217.54 as permitted sender) smtp.mailfrom=nogikh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672753024; a=rsa-sha256; cv=none; b=pAntnZF/DWqBrY7FFooXpybZ78190IWgYrGMoyehcTfWKyak4Pmmh6vrO07B0vNro5kmPq 1GkDVXV1YE2Z15sThEA7LjaE+g3zncwuNLq0Fxt+P5n8d+MF1ALDEKryTQZMKR2d5qyMqZ 586VkwsVtfZp+ZOF4T4l61r67yHUuzk= Received: by mail-vs1-f54.google.com with SMTP id o63so26910163vsc.10 for ; Tue, 03 Jan 2023 05:37:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/ZC/4CfEoCP84h65P9/vsWymefu0+WCG960hCYZnBdU=; b=SpOfI22JH24uzwGva6MCBxzoPptM8baY9coyGpfLyvdNThWVHri3dfmcr5GksM1Tew KLOivj+8Ejk1YPH2PQHIMGgntIsBnMsIfNyGA8dNFQwzANFJUR3LZDh8YVV44EmoT+Dk Db34YdqsMZMry9s6rKZJM/IQWmW7BI7yug+jEaCceo7LI/iTC49NrJiNNqeB2P1C4lnI vqmFgyKYWqJhJh2z96N0OZNR8fov1w4XQeGy2gc3ZMSCBLpQwhWyK7zPDFSs4lpPwP5R EciZjeIl0HWtYVKoO4/E+hakt+Fvj7kbsCova8CPF+UmJMK4akhIXZlM4GS07I6ETbde rn7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/ZC/4CfEoCP84h65P9/vsWymefu0+WCG960hCYZnBdU=; b=JuVY/sxqd6JH4Gc6mWtqph5sCcZ+iMTDEVtjGfXO4THsBzFciBqSphQsTcOjWVH0RA u5PrsADZUPpcqQe+m262gBAmsZsf4/Ip6oG9sHYOIc0OIzy/ZFDaMvRwgp+rANObIhi6 iqvd9tvS8xnZq+XaTphojFO5Zc/DxYhxbMJVWTsr6iN/zFSLg4408VDFtm4wfWSN1eFZ mZwShWyNjpaIwWLNgClVP9sOKsF2q1Tcff0RS8N+epr/3lc08X1oFv6o1K1Ttd/l+3Dd wFicV3ovkF69Vkm++uKg3+iq0b7Le8SIVISWAE94idtN3dTFAF6LIaOWjGvhG8BFr9IU 2UMQ== X-Gm-Message-State: AFqh2kpTjd6cURLlCVnPlQC15LVu/LNsYCzAQDMCLHnRsJf0Gbu9Gr62 Kvhl3p0ybzhh2S9Ph9u/9qZ3tF1lHjhWTB3EJ6/1gA== X-Google-Smtp-Source: AMrXdXszcryYqU11zWEiwxmncWD5vTxNtQqq6xqhBf+tGjHDmFPG1fbVdWHTLbCfd9SQIH5+bCo8uE0LpSghpN36afs= X-Received: by 2002:a67:f642:0:b0:3c4:ec4b:b943 with SMTP id u2-20020a67f642000000b003c4ec4bb943mr4907800vso.17.1672753023001; Tue, 03 Jan 2023 05:37:03 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Aleksandr Nogikh Date: Tue, 3 Jan 2023 14:36:51 +0100 Message-ID: Subject: Re: [syzbot] WARNING in do_mkdirat To: "Theodore Ts'o" Cc: Eric Biggers , Al Viro , Marco Elver , Hillf Danton , Matthew Wilcox , syzbot , linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, Taras Madan Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 07178180002 X-Stat-Signature: krxar836mjfnb16zcynir5orqhjpcy4m X-HE-Tag: 1672753023-97493 X-HE-Meta: U2FsdGVkX19fehmtMORBFSagsiSJ/S1c9hjkE/8HWnK3FE2n2cLvH3y5mz+/IbZcc2FlJMTOMVt1unwYd/Wh4HNYLgKz7YCCy4wNg5XyNa34yTqvR0HbLGbUKpdP8q+SG0GJ2knQQ/MaZ527w6Xw5RaZOFWcpiJFQdFYz9EuMNrVOvqMwHDfGHWSRAqFigKeZ3r/9OUSt0nGwg3cEJ5RYG6h6fSmTr0y7XxgP0Mc7/1Let9gtnM6kwIebjgYRXduvPe4egdcioRMQZdLpNWWWgclyHDSlECieM25w1Ip0FbD4h6L9BxPDvJdX+XnZkutQcbVw98Spm4ra/wzOt17gteQz4JpQwgxdc1GLVEs7BQGubCm18koE+lpIfKOL9IzWA3brDvwzOC8zSF0961hWSf3ZFBRpgtpMI7PzeI1AnTEvXeD5DvPwM+JPdLsbIxqgGj+LdbkQIcCu/0WIo0J4J/4Uh4mO1CCFoE4jErosCQwOPvhXFFKxiCWihKGeH6h54u0lC/WDYujntm8+xWzg1xce9ym4PJg+oDLJBh9/PI2OfJi61ca1Qqm4pAF2ZNgHbz+arkV9QZcZcMvffWLMMrvjqCwERBTb9+Mk2z7afpx9hWAGRR4IVXShRWABfoCo4icVP0YPRBzNvIBf99cclVO9FRTIIbW5YgeAH6wdXaUwImbMBw+XW2FVNRnRXCHHoLKY3y/6qxnFhLMdtd2g8P+JVzBsNi8mxKxAaGsDenZ/6OFaKaf2iO0wblVa42zgldqLbcpXCGe7oW5Zp/WAI1QHEYPjX/W9nayQ36PpH1DmMrPcMpqbj2Dp6dMh16cChhcG7rOS10kKhrXTQdS3mFgpasY6AArOjbDpOOszkcuobO6tV9a3AHfSSRTqVcFvC3vB4pPiKxMmKAZrHBxjevkr1355EKHqv2p0/hAozgQzXDyIxdDMHsz77C5fDS4W46xqDnt4kPT4o7fRUU wfqqHQwW hkABKohebYCvlCxr9BcYzgS586w5HbQBwTJY2utPaqNbw33tJVpe6VC45zqvkex5junhVdpDWLLmaYU5gGabT/7ERBWZU2U7AD01D+7hj58deZH+lMShAY1VAN5b1EsZDGuFO+kWNHmDBLjgXfbTKeAEM63OFKQaysjHA 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: Hi Eric, Ted, On Sat, Dec 31, 2022 at 5:58 PM Theodore Ts'o wrote: > > On Thu, Dec 29, 2022 at 01:17:31PM -0800, Eric Biggers wrote: > > Thanks Aleksandr. From what I can see, the fix is working for new filesystem > > bugs: the filesystem(s) involved get added to the title and the recipients. > > > > One question: what happens to all the open bugs, like this one ("WARNING in > > do_mkdirat") that were reported before the syzbot fix? Are they going to be > > re-reported correctly? Perhaps any bug whose reproducer includes > > "syz_mount_image" and was reported before the date of this fix should be > > invalidated more aggressively than usual, so that it can be re-reported? I fear that the community will not be super excited to see those tons of fs bug reports again :) Soon it'll become possible to see the subsystems on the dashboard and to filter bugs based on them, hopefully this will help those bugs not get completely lost. > > As a related request/wish, it would be nice if those dashboard pages > that were created before the new-style reporting which includes the > file system image, strace otuput, etc., could get regenerated. For example: > > https://syzkaller.appspot.com/bug?id=be6e90ce70987950e6deb3bac8418344ca8b96cd I've deployed the change -- now it should display all the download links on the bug info page. If we have reported a download link / strace log in an email, it should be there. For yet older bugs, it's trickier. We regenerate reproducers once in 100 days, so if the old bugs keep on happening, the information will appear there over time as well. > > Even if someone has already submitted a proposed fix, I often like to > double-check that the fix is really fixing the true root cause of the > problem, as opposed to just making a superficial change that blocks > the current syzbot reproducer, but which will eventually be tripped > again because code is still vulnerable. (For example, we might block > a straightforward reproducer by adding a check at mount time, but if > the superblocks get corrupted during the journal replay, we'd still be > vulnerable.) And having access to the corrupted file system image, > and other associated reporting data, is often super-helpful in that > regard. Thank you very much for the feedback below! > > Also, can we at some point have the C reproducer actually using proper > C strings instead of hex digits? It will make the reproducer much > more human understandable, as well making it easier to edit the string > when the developer is trying to do a better job minimizing the test > case than syzbot. For example: > > memcpy( > (void*)0x20000000, > "\x6e\x6f\x75\x73\x65\x72\x5f\x78\x61\x74\x74\x72\x2c\x61\x63\x6c\x2c\x64" > "\x65\x62\x75\x67\x5f\x77\x61\x6e\x74\x5f\x65\x78\x74\x72\x61\x5f\x69\x73" > "\x69\x7a\x65\x3d\x30\x78\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30" > "\x30\x30\x38\x30\x2c\x6c\x61\x7a\x79\x74\x69\x6d\x65\x2c\x6e\x6f\x62\x68" > "\x2c\x71\x75\x6f\x74\x61\x2c\x00\x3d\x93\x09\x61\x36\x5d\x73\x58\x9c", > 89); > > Would be *much* more understable if it were: > > memcpy( > (void*)0x20000000, > "nouser_xattr,acl,debug_want_extra_isize=0x0000000000000080,lazytime,nobh,quota,", > 80); I've filed an issue to keep track on the progress: https://github.com/google/syzkaller/issues/3605 > > Of course, something like: > > char mount_options[] = "nouser_xattr,acl,debug_want_extra_isize=0x0000000000000080,lazytime,nobh,quota,"; > > Would be even better (and more portable) than using random hex > addresses, but just simply using ASCII strings would be a good first > step. > > Of course, filling in C structures instead of just a random memcpy of > hex garbage would be even *more* awesome, bunt I'll take what I can > get. :-) > > Another opportunity for improvement is to try minimizing mount > options, so it becomes more obvious which ones are required. For > example, in the above example, a minimized mount option string would > have been: > > memcpy((void*)0x20000000, "debug_want_extra_isize=0x80,lazytime," 38); > > Having a more minimized reproducer would improve the reliability of > the bisect, as well as making it easier for the developer to figure > out the true root cause of the problem. I've filed an issue: https://github.com/google/syzkaller/issues/3606 -- Best Regards, Aleksandr > > Cheers, > > - Ted >