public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: David Sterba <dsterba@suse.com>,
	fstests@vger.kernel.org, Josef Bacik <josef@toxicpanda.com>,
	Filipe Manana <fdmanana@suse.com>
Subject: Re: [PATCH 5/5] generic/733: disable for btrfs
Date: Tue, 19 Mar 2024 14:10:50 -0700	[thread overview]
Message-ID: <20240319211050.GL6188@frogsfrogsfrogs> (raw)
In-Reply-To: <Zfn9DMR8UQQMiyiL@infradead.org>

On Tue, Mar 19, 2024 at 02:01:00PM -0700, Christoph Hellwig wrote:
> On Tue, Mar 19, 2024 at 07:12:10PM +0100, David Sterba wrote:
> > This tests if a clone source can be read but in btrfs there's an
> > exclusive lock and the test always fails. The functionality might be
> > implemented in btrfs in the future but for now disable the test.
> 
> Well, this sounds like btrf sis broken and it should fail?
> 
> >  # real QA test starts here
> > -_supported_fs generic
> > +_supported_fs ^btrfs
> 
> 
> and just throwing random not supported in generic testes is just a mine
> field.  You;d better explain very well why something is not supported,
> and do that by adding a _require_.  If you can't explain the
> _require this probably actually is a bug and not just an exclude..

I don't think there's a good way to _require-test for holding i_rwsem in
exclusive or shared mode during an FICLONE operation.  But that ought to
be a comment somewhere at least.

--D

  reply	other threads:[~2024-03-19 21:10 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-19 18:11 [PATCH 0/5] Btrfs fstests fixups and updates David Sterba
2024-03-19 18:12 ` [PATCH 1/5] common/verity: use the correct options for btrfs-corrupt-block David Sterba
2024-03-20  9:58   ` Anand Jain
2024-03-20 15:23     ` David Sterba
2024-03-24  7:56       ` Anand Jain
2024-03-19 18:12 ` [PATCH 2/5] btrfs/131,btrfs/172,btrfs/206: add check for block-group-tree feature in btrfs David Sterba
2024-03-20 10:01   ` Anand Jain
2024-03-19 18:12 ` [PATCH 3/5] btrfs/330: add test to validate ro/rw subvol mounting David Sterba
2024-03-20 11:33   ` Anand Jain
2024-03-20 17:01     ` Filipe Manana
2024-03-21  3:51       ` Anand Jain
2024-03-19 18:12 ` [PATCH 4/5] common/rc: use proper temporary file path in _repair_test_fs() David Sterba
2024-03-20 11:35   ` Anand Jain
2024-03-19 18:12 ` [PATCH 5/5] generic/733: disable for btrfs David Sterba
2024-03-19 21:01   ` Christoph Hellwig
2024-03-19 21:10     ` Darrick J. Wong [this message]
2024-03-19 21:16       ` Christoph Hellwig
2024-03-20 15:58     ` David Sterba
2024-03-21 21:36       ` Christoph Hellwig
2024-03-21 21:52         ` Kent Overstreet
2024-03-22 15:08           ` Josef Bacik
2024-03-22 15:45             ` Darrick J. Wong
2024-03-22 18:28             ` Kent Overstreet
2024-03-20  9:49 ` [PATCH 0/5] Btrfs fstests fixups and updates Anand Jain
2024-03-20 15:26   ` David Sterba
2024-03-21  4:09 ` [PATCH] common/btrfs: set BTRFS_CORRUPT_BLOCK_OPT_<VALUE|OFFSET> Anand Jain
2024-03-21 11:13   ` Filipe Manana
2024-03-21 12:34     ` Anand Jain
2024-03-24  8:35 ` [PATCH 0/5] Btrfs fstests fixups and updates Anand Jain

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=20240319211050.GL6188@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=dsterba@suse.com \
    --cc=fdmanana@suse.com \
    --cc=fstests@vger.kernel.org \
    --cc=hch@infradead.org \
    --cc=josef@toxicpanda.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox