Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp2441701pxj; Mon, 31 May 2021 02:11:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyES+3zEjmzsVc/Xl28xxX+bYJgwAKsZye4RUEHXPoUWGf7F+frZ7mgKVa3Qawr8V3eYv4I X-Received: by 2002:a05:6402:2686:: with SMTP id w6mr24518972edd.80.1622452270082; Mon, 31 May 2021 02:11:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622452270; cv=none; d=google.com; s=arc-20160816; b=FrGlOKycvdRrFgdD0eVzkrsHV8jWCmP9H7ybHq78GH9kj7q5n22NFurbwl1325crO4 E2ipd/6bZE+yowqIrglxsGTKhhWdis6eyk4vJ8ecaqpROIT1Mu31ydbOgpAN3ljZjeWR JTe6qkYeVPYpED1kLYbd93sPVnoEROj/0w4ahzDpBe2tuPgjTRTdX7omql6r0ofnwNP9 pIQ0m9PIoDlvVptDl1MgWgltnekeHqLZ6w5ueTsXyKwXoxSi2HLVPr7MoxbvS72HN+Z4 k790lMal2SAsjf9SLEjq+c64WDrIAb0fk3AohqNpJ3Hohn+6yIg/7ueDN5QScbylPQxO EtZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=IJm6BORftzEWEGVW607YFI9b5KUIuit1QBx1ZBqXYg0=; b=tQoq+rtXise2+xaoQQX4e37+IWn1QlP3Y0C2x3986eR52LIMpcRaQGZwnw/FatOqUG WIUiYnvlfDGD3Yk4BetTbJRpGB4OlBZ0nLirD+hD5gZtU0GLzob7/xFlI8+2+w+2ocnf TX3O9vH67eeA2rY9qK5IvJ+U4sPLCWJAtOMWpsLRd6MH83lPVE9T88r0Ot6y0JljCYcI cMrDmfCPCyBd6bQ2F1caArTxOx0CG6hRrwFVTZAyiLhC9v1pjDKi2y1EQnuL7GBz1NSO lujNXJKS3vQISw8Gx73besDDuGcIm1V17ZHifhnIj9jum6CHZeUU0szdNsDWJMeRHCag ei/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=CIbw2SDz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i2si10765611edc.332.2021.05.31.02.10.47; Mon, 31 May 2021 02:11:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=CIbw2SDz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230296AbhEaJLG (ORCPT + 99 others); Mon, 31 May 2021 05:11:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229522AbhEaJLA (ORCPT ); Mon, 31 May 2021 05:11:00 -0400 Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1E7B7C06174A for ; Mon, 31 May 2021 02:09:19 -0700 (PDT) Received: by mail-qv1-xf2c.google.com with SMTP id a7so5177529qvf.11 for ; Mon, 31 May 2021 02:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IJm6BORftzEWEGVW607YFI9b5KUIuit1QBx1ZBqXYg0=; b=CIbw2SDztBV7RW6fGgAXk8TZGbncpGR/9ybFGe2AaQdewLy7mrtwJZo07ZONLlh9rS nDEkHkeqnBcKf1J78klzsi5zZydG8B5lI+unt6CN+2/sfiONd/svy6IUZ6TnZ5Q7U2Nk OJiBuZup5tD7YE1uMtU848Ou9tLmo7jLdMjNwz7jSaCQWBBpqbvHR8EBQeNpQCvoWwZw CFcKHx+EvEAxvGJWK7dpjGMRcAd5PHpgvcbsbxrQAHWpkYg/vvlsTo7q+scyfn+kYs/7 UDPopY/BS/287eMsjy30OoXYbr8nc6Gl5u7yNIHJ8eVnPAd6Cn1PjBJ1xtBBx9XdHN5N Ai5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IJm6BORftzEWEGVW607YFI9b5KUIuit1QBx1ZBqXYg0=; b=r/pOIlvi8GBQ7yyaV4nHuC3gbqo+XMt5cX72TkTSY5X9UnVCrh+BlRY4t+F1I49nCC f1fysJKS+X/3Cc4T7w1PfOgpYGzA17EbyPbcpoMTjIK3NzHJCaq+cOX6HGloGyPcc71q pFaU89DRaZlx23gjC2PuEIkZaCayEpBrOeyOj5U6R/jX+qWyfyxayANYrHGmz14lbk55 NeKV0LyO102ydytcliwh50IgVTmxKdyQlewx6frZXGOULFpjh9XMYU+aD31WNOlmcVHR jG3KqOBuowJsYmFCFacg21tD0hcHbpqOfnoxHkE8h76nY2d43xffkIWc+2OHaspNKBXv peRA== X-Gm-Message-State: AOAM530F+fmzxp9u4kWvcaGspDfZ/aQppiIP+XO9a+1zupM1lEckOFfu q9gWmX9Hen+9Sn2Wo7EklvzB7wiJOiu5WwLiFpe+hQ== X-Received: by 2002:a05:6214:12c7:: with SMTP id s7mr10284287qvv.44.1622452157450; Mon, 31 May 2021 02:09:17 -0700 (PDT) MIME-Version: 1.0 References: <000000000000f9136f05c39b84e4@google.com> <21666193-5ad7-2656-c50f-33637fabb082@suse.com> <224f1e6a-76fa-6356-fe11-af480cee5cf2@suse.com> In-Reply-To: <224f1e6a-76fa-6356-fe11-af480cee5cf2@suse.com> From: Dmitry Vyukov Date: Mon, 31 May 2021 11:09:06 +0200 Message-ID: Subject: Re: [syzbot] kernel BUG in assertfail To: Nikolay Borisov Cc: syzbot , Chris Mason , dsterba@suse.com, Josef Bacik , linux-btrfs@vger.kernel.org, LKML , syzkaller-bugs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 31, 2021 at 10:57 AM Nikolay Borisov wrote: > On 31.05.21 =D0=B3. 11:55, Dmitry Vyukov wrote: > > On Mon, May 31, 2021 at 10:44 AM 'Nikolay Borisov' via syzkaller-bugs > > wrote: > >> On 31.05.21 =D0=B3. 10:53, syzbot wrote: > >>> Hello, > >>> > >>> syzbot found the following issue on: > >>> > >>> HEAD commit: 1434a312 Merge branch 'for-5.13-fixes' of git://git.k= ernel.. > >>> git tree: upstream > >>> console output: https://syzkaller.appspot.com/x/log.txt?x=3D162843f3d= 00000 > >>> kernel config: https://syzkaller.appspot.com/x/.config?x=3D9f3da44a0= 1882e99 > >>> dashboard link: https://syzkaller.appspot.com/bug?extid=3Da6bf271c02e= 4fe66b4e4 > >>> > >>> 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_c= opy->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 sam= e > >> 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 cras= h > >> while a filesystem's fsid was being changed. We need more context abou= t > >> 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?