Re: [PATCH] fstests: add generic/499, a cgroup io.latency test

[My apoligy for the late review, I finally got some time to look into this new feature and test] On Fri, Jun 29, 2018 at 03:21:24PM -0400, Josef Bacik wrote: > The infrastructure is fairly straightforward, just some helpers to > verify cgroup2 is mounted and to setup a cgroup for our test. The

Re: [PATCH] blk-mq-debugfs: don't allow write on attributes with seq_operations set

On Wed, Jan 24, 2018 at 11:49:26AM +0800, Ming Lei wrote: > On Tue, Jan 23, 2018 at 02:32:06PM -0700, Jens Axboe wrote: > > On 1/23/18 10:20 AM, Eryu Guan wrote: > > > Attributes that only implement .seq_ops are read-only, any write to > > > them should be rejected.

[PATCH] blk-mq-debugfs: don't allow write on attributes with seq_operations set

ock//requeue_list Fix it by returning -EPERM in blk_mq_debugfs_write() when writing to such attributes. Cc: Ming Lei <ming@redhat.com> Signed-off-by: Eryu Guan <eg...@redhat.com> --- block/blk-mq-debugfs.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

Re: [PATCH] generic/473: test return EBUSY from BLKRRPART for mounted whole-dev

On Mon, Dec 04, 2017 at 05:15:17PM +0800, Xiao Yang wrote: > On 2017/12/04 16:29, Eryu Guan wrote: > > On Wed, Nov 29, 2017 at 08:02:26PM +0800, Xiao Yang wrote: > > > If the entire block device is formatted with a filesystem and > > > mounted, running "blockdev --

Re: [PATCH] generic/473: test return EBUSY from BLKRRPART for mounted whole-dev

On Wed, Nov 29, 2017 at 08:02:26PM +0800, Xiao Yang wrote: > If the entire block device is formatted with a filesystem and > mounted, running "blockdev --rereadpt" should fail and return > EBUSY instead of pass. > > Signed-off-by: Xiao Yang As we have blktests[1] now, I

Re: [ANNOUNCE] fsperf: a simple fs/block performance testing framework

On Mon, Oct 09, 2017 at 04:17:31PM +1100, Dave Chinner wrote: > On Sun, Oct 08, 2017 at 10:25:10PM -0400, Josef Bacik wrote: > > On Mon, Oct 09, 2017 at 11:51:37AM +1100, Dave Chinner wrote: > > > On Fri, Oct 06, 2017 at 05:09:57PM -0400, Josef Bacik wrote: > > > > Hello, > > > > > > > > One

[BUG] xfs/104 triggered NULL pointer dereference in iomap based dio

Hi all, Recently I noticed multiple crashes triggered by xfs/104 on ppc64 hosts in my upstream 4.13 kernel testings. The block layer is involved in the call trace so I add linux-block to cc list too. I append the full console log to the end of this mail. Now I can reproduce the crash on x86_64

Re: [v4.12-rc6 regression] commit dc9edc44de6c introduced use-after-free

On Thu, Jul 13, 2017 at 09:04:12PM +, Bart Van Assche wrote: > On Thu, 2017-06-29 at 19:34 +0800, Eryu Guan wrote: > > Hi all, > > > > I got a use-after-free report from kasan-enabled kernel, when running > > fstests xfs/279 (generic/108 could trigger too). I a

[v4.12-rc6 regression] commit dc9edc44de6c introduced use-after-free

Hi all, I got a use-after-free report from kasan-enabled kernel, when running fstests xfs/279 (generic/108 could trigger too). I appended the console log at the end of email. git bisect pointed first bad commit to dc9edc44de6c ("block: Fix a blk_exit_rl() regression"), and reverting that commit

Re: [xfstests PATCH v4 5/5] btrfs: make a btrfs version of writeback error reporting test

On Wed, Jun 14, 2017 at 07:55:17AM -0400, Jeff Layton wrote: > On Tue, 2017-06-13 at 16:40 +0800, Eryu Guan wrote: > > On Mon, Jun 12, 2017 at 08:42:13AM -0400, Jeff Layton wrote: > > > Make a new btrfs/999 test that works the way Chris Mason suggested: > > > >

Re: [xfstests PATCH v4 5/5] btrfs: make a btrfs version of writeback error reporting test

On Mon, Jun 12, 2017 at 08:42:13AM -0400, Jeff Layton wrote: > Make a new btrfs/999 test that works the way Chris Mason suggested: > > Build a filesystem with 2 devices that stripes the data across > both devices, but mirrors metadata across both. Then, make one > of the devices fail and see how

Re: [xfstests PATCH v4 2/5] ext4: allow ext4 to use $SCRATCH_LOGDEV

On Mon, Jun 12, 2017 at 08:42:10AM -0400, Jeff Layton wrote: > The writeback error handling test requires that you put the journal on a > separate device. This allows us to use dmerror to simulate data > writeback failure, without affecting the journal. > > xfs already has infrastructure for this

Re: [xfstests PATCH v4 1/5] generic: add a writeback error handling test

On Mon, Jun 12, 2017 at 08:42:09AM -0400, Jeff Layton wrote: > I'm working on a set of kernel patches to change how writeback errors > are handled and reported in the kernel. Instead of reporting a > writeback error to only the first fsync caller on the file, I aim > to make the kernel report them

Re: [xfstests PATCH v4 0/5] new tests for writeback error reporting behavior

On Mon, Jun 12, 2017 at 08:42:08AM -0400, Jeff Layton wrote: > v4: respin set based on Eryu's comments > > These tests are companion tests to the patchset I recently posted with > the cover letter: > > [PATCH v6 00/20] fs: enhanced writeback error reporting with errseq_t > (pile #1) > >

Re: [xfstests PATCH v3 1/5] generic: add a writeback error handling test

On Tue, Jun 06, 2017 at 06:15:57AM -0400, Jeff Layton wrote: > On Tue, 2017-06-06 at 16:58 +0800, Eryu Guan wrote: > > On Wed, May 31, 2017 at 09:08:16AM -0400, Jeff Layton wrote: > > > I'm working on a set of kernel patches to change how writeback errors > > &g

Re: [xfstests PATCH v3 5/5] btrfs: allow it to use $SCRATCH_LOGDEV

On Wed, May 31, 2017 at 09:08:20AM -0400, Jeff Layton wrote: > With btrfs, we can't really put the log on a separate device. What we > can do however is mirror the metadata across two devices and make the > data striped across all devices. When we turn on dmerror then the > metadata can fall back

Re: [xfstests PATCH v3 3/5] generic: test writeback error handling on dmerror devices

On Wed, May 31, 2017 at 09:08:18AM -0400, Jeff Layton wrote: > Ensure that we get an error back on all fds when a block device is > open by multiple writers and writeback fails. > > Signed-off-by: Jeff Layton > --- > tests/generic/998 | 64 >

Re: [xfstests PATCH v3 4/5] ext3: allow it to put journal on a separate device when doing scratch_mkfs

On Wed, May 31, 2017 at 09:08:19AM -0400, Jeff Layton wrote: > Signed-off-by: Jeff Layton > --- > common/rc | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/common/rc b/common/rc > index 391d36f373cd..83765aacfb06 100644 > --- a/common/rc

Re: [xfstests PATCH v3 2/5] ext4: allow ext4 to use $SCRATCH_LOGDEV

On Wed, May 31, 2017 at 09:08:17AM -0400, Jeff Layton wrote: > The writeback error handling test requires that you put the journal on a > separate device. This allows us to use dmerror to simulate data > writeback failure, without affecting the journal. > > xfs already has infrastructure for this

Re: [xfstests PATCH v3 1/5] generic: add a writeback error handling test

On Wed, May 31, 2017 at 09:08:16AM -0400, Jeff Layton wrote: > I'm working on a set of kernel patches to change how writeback errors > are handled and reported in the kernel. Instead of reporting a > writeback error to only the first fsync caller on the file, I aim > to make the kernel report them