All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
	Bagas Sanjaya <bagasdotme@gmail.com>,
	Pengfei Xu <pengfei.xu@intel.com>,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	heng.su@intel.com, dchinner@redhat.com, lkp@intel.com,
	Linux Regressions <regressions@lists.linux.dev>
Subject: Re: [Syzkaller & bisect] There is BUG: unable to handle kernel NULL pointer dereference in xfs_extent_free_diff_items in v6.4-rc3
Date: Tue, 23 May 2023 23:46:12 +0000	[thread overview]
Message-ID: <20230523234612.GG888341@google.com> (raw)
In-Reply-To: <ZG07WoKnBzaN4T1L@dread.disaster.area>

On Wed, May 24, 2023 at 08:16:58AM +1000, Dave Chinner wrote:
> config XFS_SUPPORT_V4
>         bool "Support deprecated V4 (crc=0) format"
>         depends on XFS_FS
>         default y
>         help
>           The V4 filesystem format lacks certain features that are supported
>           by the V5 format, such as metadata checksumming, strengthened
>           metadata verification, and the ability to store timestamps past the
>           year 2038.  Because of this, the V4 format is deprecated.  All users
>           should upgrade by backing up their files, reformatting, and restoring
>           from the backup.
> 
>           Administrators and users can detect a V4 filesystem by running
>           xfs_info against a filesystem mountpoint and checking for a string
>           beginning with "crc=".  If the string "crc=0" is found, the
>           filesystem is a V4 filesystem.  If no such string is found, please
>           upgrade xfsprogs to the latest version and try again.
> 
>           This option will become default N in September 2025.  Support for the
>           V4 format will be removed entirely in September 2030.  Distributors
>           can say N here to withdraw support earlier.
> 
>           To continue supporting the old V4 format (crc=0), say Y.
>           To close off an attack surface, say N.
> 
> This was added almost 3 years ago in mid-2020. We're more than half
> way through the deprecation period and then we're going to turn off
> v4 support by default. At this point, nobody should be using v4
> filesystems in new production systems, and those that are should be
> preparing for upstream and distro support to be withdraw in the next
> couple of years...

Great to see that this exists now and there is a specific deprecation plan!

> > Then you could just tell the people fuzzing XFS filesystem images
> > that they need to use that option.  That would save everyone a lot of time.
> > (To be clear, I'm not arguing for the XFS policy on v4 filesystems being right
> > or wrong; that's really not something I'd like to get into again...  I'm just
> > saying that if that's indeed your policy, this is what you should do.)
> 
> It should be obvious by now that we've already done this. 3 years
> ago, in fact. And yet we are still having the same problems. Maybe
> this helps you understand the level of frustration we have with all
> the people running fuzzing bots out there....

I don't see evidence that this actually happened, though perhaps we are not
looking in the same places.  https://lore.kernel.org/all/?q=XFS_SUPPORT_V4
brings up little except the original patch thread, nor did
https://github.com/search?q=XFS_SUPPORT_V4&type=issues find anything.

Anyway, I took 3 minutes to file an issue in the syzkaller repo
(https://github.com/google/syzkaller/issues/3918), so at least this should get
resolved for syzbot soon.

- Eric

      reply	other threads:[~2023-05-23 23:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-22  2:07 [Syzkaller & bisect] There is BUG: unable to handle kernel NULL pointer dereference in xfs_extent_free_diff_items in v6.4-rc3 Pengfei Xu
2023-05-22  6:39 ` Bagas Sanjaya
2023-05-22 16:05   ` Darrick J. Wong
2023-05-22 17:05     ` Linux regression tracking (Thorsten Leemhuis)
2023-05-23  6:08       ` Bagas Sanjaya
2023-05-23  6:44         ` Pengfei Xu
2023-05-23  0:00     ` Eric Biggers
2023-05-23  7:31       ` Dave Chinner
2023-05-23  9:14         ` Pengfei Xu
2023-05-23 21:52           ` Dave Chinner
2023-05-24  2:20             ` Pengfei Xu
2023-05-23 16:50         ` Eric Biggers
2023-05-23 22:16           ` Dave Chinner
2023-05-23 23:46             ` Eric Biggers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230523234612.GG888341@google.com \
    --to=ebiggers@kernel.org \
    --cc=bagasdotme@gmail.com \
    --cc=david@fromorbit.com \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --cc=heng.su@intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=pengfei.xu@intel.com \
    --cc=regressions@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.