On Wed, Oct 09, 2019 at 04:27:57PM +0800, Zhihao Cheng wrote:
> Running generic/192 with overlayfs(Let ubifs as base fs) yields the
> following output:
>
> generic/192 - output mismatch
> QA output created by 192
> sleep for 5 seconds
> test
> +./common/rc: line 316: src/t_dir
On Wed, Sep 25, 2019 at 10:18:39AM +0300, Amir Goldstein wrote:
> On Wed, Sep 25, 2019 at 9:29 AM Zhihao Cheng wrote:
> >
> > When running overlay tests using character devices as base fs partitions,
> > all overlay usecase results become 'notrun'. Function
> > '_overay_config_override' (common/co
On Tue, Sep 24, 2019 at 10:19:38PM +0800, Zhihao Cheng wrote:
> As far as I know, _require_scratch_shutdown() is called after
> _overay_config_override(), at this moment, FSTYP equals to base fs. According
> the implementation of _require_scratch_shutdown:
> 3090 _require_scratch_shutdown()
> 309
On Fri, Dec 15, 2017 at 12:41:07PM -0800, Luis R. Rodriguez wrote:
> Some systems are not allowing usernames prefixed with a number now, this
> test however relies on the assumption that you can end up with usernames
> of such type, given the purpose of the test is to ensure that xfs_quota
> can di
On Thu, Dec 14, 2017 at 06:55:03PM +0100, Luis R. Rodriguez wrote:
> On Thu, Dec 14, 2017 at 01:51:02PM +0800, Eryu Guan wrote:
> > On Tue, Dec 12, 2017 at 04:45:14PM -0800, Luis R. Rodriguez wrote:
> > > Modern gdbm-devel packages bundle together gdbm.h and ndbm.h.
> >
On Tue, Dec 12, 2017 at 04:45:14PM -0800, Luis R. Rodriguez wrote:
> Modern gdbm-devel packages bundle together gdbm.h and ndbm.h.
> The old m4 macro had detection support for some old gdbm libraries
> but not for new ones.
>
> We fix compilation of src/dbtest.c by making the autoconf helper
> che
, size);
Fixed by capping the 'max' value according to the src buffer size,
to make sure we won't go beyond src buffer.
Cc: Andrew Morton
Cc: Chris Metcalf
Cc: Kees Cook
Signed-off-by: Eryu Guan
---
lib/string.c | 5 +
1 file changed, 5 insertions(+)
diff --gi
On Tue, Oct 31, 2017 at 01:10:41AM +0100, Fengguang Wu wrote:
> Hi Eryu,
>
> On Mon, Oct 30, 2017 at 03:44:29PM +0800, Eryu Guan wrote:
> > Hi Fengguang,
> >
> > On Mon, Oct 30, 2017 at 08:20:21AM +0100, Fengguang Wu wrote:
> > > CC fsdevel.
> > >
&
Hi Fengguang,
On Mon, Oct 30, 2017 at 08:20:21AM +0100, Fengguang Wu wrote:
> CC fsdevel.
>
> On Sun, Oct 29, 2017 at 11:51:55PM +0100, Fengguang Wu wrote:
> > Hi Linus,
> >
> > Up to now we see the below boot error/warnings when testing v4.14-rc6.
> >
> > They hit the RC release mainly due to
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 thing
On Thu, Sep 21, 2017 at 02:34:43PM -0700, Khazhismel Kumykov wrote:
> Most shutdown tests only run on filesystems with metadata journaling, so
> we lose coverage. Add a shutdown stress test that doesn't check for
> consistency, so does not require journaling.
>
> Signed-off-by: Khazhismel Kumykov
On Mon, Sep 11, 2017 at 10:45:21PM -0600, Ross Zwisler wrote:
> Add a regression test for the following kernel commit:
>
> ext4: prevent data corruption with inline data + DAX
>
> The test passes either if we don't encounter corruption, or if mounting
> with DAX + inline data fails. The latter
On Mon, Sep 11, 2017 at 10:45:20PM -0600, Ross Zwisler wrote:
> Add a regression test for the following kernel commit:
>
> ext4: prevent data corruption with journaling + DAX
>
> The test passes if either we successfully compare the data between the mmap
> with journaling turned on and the one
On Tue, Jun 06, 2017 at 06:00:34PM +0800, Li Wang wrote:
> Hi,
>
> ltp/access04 always panic the latest mainstream kernel-4.12-rc4 on
> ppc64le. From the calltrace
> I guess the reason is probably that the tests mount ext2 file system
> using ext4 driver.
>
> A simple way to reproduce:
>
> # dd
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
> > >
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 t
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
> +++ b/common/rc
> @
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
> +
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
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
patch today
myself, and I'm still testing it.
I found this by xfstests, many tests (tens of tests) failed fsck after
test when testing extN if blocksize < pagesize. E.g. generic/013 could
reproduce the fs corruption quite reliablely for me.
Reviewed-by: Eryu Guan
>
> The patch loo
page is not uptodate.
Signed-off-by: Eryu Guan
---
I think the other way to fix it is to add the ability to check & allow
partially-uptodate page to page_cache_pipe_buf_confirm(), but that is much
harder to do and seems gain little.
v2:
- Update summary a little bit
- Update commit log
- Add co
On Sun, Aug 14, 2016 at 04:52:16PM +0200, Greg Kroah-Hartman wrote:
>
> Did a fix for this ever get into Linus's tree?
>
> thanks,
>
> greg k-h
Yes, please see commit c1892c37769c ("vfs: fix deadlock in
file_remove_privs() on overlayfs"), which is tagged as "stable".
Thanks,
Eryu
Hi,
I hit boot failure on s390x host starting from 4.8-rc1 kernel, 4.7
kernel works fine. And I bisected to this commit 444d13ff10fb
commit 444d13ff10fb13bc3e64859c3cf9ce43dcfeb075
Author: Jessica Yu
Date: Wed Jul 27 12:06:21 2016 +0930
modules: add ro_after_init suppo
On Tue, Aug 09, 2016 at 11:14:38PM +0800, kernel test robot wrote:
>
> FYI, we noticed the following commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
> commit 6141b4d64295ec08a1b48c7fcac8a566658cd64f ("fs: return EPERM on
> immutable inode")
>
> in testcase: xf
On Wed, Aug 03, 2016 at 09:45:06AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 03, 2016 at 03:36:44PM +0800, Eryu Guan wrote:
> > On Mon, Jul 25, 2016 at 01:56:28PM -0700, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch. If anyone has any objections, please
ng the kernel.
Should we skip it for now and wait for a further fix?
(The 4.6-stable tree faces the same question)
Thanks,
Eryu
>
> Signed-off-by: Vivek Goyal
> Reported-by: Eryu Guan
> Signed-off-by: Miklos Szeredi
> Fixes: 4bacc9c9234c ("overlayfs: Make f_path alwa
igned-off-by: Eryu Guan
---
v2:
- update commit log to mention that it's found by running LTP
fs/gfs2/inode.c| 2 +-
fs/namei.c | 2 +-
fs/utimes.c| 3 ++-
fs/xfs/xfs_ioctl.c | 2 +-
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/gfs2/inode.c b/fs/gf
igned-off-by: Eryu Guan
---
v2:
- update commit message to include the background on noticing this issue
fs/gfs2/inode.c| 2 +-
fs/namei.c | 2 +-
fs/utimes.c| 3 ++-
fs/xfs/xfs_ioctl.c | 2 +-
4 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/gfs2/inode.c b/fs
In most cases, EPERM is returned on immutable inode, and there're only
a few places returning EACCES. And EPERM looks more reasonable to me.
So converting all EACCES to EPERM on immutable inode.
Signed-off-by: Eryu Guan
---
I noticed this when running LTP on overlayfs, setxattr03 failed d
_list_add+0xa4/0x140
> Call Trace:
> [c004c749f620] [c042db74] __list_add+0xa4/0x140 (unreliable)
> [c004c749f6b0] [c08010ec] rwsem_down_read_failed+0x6c/0x1a0
> [c004c749f760] [c0800828] down_read+0x58/0x60
> [c004c749f7e0] [d5a
> a lot of marks being removed, we delay the reaper job slightly when
> queueing it, to allow several to gather on the list.
>
> Cc: Jan Kara
> Cc: Eric Paris
> Cc: Andrew Morton
> Cc: Eryu Guan
> Signed-off-by: Jeff Layton
With these two patches applied on top of r.5-rc
On Mon, Aug 24, 2015 at 04:24:25PM +1000, Dave Chinner wrote:
> On Mon, Aug 24, 2015 at 11:18:16AM +0800, Eryu Guan wrote:
> > On Mon, Aug 24, 2015 at 11:11:23AM +1000, Dave Chinner wrote:
> > >
> > > Eryu, can you change the way you run the event trace to be:
> &
On Mon, Aug 24, 2015 at 11:11:23AM +1000, Dave Chinner wrote:
>
> Eryu, can you change the way you run the event trace to be:
>
> $ sudo trace-cmd -o ./check
>
> rather than running the trace as a background operation elsewhere?
> Maybe that will give better results.
The results are here
ht
On Sat, Aug 22, 2015 at 10:30:25AM +1000, Dave Chinner wrote:
> On Fri, Aug 21, 2015 at 06:20:53PM +0800, Eryu Guan wrote:
[snip]
>
> Eryu, can you try again, this time manually specifying the writeback
> tracepoints so you exclude the really noisy ones? You can als
On Wed, Aug 19, 2015 at 07:56:11AM +1000, Dave Chinner wrote:
> On Tue, Aug 18, 2015 at 12:54:39PM -0700, Tejun Heo wrote:
[snip]
>
> I'd suggest looking at some of the XFS tracepoints during the test:
>
> tracepointtrigger
> xfs_file_buffered_write once per writ
On Thu, Aug 20, 2015 at 02:12:24PM +0800, Eryu Guan wrote:
> On Wed, Aug 19, 2015 at 07:56:11AM +1000, Dave Chinner wrote:
> > On Tue, Aug 18, 2015 at 12:54:39PM -0700, Tejun Heo wrote:
> > > Hello,
> > >
> > > On Tue, Aug 18, 2015 at 10:47:18AM -0700, Teju
On Wed, Aug 19, 2015 at 07:56:11AM +1000, Dave Chinner wrote:
> On Tue, Aug 18, 2015 at 12:54:39PM -0700, Tejun Heo wrote:
> > Hello,
> >
> > On Tue, Aug 18, 2015 at 10:47:18AM -0700, Tejun Heo wrote:
> > > Hmm... the only possibility I can think of is tot_write_bandwidth
> > > being zero when it
38 matches
Mail list logo