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 X-Spam-Level: X-Spam-Status: No, score=-12.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6A92C47094 for ; Mon, 31 May 2021 09:27:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7FCA96023C for ; Mon, 31 May 2021 09:27:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231172AbhEaJ2v (ORCPT ); Mon, 31 May 2021 05:28:51 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:40390 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230501AbhEaJ2t (ORCPT ); Mon, 31 May 2021 05:28:49 -0400 Received: from imap.suse.de (imap-alt.suse-dmz.suse.de [192.168.254.47]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id AD8D52191F; Mon, 31 May 2021 09:27:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1622453228; h=from:from:reply-to: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; bh=W4z0meOW6IUCU2rQCfaqM2HBPpAFPAp/Ax2mmtHbSu8=; b=m7E9GVMntQg0Rqn2gC9P8zIWgPvjxIeM7kQXaqRmATFQQdBxuHLm0vDmmc+n5rghg0pMXZ ZlTwi+1eC07fSIrbHwn54bhptSOKoRgpfCS337nAA0YEa4s/Ce4pHHtijzM48fdvDoKP6Q StqmgtrGwHyPscgvUzNJ3dcUyBV4rVk= Received: from imap3-int (imap-alt.suse-dmz.suse.de [192.168.254.47]) by imap.suse.de (Postfix) with ESMTP id 35873118DD; Mon, 31 May 2021 09:27:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1622453226; h=from:from:reply-to: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; bh=W4z0meOW6IUCU2rQCfaqM2HBPpAFPAp/Ax2mmtHbSu8=; b=AG9SIgwXHsb2cQNSyV10/toWzH4RzhVfZ4Dpz4azl2VR7gRzjs8Ygyx8Bvi+4cFZyhwqGN fjXrWEKDpA/LnykCPIQx6JPXnYzoY84XJR3meiPLwyiTf5JJtklyDiFaxEHI/1eg3yzjYi raDIpK6km7Uij/76VoksOynNd+S2FYM= Received: from director2.suse.de ([192.168.254.72]) by imap3-int with ESMTPSA id RsipCuqrtGDpVwAALh3uQQ (envelope-from ); Mon, 31 May 2021 09:27:06 +0000 Subject: Re: [syzbot] kernel BUG in assertfail To: Dmitry Vyukov Cc: syzbot , Chris Mason , dsterba@suse.com, Josef Bacik , linux-btrfs@vger.kernel.org, LKML , syzkaller-bugs References: <000000000000f9136f05c39b84e4@google.com> <21666193-5ad7-2656-c50f-33637fabb082@suse.com> <224f1e6a-76fa-6356-fe11-af480cee5cf2@suse.com> From: Nikolay Borisov Message-ID: Date: Mon, 31 May 2021 12:27:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Authentication-Results: imap.suse.de; none X-Spamd-Result: default: False [2.50 / 100.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; URI_HIDDEN_PATH(1.00)[https://syzkaller.appspot.com/x/.config?x=9f3da44a01882e99]; TAGGED_RCPT(0.00)[a6bf271c02e4fe66b4e4]; MIME_GOOD(-0.10)[text/plain]; SURBL_MULTI_FAIL(0.00)[googlegroups.com:server fail]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RCPT_COUNT_SEVEN(0.00)[8]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; SUSPICIOUS_RECIPS(1.50)[] Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 31.05.21 г. 12:09, Dmitry Vyukov wrote: > On Mon, May 31, 2021 at 10:57 AM Nikolay Borisov wrote: >> On 31.05.21 г. 11:55, Dmitry Vyukov wrote: >>> On Mon, May 31, 2021 at 10:44 AM 'Nikolay Borisov' via syzkaller-bugs >>> wrote: >>>> On 31.05.21 г. 10:53, syzbot wrote: >>>>> Hello, >>>>> >>>>> syzbot found the following issue on: >>>>> >>>>> HEAD commit: 1434a312 Merge branch 'for-5.13-fixes' of git://git.kernel.. >>>>> git tree: upstream >>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=162843f3d00000 >>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=9f3da44a01882e99 >>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=a6bf271c02e4fe66b4e4 >>>>> >>>>> Unfortunately, I don't have any reproducer for this issue yet. >>>>> >>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit: >>>>> Reported-by: syzbot+a6bf271c02e4fe66b4e4@syzkaller.appspotmail.com >>>>> >>>>> assertion failed: !memcmp(fs_info->fs_devices->fsid, fs_info->super_copy->fsid, BTRFS_FSID_SIZE), in fs/btrfs/disk-io.c:3282 >>>> >>>> This means a device contains a btrfs filesystem which has a different >>>> FSID in its superblock than the fsid which all devices part of the same >>>> fs_devices should have. This can happen in 2 ways - memory corruption >>>> where either of the ->fsid member are corrupted or if there was a crash >>>> while a filesystem's fsid was being changed. We need more context about >>>> what the test did? >>> >>> Hi Nikolay, >>> >>> From a semantic point of view we can consider that it just mounts /dev/random. >>> If syzbot comes up with a reproducer it will post it, but you seem to >>> already figure out what happened, so I assume you can write a unit >>> test for this. >>> >> >> Well no, under normal circumstances this shouldn't trigger. So if syzbot >> is doing something stupid as mounting /dev/random then I don't see a >> problem here. The assert is there to catch inconsistencies during normal >> operation which doesn't seem to be the case here. > > > Does this mean that CONFIG_BTRFS_ASSERT needs to be disabled in any testing? > What is it intended for? Or it can only be enabled when mounting known > good images? But then I assume even btrfs unit tests mount some > invalid images, so it would mean it can't be used even during unit > testing? > > Looking at the output of "grep ASSERT fs/btrfs/*.c" it looks like most > of these actually check for something that "must never happen". E.g. > some lists/pointers are empty/non-empty in particular states. And > "must never happen" checks are for testing scenarios... > > Taking this particular FSID mismatch assert, should such corrupted > images be mounted for end users? Should users be notified? Currently > they are mounted and users are not notified, what is the purpose of > this assertion? > > Perhaps CONFIG_BTRFS_ASSERT needs to be split into "must never happen" > checks that are enabled during testing and normal if's with pr_err for > user notifications? > After going through the code you've convinced me. I just sent a patch turning the 2 debugging asserts into full-fledged checks in validate_super. So now the correct behavior is to prevent mounting of such images. How can I force syzbot to retest with the given patch applied?