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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 72A2FC83F2D for ; Sun, 3 Sep 2023 22:27:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243941AbjICW1Z (ORCPT ); Sun, 3 Sep 2023 18:27:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236441AbjICW1X (ORCPT ); Sun, 3 Sep 2023 18:27:23 -0400 Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8A17DE for ; Sun, 3 Sep 2023 15:27:19 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-56f84de64b9so439784a12.1 for ; Sun, 03 Sep 2023 15:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1693780039; x=1694384839; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=uey9X37TsXxaxDDta+GmGK9zdrWEFlBTA4HM9sllgko=; b=aFcW5hhFseVJYvY9BxkVUGdq94OzhJT+piPShTn7nfOvOqUIAbtvyW6pEs7Y5AszBo iWDtNnMZCtAlW7+p0HLHWbaSGMMLbNDURG9IT+WAldCcrTaFHwbwT7Dx/diDOf4lQlJY 6R8KK0OgpgRCqAM9PY7WLMAuvaLp/HcrE/qv+CrBQQZp8QV4dBd4GpggNanfFa707RJU cBumvp0S6srNTFZ1wM/rPnYIQ48zm/ZbT39aeE+R4mflHAQriKOlszZTvYgc2DzoX0lx IttOIZ7Me4UdAI3Vflqk+fMvvoJ1lRrTPU3SSzDtUc0bK+lCEN50YMeadQ37y7ZCwPz+ 8UJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693780039; x=1694384839; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uey9X37TsXxaxDDta+GmGK9zdrWEFlBTA4HM9sllgko=; b=YbedTx68MPHEdZ7ltYPpWnDt030H5C1CZV2j2P9ReLhOSsYK0eYfqvZybl1fYlGgcY f85wY7losKEmpaEkQC+E5rvdRIF0nLA6v9jynZrRjSK1Uh6P3OhgJA9JpIXlry4M5YUv qP2ccZ7mJGyQ63cBeYdo/mVpWiZzw2FJB/ZfRRVmyBAgnH0ViROY8lUhHrCh5/LxzKkk 1PzuyAgz6WwsXkkkFOtn1c1UmvZMSWGE8bw/XTQ2+nKmlLk5d1t2lkEfOiiA4TEkg0/6 gbCDPXBlLRnIlv4yqMjdO3Ya7mA5oHb4qAa7YuboBHGKewDEuCjt5qtZ4fTSgKwDeoIj vudw== X-Gm-Message-State: AOJu0YwLRmPOSO2SK1LXliGZZE8tnMuqBCS0HakQjnv7vnT0hrxIIbNP eChmYrG/UHJCwoYhOmMYAlAaOg== X-Google-Smtp-Source: AGHT+IGeAVpJ32MwLia9j7b+fincRrOYrEYNNZjKkEpbapJ86ueujIl+j6DWTleN+nP733gdLcwaIQ== X-Received: by 2002:a17:90b:d94:b0:267:f8f4:73ab with SMTP id bg20-20020a17090b0d9400b00267f8f473abmr11150197pjb.16.1693780039113; Sun, 03 Sep 2023 15:27:19 -0700 (PDT) Received: from dread.disaster.area (pa49-195-66-88.pa.nsw.optusnet.com.au. [49.195.66.88]) by smtp.gmail.com with ESMTPSA id gb16-20020a17090b061000b00263f446d432sm7845229pjb.43.2023.09.03.15.27.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Sep 2023 15:27:18 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1qcvYp-00ASAZ-2e; Mon, 04 Sep 2023 08:27:15 +1000 Date: Mon, 4 Sep 2023 08:27:15 +1000 From: Dave Chinner To: Mateusz Guzik Cc: syzbot , brauner@kernel.org, djwong@kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, llvm@lists.linux.dev, nathan@kernel.org, ndesaulniers@google.com, syzkaller-bugs@googlegroups.com, trix@redhat.com, viro@zeniv.linux.org.uk Subject: Re: [syzbot] [xfs?] INFO: task hung in __fdget_pos (4) Message-ID: References: <000000000000e6432a06046c96a5@google.com> <20230903083357.75mq5l43gakuc2z7@f> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230903083357.75mq5l43gakuc2z7@f> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Sep 03, 2023 at 10:33:57AM +0200, Mateusz Guzik wrote: > On Sun, Sep 03, 2023 at 03:25:28PM +1000, Dave Chinner wrote: > > On Sat, Sep 02, 2023 at 09:11:34PM -0700, syzbot wrote: > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit: b97d64c72259 Merge tag '6.6-rc-smb3-client-fixes-part1' of.. > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=14136d8fa80000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=958c1fdc38118172 > > > dashboard link: https://syzkaller.appspot.com/bug?extid=e245f0516ee625aaa412 > > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > Been happening for months, apparently, yet for some reason it now > > thinks a locking hang in __fdget_pos() is an XFS issue? > > > > #syz set subsystems: fs > > > > The report does not have info necessary to figure this out -- no > backtrace for whichever thread which holds f_pos_lock. I clicked on a > bunch of other reports and it is the same story. That's true, but there's nothing that points at XFS in *any* of the bug reports. Indeed, log from the most recent report doesn't have any of the output from the time stuff hung. i.e. the log starts at kernel time 669.487771 seconds, and the hung task report is at: 684.588608][ T28] INFO: task syz-executor.0:19830 blocked for more than 143 seconds About 25 seconds later. So the hung tasks were running at about 540s, and that's just not in the logs. Every report has a different combination of filesystems being exercised, and a couple of them didn't even have XFS in them. So at this point, there is no single filesystem that the reports actually indicate is the cause, the reports don't contain the actual operations that hung, and there's basically nothing to go on so far. Hence putting it in the "fs" bucket (which encompasses all things filesystems!) is the rigth thing to do. The only commonality I kinda see is that secondary processes that are hung seem mostly to be in directory operations waiting on inode locks - either lookup or readdir, so it's entirely possible that a filesystem has screwed up ->iterate_shared locking in some way... > Can the kernel be configured to dump backtraces from *all* threads? It already is (sysrq-t), but I'm not sure that will help - if it is a leaked unlock then nothing will show up at all. -Dave. -- Dave Chinner david@fromorbit.com