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 AB289C4167B for ; Sat, 31 Dec 2022 17:04:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0C9588E0002; Sat, 31 Dec 2022 12:04:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0799F8E0001; Sat, 31 Dec 2022 12:04:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAAB98E0002; Sat, 31 Dec 2022 12:04:17 -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 DC5758E0001 for ; Sat, 31 Dec 2022 12:04:17 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A408AAAAA1 for ; Sat, 31 Dec 2022 17:04:17 +0000 (UTC) X-FDA: 80303224554.27.88FFE1F Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf04.hostedemail.com (Postfix) with ESMTP id 8DB3840006 for ; Sat, 31 Dec 2022 17:04:14 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=3gp0WBQK; spf=none (imf04.hostedemail.com: domain of rdunlap@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=rdunlap@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672506255; a=rsa-sha256; cv=none; b=jPzxf3LpD8mBFNbbPdSpwfUpn7cP8thGXfU3DDJH2esqJCMMQ8XRYyYgiK4fnNo/kvuHf+ 8iS+QynkuCmYrHuEp5l7lZULf9iLueRYO6ga0q/e+9rq9CwZw7yMfAyhQNfMN9xR6KU4rM aXAFwLXQoSIoSVCNheGpYkIB/iS/F2w= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=3gp0WBQK; spf=none (imf04.hostedemail.com: domain of rdunlap@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=rdunlap@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672506255; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+eA7UEumfrhwZvnLMy8o4eWh1GCDZs4DHFXhV0mGrRY=; b=rpO5Jb7MWmJoSDYu51YEN7z1PB8Gy3qy09G/UwNKL9bTxDSgoshxOLsHrvlSJKrn1EiDiw af6iCavGdVa9E/MT/qLpYLmeyG68NBVx2d3lyc24QJkjLH4HdfKrrTk4R/HznE2wtC4Aga 5BR/EzqkfBNT6xxLlto9/Wf7CKZPA3c= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Sender:Reply-To:Content-ID:Content-Description; bh=+eA7UEumfrhwZvnLMy8o4eWh1GCDZs4DHFXhV0mGrRY=; b=3gp0WBQK/ZGzjJm41N+msNiPyr VgUFQ0ajeJkzwEYPUWBMaPEufnCcONp0/UUgM/I/UjJoKSjjlIx5RoSEA6I9Da3FBm/aIT8wFcafI JNuWNZqfQELgMSCLuPluKMv9jsI7b6PEIgptjaQLVFJkce0FZLn0evNO1f04XYg7hHAz4ody/4GpB waseApCmZtsWaJiFG58+J9Wq9wgB3f7YTOxKME3sJsM5ryLKFXC6ywu1kuTmt79Ajb6YCuQv0jVdM JRB+J17pZ+QznVt0CpE8LL46iYUV+cIgCNsfF7IFC/54t5nBPR+ZIlqC2dWKCOncmxxoD3ZnOVFEH NeWYF5zg==; Received: from [2601:1c2:d80:3110::a2e7] by bombadil.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1pBfH2-007nIR-4f; Sat, 31 Dec 2022 17:03:56 +0000 Message-ID: <2e739a3f-b892-3fdd-634d-a1010c41dab2@infradead.org> Date: Sat, 31 Dec 2022 09:03:54 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [syzbot] WARNING in do_mkdirat Content-Language: en-US To: Theodore Ts'o , Aleksandr Nogikh 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 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> From: Randy Dunlap In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 8DB3840006 X-Rspamd-Server: rspam01 X-Stat-Signature: yecft6r5c4rc5bw9r79t4144qsjwx5gn X-HE-Tag: 1672506254-180883 X-HE-Meta: U2FsdGVkX19LIkpqn356v+6374EtovVE1d+nrs7qRQSynkDKMMi5ddlo4NfIuVNx1gBPDqa/2jZ7teLqG/qh00kCZyo7CC28k561VmPwdG5W7DabWJN5E+21RMd8XF5zrtaVbJS/dqzq1MZHhRQtslHdtkJpj1I1ghKchZ4m+qPA/7gVxWgcu4fRRZHuP5SWuNsbcWkOT5fteYPi+p7aQ0pOTFdhb9Mxm+rxQFCcpyNbEdFn9EN93vKaLvVB+dRvwa2NTxM/QV3+jRshs4yy0rxrjDTZDMgmFGtl1qygPKX4E1blZHZqLznzf/aWQu6nJ0x0CmO8lJ51jce+6Zs36pfyCDQcN+poqSWUtToK5j9Pc7DLxHUefw/MkPhgj1VUICB9dDUo+FUVNo+7YJBmTMP4wgrdu9+HnCgEML8zr0E3n+N1k2/GGB8IBo8ql6r9QDfAtJmLzOcpL56EeLiruhx9kqroJMunWQlajZqZh797gDVPZpLyJnBKWECvcOp2WwV4znHNp5HyO3cS0mCZmVga+iIJaq8d8Eq3y739vVhIFHTf5fvhanLAGaqRbQCyC0M6SMPic7r3H8jIuexsxImjPIFUjA7dAPTczBpKOBuPIbAIC93z8XiUWGZX5baWC2tgurLOVrJSyEgkLoMMAi7MtbUg4E4FLQeU4nY/UPSy62HdOkLxVWC2k7fHzFwr1Yv/G+lfLPyBSDxVghtcegCMfJA0I2LaxpUOkrnfsAL3yzdhX5gvuVmJsKyjnjd58It3D17TveZ1ewI7FPY6R+B6ZuJCz+TUnlzWBD5bNrlOcewHv0OVzdZwFazdX5OYousYnBWkjk4dsdvK1ur6dcgrfjzsgkTJRqrEvepskrrP0+H0bpTlvkqsFjdef5UM7Jx72MZijuqO+AhIt4sR/7un+Gh9p+O0gLQcNUJAwRxSopzP80bUZElANMRL/2PZocVNaFz+7va9eeDc/KD PDzTC2Ys NXyrTXNUU9IhTrrXQLR8adjZYgUw5ukO8GVEWQVEg2SRGjL1QMefCfgrZpxmES+ot5FDJ 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/31/22 08:57, 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? > > 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 > > 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. > > 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); > > 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. Amen to all of that. for so many good reasons. Thanks. -- ~Randy