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 54677C4332F for ; Sat, 31 Dec 2022 16:58:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB94E8E0002; Sat, 31 Dec 2022 11:58:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A6A1E8E0001; Sat, 31 Dec 2022 11:58:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9305F8E0002; Sat, 31 Dec 2022 11:58:17 -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 7FA0C8E0001 for ; Sat, 31 Dec 2022 11:58:17 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 382D1140239 for ; Sat, 31 Dec 2022 16:58:17 +0000 (UTC) X-FDA: 80303209434.10.BC252D6 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by imf28.hostedemail.com (Postfix) with ESMTP id 79C5AC0011 for ; Sat, 31 Dec 2022 16:58:15 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=fail ("headers rsa verify failed") header.d=mit.edu header.s=outgoing header.b="kjAwo/UE"; spf=pass (imf28.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu; dmarc=pass (policy=none) header.from=mit.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672505895; 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=OZlI3LKt7qQwa7YKmknHkE9bQ2vjr1mCmTgEfEpMiwY=; b=UGFLO0HeYNUdZziOXz3183jcP7hCnq1O/S78U9gHoqGTYUROTovBQS0B6wvSYFy5RIkXlA Wl9wMtNV3iHsDJ9YDkJk6+GwGfOinIxqzAV1yfAM3fqhnoiFPIzoiC/wTbOI61hp3M8AMR tyXWhnA+exSjQdP6TsIkLtzWXJG48uM= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=fail ("headers rsa verify failed") header.d=mit.edu header.s=outgoing header.b="kjAwo/UE"; spf=pass (imf28.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu; dmarc=pass (policy=none) header.from=mit.edu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672505895; a=rsa-sha256; cv=none; b=kcAKUOknNK2AzwnyxyBra38JnQiDkc+12DqAQgUG3FM8v8qy0k1KqrSnt2+jBvA6vnNyIY DORJjPCD14SJrC2qmfZLN5PQbLK8yMD40HDYFr9Idz8C0Ntxq3Zhm99fEpw3GxSqUzTFKi YMc6u0ZPQ1WCIRZZ16CXZVTNPt64S38= Received: from letrec.thunk.org (host-67-21-23-146.mtnsat.com [67.21.23.146] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 2BVGvlG2017379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 31 Dec 2022 11:57:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1672505879; bh=OZlI3LKt7qQwa7YKmknHkE9bQ2vjr1mCmTgEfEpMiwY=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=kjAwo/UEpSbI0nz5oloeXgkkfC1aSjQja9YRWpf/OgYuuz97eZji+KGaNQ4MbOPSg 9Qx5c0JXhstgfasvQn5kRdwqfhNSnn0tO5FtLpMnSDZBcJZKTCJuAMW0OZqMzeaNlo m8Qo1idEBuO+2z/TUNqy+Xq8yWN7tJRyjTZAKttUfPInsKcN03z0V+sVw/JZyfjHdh jYYwPEyhrIsp5cLJ4mQ3i9HpXv7MQyVvlSbncYV+5F57Dh8rysmfmNOrxJa9eegCRu ylaHgB4A2HMJ0dn25hxE//HHlc5p5TlBj8hb5SYbjTz5XQoNdQvjsLhxLm5cdJ3k72 l3TTW3e52WaXw== Received: by letrec.thunk.org (Postfix, from userid 15806) id 98A2F8C09BA; Sat, 31 Dec 2022 11:57:39 -0500 (EST) Date: Sat, 31 Dec 2022 11:57:39 -0500 From: "Theodore Ts'o" To: 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 Subject: Re: [syzbot] WARNING in do_mkdirat Message-ID: 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 79C5AC0011 X-Stat-Signature: tsa3wmzcoox8hozphoh66k6t3zpabff3 X-Rspam-User: X-HE-Tag: 1672505895-104579 X-HE-Meta: U2FsdGVkX1/hfO84bY+iK0GE2n5elelo8jORrxiwFCbsKOI3oDIdcrEsb0Xf0E/z7jlTUfIXuuhN5SiJs7ik5a+kPnX4HWSEo6TrMODU4j4IGZH6TQMDcNWyr5LLEHeGGsTqXMEgo1rReHDTn8YWfDb78r1iVX+pfj1wl2cuNATyW3T5HiFfkIg1IYF+3EnnBesxnGKg4Lrj8jKG3dnXBO2a/JPv8ZVli/IPPci3gf0EFx9EfIVVOkiCOlrfofI+nn+U2i0mQUfnppAvb3AbAbnRKYmbZNUXrKQjiM0q8cNHqjDcuAI63+TLfJFN07r132wkYxY5L/Y/okkB3v1scpvr0TSZiNnNJTTJSj3y9etUUIQtKAXs1L/twji0S8T7SE735wfbRW77AbVwgx7/bExhZr72eMYhOkGd1IaDfVteM2uB4SI8VM9hREdwS0SQ7lvFmWzPUJg0vTD/UqckjhjLbClDDBOeO4EBxG7HNe7M1qRB3mw8tw+QAy50k9OB/5F9xRcmSPnkBdmOtS0EOHsro2SRfnzBxr8moW2mGDDYaZWpXwXFOw7T5HvwEsXS3lGoJUDbnY+WHnwXfFcYBCTObIpn9qqN9FGVbU4zdkA8HljDkNJi450YhhK4DU5IeXV1b/ijf1pX7CsdLWKQldXPFocDKp3uCDfMnSq9K/ty9xqoFRqNbfnH59mk8efK1I7COyIzvhtNMT1+NLt0vBd6R8Znb4IykxrPOBBW83UOZDnTlkV4+AcQJ7q0tScZ6/BCWhpEJRmlinukGaj2djoIpzkLW5f7ReiuwkWb+vo86T8blTRluvJOGddnRB3h/gDDx426RIzB/soCbBCrWVGGyqzsv2NB2PvWNfMDk4xZvry7WZNtxCM91YIZBseFKyHMGk6aiTk8Qd6LUGD0Yv0/AGAKSH+szMbrrCYIPj/wTqSDuqtRBr8RsEfo29VVm6Ato/dH9KLHc2dUuw9 WuJ3wBdl KHuUneHb/t3LYrGykFeZ4/rh1BIiGgo3UN239sH8Gl2YquaRTEgKDuFaedvohU34Hcea4fD7XiJJO6mptnOQaiiZkBA== 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 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. Cheers, - Ted