Re: [PATCH] xfs: fix system crash caused by null bp->b_pages

On 12/24/20 3:51 AM, Fengfei Xi wrote: > We have encountered the following problems several times: > 1、A raid slot or hardware problem causes block device loss. > 2、Continue to issue IO requests to the problematic block device. > 3、The system possibly crash after a few hours. What

Re: [PATCH -next] fs/xfs: convert comma to semicolon

e dare add that tag ;) Reviewed-by: Eric Sandeen > --- > fs/xfs/libxfs/xfs_btree.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/xfs/libxfs/xfs_btree.c b/fs/xfs/libxfs/xfs_btree.c > index 2d25bab68764..51dbff9b0908 100644 > --- a/fs/xfs/libxfs/xfs_b

Re: [PATCH] common/rc: Fix _check_s_dax()

On 12/3/20 2:15 AM, Christoph Hellwig wrote: > On Wed, Dec 02, 2020 at 01:41:45PM -0800, ira.we...@intel.com wrote: >> From: Ira Weiny >> >> There is a conflict with the user visible statx bits 'mount root' and >> 'dax'. The kernel is changing the dax bit to correct this conflict.[1] >> >>

Re: [RFC PATCH] common/rc: Fix _check_s_dax() for kernel 5.10

On 12/2/20 10:07 AM, ira.we...@intel.com wrote: > From: Ira Weiny > > There is a conflict with the user visible statx bits 'mount root' and > 'dax'. The kernel is shifting the dax bit.[1] > > Adjust _check_s_dax() to use the new bit. > > [1] >

Re: [PATCH 2/2] statx: move STATX_ATTR_DAX attribute handling to filesystems

On 12/1/20 4:09 PM, Linus Torvalds wrote: > So basically, the thing that argues against this patch is that it > seems to just duplicate things inside filesystems, when the VFS layter > already has the information. > > Now, if the VFS information was possibly stale or wrong, that woudl be > one

[PATCH V2] uapi: fix statx attribute value overlap for DAX & MOUNT_ROOT

of the attributes, and explain why the value for DAX does not match. Fixes: 80340fe3605c ("statx: add mount_root") Fixes: 712b2698e4c0 ("fs/stat: Define DAX statx attribute") Reported-by: David Howells Signed-off-by: Eric Sandeen Reviewed-by: David Howells --- V2: Change flag va

Re: [PATCH 2/2] statx: move STATX_ATTR_DAX attribute handling to filesystems

On 12/1/20 4:12 PM, Linus Torvalds wrote: > On Tue, Dec 1, 2020 at 2:03 PM Eric Sandeen wrote: >> >> That's why I was keen to just add DAX unconditionally at this point, and if >> we want >> to invent/refine meanings for the mask, we can still try to do that? >

Re: [PATCH 2/2] statx: move STATX_ATTR_DAX attribute handling to filesystems

On 12/1/20 2:52 PM, Dave Chinner wrote: > On Tue, Dec 01, 2020 at 09:39:05AM -0800, Darrick J. Wong wrote: >> On Tue, Dec 01, 2020 at 10:59:36AM -0600, Eric Sandeen wrote: >>> It's a bit odd to set STATX_ATTR_DAX into the statx attributes in the VFS; >>> while the VFS

Re: [PATCH 2/2] statx: move STATX_ATTR_DAX attribute handling to filesystems

On 12/1/20 2:04 PM, Linus Torvalds wrote: > On Tue, Dec 1, 2020 at 8:59 AM Eric Sandeen wrote: >> >> It's a bit odd to set STATX_ATTR_DAX into the statx attributes in the VFS; >> while the VFS can detect the current DAX state, it is the filesystem which >> actua

Re: [PATCH 1/2] uapi: fix statx attribute value overlap for DAX & MOUNT_ROOT

On 12/1/20 12:31 PM, Andreas Dilger wrote: > On Dec 1, 2020, at 10:44 AM, Eric Sandeen wrote: >> >> On 12/1/20 11:32 AM, Darrick J. Wong wrote: >>> On Tue, Dec 01, 2020 at 10:57:11AM -0600, Eric Sandeen wrote: >>>> STATX_ATTR_MOUNT_ROOT and STATX_ATTR_DAX got

Re: [PATCH 2/2] statx: move STATX_ATTR_DAX attribute handling to filesystems

On 12/1/20 11:39 AM, Darrick J. Wong wrote: >> diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c >> index 1414ab79eacf..56deda7042fd 100644 >> --- a/fs/xfs/xfs_iops.c >> +++ b/fs/xfs/xfs_iops.c >> @@ -575,10 +575,13 @@ xfs_vn_getattr( >> stat->attributes |= STATX_ATTR_APPEND; >>

Re: [PATCH 1/2] uapi: fix statx attribute value overlap for DAX & MOUNT_ROOT

On 12/1/20 11:32 AM, Darrick J. Wong wrote: > On Tue, Dec 01, 2020 at 10:57:11AM -0600, Eric Sandeen wrote: >> STATX_ATTR_MOUNT_ROOT and STATX_ATTR_DAX got merged with the same value, >> so one of them needs fixing. Move STATX_ATTR_DAX. >> >> While we're in here, clarif

[PATCH 2/2] statx: move STATX_ATTR_DAX attribute handling to filesystems

ot; [1] so that the statx attributes_mask can be properly set. So, move STATX_ATTR_DAX attribute setting to the individual dax-capable filesystems, and update the attributes_mask there as well. [1] 3209f68b3ca4 statx: Include a mask for stx_attributes in struct statx Signed-off-by: Eric Sandee

[PATCH 1/2] uapi: fix statx attribute value overlap for DAX & MOUNT_ROOT

STATX_ATTR_MOUNT_ROOT and STATX_ATTR_DAX got merged with the same value, so one of them needs fixing. Move STATX_ATTR_DAX. While we're in here, clarify the value-matching scheme for some of the attributes, and explain why the value for DAX does not match. Signed-off-by: Eric Sandeen

[PATCH 0/2] statx: Fix DAX attribute collision and handling

There are two issues with the statx DAX attribute in the kernel today: 1) Its value clashes with STATX_ATTR_MOUNT_ROOT as dhowells previously reported 2) It is not set in the statx attributes_mask as reported by xifeng This short series changes the STATX_ATTR_DAX value, and moves the reporting

Re: UAPI value collision: STATX_ATTR_MOUNT_ROOT vs STATX_ATTR_DAX

On 11/25/20 10:50 AM, David Howells wrote: > Hi Linus, Miklos, Ira, > > It seems that two patches that got merged in the 5.8 merge window collided and > no one noticed until now: > > 80340fe3605c0 (Miklos Szeredi 2020-05-14 184) #define > STATX_ATTR_MOUNT_ROOT 0x2000 /*

Re: [PATCH] xfs: check the return value of krealloc() in xfs_uuid_mount

On 11/25/20 12:50 AM, Qinglang Miao wrote: > krealloc() may fail to expand the memory space. Even with __GFP_NOFAIL? * ``GFP_KERNEL | __GFP_NOFAIL`` - overrides the default allocator behavior and all allocation requests will loop endlessly until they succeed. This might be really

Re: [PATCH 1/2] xfs: show the dax option in mount options.

options when only one was given, but if legacy apps rely on finding a bare "dax," then I guess it seems harmless enough... Reviewed-by: Eric Sandeen > --- > fs/xfs/xfs_super.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/xfs/xfs_super.c b/fs/

Re: [PATCH] xfs: fix Kconfig asking about XFS_SUPPORT_V4 when XFS_FS=n

Signed-off-by: Darrick J. Wong Reviewed-by: Eric Sandeen > --- > fs/xfs/Kconfig |1 + > 1 file changed, 1 insertion(+) > > diff --git a/fs/xfs/Kconfig b/fs/xfs/Kconfig > index 547e9e93..9fac5ea8d0e4 100644 > --- a/fs/xfs/Kconfig > +++ b/fs/xfs/Kconfig

Re: [PATCH] iomap: Fix direct I/O write consistency check

On 9/3/20 11:56 AM, Andreas Gruenbacher wrote: > When a direct I/O write falls back to buffered I/O entirely, dio->size > will be 0 in iomap_dio_complete. Function invalidate_inode_pages2_range > will try to invalidate the rest of the address space. (Because if ->size == 0 and offset == 0, then

Re: [PATCH v2] iomap: Fix WARN_ON_ONCE() from unprivileged users

On 8/31/20 10:56 AM, Darrick J. Wong wrote: > On Mon, Aug 31, 2020 at 10:48:59AM -0500, Eric Sandeen wrote: >> On 8/30/20 8:45 PM, Qian Cai wrote: >>> It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by >>> unprivileged users which would taint t

Re: [PATCH v2] iomap: Fix WARN_ON_ONCE() from unprivileged users

On 8/30/20 8:45 PM, Qian Cai wrote: > It is trivial to trigger a WARN_ON_ONCE(1) in iomap_dio_actor() by > unprivileged users which would taint the kernel, or worse - panic if > panic_on_warn or panic_on_taint is set. Hence, just convert it to > pr_warn_ratelimited() to let users know their

Re: Inverted mount options completely broken (iversion,relatime)

On 7/29/20 11:32 AM, Josef Bacik wrote: > Hello, > > Eric reported a problem to me where we were clearing SB_I_VERSION on remount > of a btrfs file system.  After digging through I discovered it's because we > expect the proper flags that we want to be passed in via the mount() syscall, > and

Re: [PATCH] doc: cgroup: add f2fs and xfs to supported list for writeback

On 7/1/20 3:32 AM, Christoph Hellwig wrote: > On Tue, Jun 30, 2020 at 08:59:34AM -0500, Eric Sandeen wrote: >> On 6/30/20 12:42 AM, Christoph Hellwig wrote: >>> On Mon, Jun 29, 2020 at 02:08:09PM -0500, Eric Sandeen wrote: >>>> f2fs and xfs have both adde

Re: [PATCH] doc: cgroup: add f2fs and xfs to supported list for writeback

On 6/30/20 12:42 AM, Christoph Hellwig wrote: > On Mon, Jun 29, 2020 at 02:08:09PM -0500, Eric Sandeen wrote: >> f2fs and xfs have both added support for cgroup writeback: >> >> 578c647 f2fs: implement cgroup writeback support >> adfb5fb xfs: implement cgroup aware

[PATCH] doc: cgroup: add f2fs and xfs to supported list for writeback

f2fs and xfs have both added support for cgroup writeback: 578c647 f2fs: implement cgroup writeback support adfb5fb xfs: implement cgroup aware writeback so add them to the supported list in the docs. Signed-off-by: Eric Sandeen --- TBH I wonder about the wisdom of having this detail

Re: [PATCH v2] exfat: add the dummy mount options to be backward compatible with staging/exfat

On 5/21/20 9:05 AM, Namjae Jeon wrote: > As Ubuntu and Fedora release new version used kernel version equal to or > higher than v5.4, They started to support kernel exfat filesystem. > > Linus Torvalds reported mount error with new version of exfat on Fedora. > > exfat: Unknown parameter

Re: PROBLEM: XFS in-memory corruption with reflinks and duperemove: XFS (dm-4): Internal error xfs_trans_cancel at line 1048 of file fs/xfs/xfs_trans.c. Caller xfs_reflink_remap_extent+0x100/0x560

On 5/6/20 6:20 PM, Edwin Török wrote: >> (Obviously, a full metadump would be useful for confirming the shape >> of >> the refcount btree, but...first things first let's look at the >> filefrag >> output.) > I'll try to gather one, and find a place to store/share it. > > Best regards, > --Edwin

[PATCH] vfs: Fix EOVERFLOW testing in put_compat_statfs64

andle errors") Signed-off-by: Eric Sandeen --- Note, if it'd be better form to add: From: Al Viro please do so. Thanks, -Eric diff --git a/fs/statfs.c b/fs/statfs.c index eea7af6f2f22..2616424012ea 100644 --- a/fs/statfs.c +++ b/fs/statfs.c @@ -318,19 +318,10 @@ COMPAT_SYSCALL_DEFIN

Re: [PATCH] xfs: include QUOTA, FATAL ASSERT build options in XFS_BUILD_OPTIONS

On 9/16/19 11:24 AM, Darrick J. Wong wrote: > On Fri, Sep 06, 2019 at 02:26:46PM +0800, yu kuai wrote: >> In commit d03a2f1b9fa8 ("xfs: include WARN, REPAIR build options in >> XFS_BUILD_OPTIONS"), Eric pointed out that the XFS_BUILD_OPTIONS string, >> shown at module init time and in modinfo

Re: [PATCH] fs: xfs: xfs_log: Change return type from int to void

able: "error". Return > "0" on line 4926 > > Signed-off-by: Hariprasad Kelam Looks fine, the highest caller in the chain (calling xfs_log_mount_cancel) doesn't use the return value, either. Reviewed-by: Eric Sandeen > --- > fs/xfs/xfs_log.c |

Re: [PATCH 0/6] sysctl: add pending proc_do_large_bitmap fix

anyone considers these for stable as minor fixes, I'd recommend >> we also address the discrepancy on the read side of things: modify the >> test script to use diff against the target file instead of using the >> temp file. >> >> Eric Sandeen (2): >> te

Re: [PATCH 0/6] sysctl: add pending proc_do_large_bitmap fix

On 3/21/19 12:13 PM, Eric Sandeen wrote: > On 3/20/19 5:28 PM, Luis Chamberlain wrote: >> Andrew, Kees, >> >> Eric sent a fix out for proc_do_large_bitmap() last month for when >> using a large input buffer. After patch review a test case for the issue >> w

Re: [PATCH 0/6] sysctl: add pending proc_do_large_bitmap fix

of things: modify the > test script to use diff against the target file instead of using the > temp file. > > Eric Sandeen (2): > test_sysctl: add proc_do_large_bitmap() test case > sysctl: Fix proc_do_large_bitmap for large input buffers Isn't this missing: [PATCH] sy

Re: [PATCH] sysctl: Fix proc_do_large_bitmap for large input buffers

On 2/20/19 5:32 PM, Eric Sandeen wrote: > Today, proc_do_large_bitmap() truncates a large write input buffer > to PAGE_SIZE - 1, which may result in misparsed numbers at the > (truncated) end of the buffer. Further, it fails to notify the caller > that the buffer was truncated, so it

[PATCH V2] test_sysctl: add proc_do_large_bitmap test function

Add test to build up bitmap range string and test the bitmap proc handler. Signed-off-by: Eric Sandeen --- V2: set rc=0 for test success however this still fails indeterminately for me. Debugging, if I save off the test write string and the read string, re-writing it to the handler works fine

Re: [PATCH] test_sysctl: add proc_do_large_bitmap test function

On 2/21/19 12:43 PM, Eric Sandeen wrote: > Add test to build up bitmap range string and test the bitmap > proc handler. > > Signed-off-by: Eric Sandeen > --- > > nb: test_modprobe & load_req_mod fail for me before we ever > get to this test, but commenting them o

[PATCH] test_sysctl: add proc_do_large_bitmap test function

Add test to build up bitmap range string and test the bitmap proc handler. Signed-off-by: Eric Sandeen --- nb: test_modprobe & load_req_mod fail for me before we ever get to this test, but commenting them out, my test runs as expected. I'm new to this script, so careful review would be

Re: [PATCH] sysctl: Fix proc_do_large_bitmap for large input buffers

On 2/21/19 11:52 AM, Luis Chamberlain wrote: > On Thu, Feb 21, 2019 at 11:47:49AM -0600, Eric Sandeen wrote: >> On 2/21/19 9:18 AM, Luis Chamberlain wrote: >>> On Wed, Feb 20, 2019 at 05:35:04PM -0600, Eric Sandeen wrote: >>>> Here's a pretty hacky tes

Re: [PATCH] sysctl: Fix proc_do_large_bitmap for large input buffers

On 2/21/19 9:18 AM, Luis Chamberlain wrote: > On Wed, Feb 20, 2019 at 05:35:04PM -0600, Eric Sandeen wrote: >> Here's a pretty hacky test script to test this code via >> ip_local_reserved_ports > > Thanks Eric! > > So /proc/sys/net/ipv4/ip_local_reserved_ports is a p

[PATCH] sysctl: add proc_do_large_bitmap test node

Add a test node for proc_do_large_bitmap to the test_sysctl.c infrastructure. It's sized the same as the one existing user. Signed-off-by: Eric Sandeen --- diff --git a/lib/test_sysctl.c b/lib/test_sysctl.c index 3dd801c1c85b..1263be4ebfaf 100644 --- a/lib/test_sysctl.c +++ b/lib/test_sysctl.c

Re: [PATCH] sysctl: Fix proc_do_large_bitmap for large input buffers

Here's a pretty hacky test script to test this code via ip_local_reserved_ports - #!/bin/bash # Randomly construct well-formed (sequential, non-overlapping) # input for ip_local_reserved_ports, feed it to the sysctl, # then read it back and check for differences. # Port range to use

[PATCH] sysctl: Fix proc_do_large_bitmap for large input buffers

er to come back for more. Signed-off-by: Eric Sandeen --- diff --git a/kernel/sysctl.c b/kernel/sysctl.c index ba4d9e85feb8..970a96659809 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -3089,9 +3089,13 @@ int proc_do_large_bitmap(struct ctl_table *table, int write,

Re: [PATCH] xfs: correct statx's result_mask value

On 1/7/19 11:15 PM, Su Yanjun wrote: > > > On 1/8/2019 1:07 PM, Darrick J. Wong wrote: >> On Tue, Jan 08, 2019 at 12:58:43PM +0800, Su Yanjun >> wrote: >>> >>> On 1/8/2019 2:04 AM, Eric Sandeen wrote: >>>> On 1/7/19 11:52 AM, Darrick J. W

Re: [PATCH] xfs: correct statx's result_mask value

On 1/7/19 11:52 AM, Darrick J. Wong wrote: > On Mon, Jan 07, 2019 at 04:53:10AM -0500, Su Yanjun wrote: >> For statx syscall, xfs return the wrong result_mask. >> >> Signed-off-by: Su Yanjun >> --- >> fs/xfs/xfs_iops.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git

Re: [PATCH] xfs: Remove noinline from #define STATIC

On 11/10/18 7:21 PM, Joe Perches wrote: > Reduce total object size quite a bit (~32KB) and presumably > improve performance at the same time. > > Total object size old vs new (x86-64 defconfig with xfs) > > text data bss dec hex filename > - 959351 165573 632

Re: [PATCH] xfs: Remove noinline from #define STATIC

On 11/10/18 7:21 PM, Joe Perches wrote: > Reduce total object size quite a bit (~32KB) and presumably > improve performance at the same time. > > Total object size old vs new (x86-64 defconfig with xfs) > > text data bss dec hex filename > - 959351 165573 632

Re: [PATCH] Fix misspelling issue in fs/xfs/kmem.c

On 11/9/18 5:40 PM, Darrick J. Wong wrote: > On Sat, Nov 10, 2018 at 07:23:01AM +0800, hmsjwzb wrote: > > Sorry, but all submissions must have a Signed-off-by: to be reviewed. > > Also, there's no To: header on this message?? Also, it's not the only misspelling, and not even the only

Re: [PATCH] Fix misspelling issue in fs/xfs/kmem.c

On 11/9/18 5:40 PM, Darrick J. Wong wrote: > On Sat, Nov 10, 2018 at 07:23:01AM +0800, hmsjwzb wrote: > > Sorry, but all submissions must have a Signed-off-by: to be reviewed. > > Also, there's no To: header on this message?? Also, it's not the only misspelling, and not even the only

Re: INFO: task hung in xlog_grant_head_check

On 6/11/18 8:20 AM, Dmitry Vyukov wrote: > On Wed, May 23, 2018 at 8:01 PM, Eric Sandeen wrote: ... >> As an aside, I wonder how much coverage of the V5 format code syzkaller >> /has/ >> achieved; that would be another useful datapoint google could provide - if &g

Re: INFO: task hung in xlog_grant_head_check

On 6/11/18 8:20 AM, Dmitry Vyukov wrote: > On Wed, May 23, 2018 at 8:01 PM, Eric Sandeen wrote: ... >> As an aside, I wonder how much coverage of the V5 format code syzkaller >> /has/ >> achieved; that would be another useful datapoint google could provide - if &g

Re: [PATCH V2] xfs: fix string handling in get/set functions

On 6/6/18 5:58 AM, Christoph Hellwig wrote: >> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c >> index 82f7c83c1dad..596e176c19a6 100644 >> --- a/fs/xfs/xfs_ioctl.c >> +++ b/fs/xfs/xfs_ioctl.c >> @@ -1828,13 +1828,13 @@ xfs_ioc_getlabel( >> /* Paranoia */ >>

Re: [PATCH V2] xfs: fix string handling in get/set functions

On 6/6/18 5:58 AM, Christoph Hellwig wrote: >> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c >> index 82f7c83c1dad..596e176c19a6 100644 >> --- a/fs/xfs/xfs_ioctl.c >> +++ b/fs/xfs/xfs_ioctl.c >> @@ -1828,13 +1828,13 @@ xfs_ioc_getlabel( >> /* Paranoia */ >>

Re: [PATCH] xfs: mark sb_fname as nonstring

On 6/5/18 4:23 PM, Arnd Bergmann wrote: > On Tue, Jun 5, 2018 at 8:44 PM, Eric Sandeen wrote: >> On 5/25/18 10:14 AM, Arnd Bergmann wrote: > >>> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c >>> index 84fbf164cbc3..eb79f2bc4dcc 100644 >>> --

Re: [PATCH] xfs: mark sb_fname as nonstring

On 6/5/18 4:23 PM, Arnd Bergmann wrote: > On Tue, Jun 5, 2018 at 8:44 PM, Eric Sandeen wrote: >> On 5/25/18 10:14 AM, Arnd Bergmann wrote: > >>> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c >>> index 84fbf164cbc3..eb79f2bc4dcc 100644 >>> --

[PATCH V2] xfs: fix string handling in get/set functions

("xfs: implement online get/set fs label") Cc: Eric Sandeen Cc: Martin Sebor Signed-off-by: Arnd Bergmann Signed-off-by: Eric Sandeen --- diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c index 82f7c83c1dad..596e176c19a6 100644 --- a/fs/xfs/xfs_ioctl.c +++ b/fs/xfs/xfs_ioctl.c @@ -

[PATCH V2] xfs: fix string handling in get/set functions

("xfs: implement online get/set fs label") Cc: Eric Sandeen Cc: Martin Sebor Signed-off-by: Arnd Bergmann Signed-off-by: Eric Sandeen --- diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c index 82f7c83c1dad..596e176c19a6 100644 --- a/fs/xfs/xfs_ioctl.c +++ b/fs/xfs/xfs_ioctl.c @@ -

Re: [PATCH] xfs: mark sb_fname as nonstring

e copies the extra character. > > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85602 > Fixes: f7664b31975b ("xfs: implement online get/set fs label") > Cc: Eric Sandeen > Cc: Martin Sebor > Signed-off-by: Arnd Bergmann > --- > fs/xfs/xfs_ioctl.c | 6 +++

Re: [PATCH] xfs: mark sb_fname as nonstring

e copies the extra character. > > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85602 > Fixes: f7664b31975b ("xfs: implement online get/set fs label") > Cc: Eric Sandeen > Cc: Martin Sebor > Signed-off-by: Arnd Bergmann > --- > fs/xfs/xfs_ioctl.c | 6 +++

Re: [PATCH resend 1/7] fs: allow per-device dax status checking for filesystems

tests are coming ;) Reviewed-by: Eric Sandeen <sand...@redhat.com> Signed-off-by: Darrick J. Wong <darrick.w...@oracle.com> Signed-off-by: Ross Zwisler <ross.zwis...@linux.intel.com> --- drivers/dax/super.c | 30 +++--- fs/ext2/super.c | 2 +- fs

Re: [PATCH resend 1/7] fs: allow per-device dax status checking for filesystems

inkle, i.e. mount -o dax means at least /one/ of the devices must support it, and then at runtime whichever file you try to use dax on still needs to be on a device that supports it ... but ok, anyway this seems fine functionally. you've assured me that xfstests are coming ;) Reviewed-by: Er

Re: [PATCH] xfs: mark sb_fname as nonstring

On 5/25/18 3:16 PM, Arnd Bergmann wrote: On Fri, May 25, 2018 at 6:53 PM, Eric Sandeen <sand...@redhat.com> wrote: On 5/25/18 10:14 AM, Arnd Bergmann wrote: ... @@ -1860,7 +1860,7 @@ xfs_ioc_setlabel( spin_lock(>m_sb_lock); memset(sbp->sb_fname, 0, sizeof(s

Re: [PATCH] xfs: mark sb_fname as nonstring

On 5/25/18 3:16 PM, Arnd Bergmann wrote: On Fri, May 25, 2018 at 6:53 PM, Eric Sandeen wrote: On 5/25/18 10:14 AM, Arnd Bergmann wrote: ... @@ -1860,7 +1860,7 @@ xfs_ioc_setlabel( spin_lock(>m_sb_lock); memset(sbp->sb_fname, 0, sizeof(sbp->sb_fname)); - st

Re: [PATCH] xfs: mark sb_fname as nonstring

etlabel(). Using the correct sizeof() argument here copies the extra character. Oops, you are correct. Sigh, I wonder why testing didn't see that. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85602 Fixes: f7664b31975b ("xfs: implement online get/set fs label") Cc: Eric Sandeen <s

Re: [PATCH] xfs: mark sb_fname as nonstring

etlabel(). Using the correct sizeof() argument here copies the extra character. Oops, you are correct. Sigh, I wonder why testing didn't see that. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85602 Fixes: f7664b31975b ("xfs: implement online get/set fs label") Cc: Eric Sandeen Cc

Re: Bugs involving maliciously crafted file system

On 5/23/18 7:59 PM, Theodore Y. Ts'o wrote: On Thu, May 24, 2018 at 10:49:31AM +1000, Dave Chinner wrote: We've learnt this lesson the hard way over and over again: don't parse untrusted input in privileged contexts. How many times do we have to make the same mistakes before people start to

Re: Bugs involving maliciously crafted file system

On 5/23/18 7:59 PM, Theodore Y. Ts'o wrote: On Thu, May 24, 2018 at 10:49:31AM +1000, Dave Chinner wrote: We've learnt this lesson the hard way over and over again: don't parse untrusted input in privileged contexts. How many times do we have to make the same mistakes before people start to

Re: INFO: task hung in xlog_grant_head_check

On 5/23/18 11:20 AM, Eric Biggers wrote: Hi Darrick, ... Now, if you *really* don't want syzbot to report XFS bugs as you believe XFS contains known unfixable bugs or for other reasons, you can formally ask Dmitry to remove CONFIG_XFS_FS from the syzbot config. But of course that doesn't

Re: INFO: task hung in xlog_grant_head_check

On 5/23/18 11:20 AM, Eric Biggers wrote: Hi Darrick, ... Now, if you *really* don't want syzbot to report XFS bugs as you believe XFS contains known unfixable bugs or for other reasons, you can formally ask Dmitry to remove CONFIG_XFS_FS from the syzbot config. But of course that doesn't

Re: WARNING: bad unlock balance in xfs_iunlock

On 5/8/18 9:37 PM, Eric Biggers wrote: > On Wed, May 09, 2018 at 10:50:11AM +1000, Dave Chinner wrote: >> On Tue, May 08, 2018 at 09:56:01AM +0200, Dmitry Vyukov wrote: >>> On Wed, May 2, 2018 at 12:51 AM, Dave Chinner wrote: Hello, syzbot hit the

Re: WARNING: bad unlock balance in xfs_iunlock

On 5/8/18 9:37 PM, Eric Biggers wrote: > On Wed, May 09, 2018 at 10:50:11AM +1000, Dave Chinner wrote: >> On Tue, May 08, 2018 at 09:56:01AM +0200, Dmitry Vyukov wrote: >>> On Wed, May 2, 2018 at 12:51 AM, Dave Chinner wrote: Hello, syzbot hit the following crash on

Re: WARNING: bad unlock balance in xfs_iunlock

On 5/8/18 2:52 AM, Dmitry Vyukov wrote: >> Or put another way, how did you arrive at the fs image values in the >> reproducer, >> i.e.: > Currently they are completely random, nobody taught syzkaller about AGFs, etc. So you just combine a few megabytes of purely random bits out of thin air

Re: WARNING: bad unlock balance in xfs_iunlock

On 5/8/18 2:52 AM, Dmitry Vyukov wrote: >> Or put another way, how did you arrive at the fs image values in the >> reproducer, >> i.e.: > Currently they are completely random, nobody taught syzkaller about AGFs, etc. So you just combine a few megabytes of purely random bits out of thin air

Re: WARNING: bad unlock balance in xfs_iunlock

On 4/30/18 9:02 AM, Dmitry Vyukov wrote: > On Mon, Apr 30, 2018 at 3:49 PM, Eric Sandeen <sand...@sandeen.net> wrote: ... >>> It just extracted kernel source file name that looked relevant >>> to this crash and run get_maintainers.pl on it. >>> Also the ima

Re: WARNING: bad unlock balance in xfs_iunlock

On 4/30/18 9:02 AM, Dmitry Vyukov wrote: > On Mon, Apr 30, 2018 at 3:49 PM, Eric Sandeen wrote: ... >>> It just extracted kernel source file name that looked relevant >>> to this crash and run get_maintainers.pl on it. >>> Also the image can contain dynamical

Re: WARNING: bad unlock balance in xfs_iunlock

On 4/30/18 8:23 AM, Dmitry Vyukov wrote: > On Mon, Apr 16, 2018 at 9:22 PM, Eric Sandeen <sand...@sandeen.net> wrote: ... >> It sure /seems/ to have a notion of images: what else is syz_mount_image()? >> >> i.e. you are mounting an image to reproduce the problem,

Re: WARNING: bad unlock balance in xfs_iunlock

On 4/30/18 8:23 AM, Dmitry Vyukov wrote: > On Mon, Apr 16, 2018 at 9:22 PM, Eric Sandeen wrote: ... >> It sure /seems/ to have a notion of images: what else is syz_mount_image()? >> >> i.e. you are mounting an image to reproduce the problem, correct? >> And the syste

Re: WARNING: bad unlock balance in xfs_iunlock

On 4/13/18 5:03 AM, Dmitry Vyukov wrote: > On Fri, Apr 6, 2018 at 6:10 PM, Darrick J. Wong > wrote: >> On Fri, Apr 06, 2018 at 07:38:44AM +1000, Dave Chinner wrote: >>> On Thu, Apr 05, 2018 at 08:54:50PM +0200, Dmitry Vyukov wrote: On Tue, Apr 3, 2018 at 6:38 AM,

Re: WARNING: bad unlock balance in xfs_iunlock

On 4/13/18 5:03 AM, Dmitry Vyukov wrote: > On Fri, Apr 6, 2018 at 6:10 PM, Darrick J. Wong > wrote: >> On Fri, Apr 06, 2018 at 07:38:44AM +1000, Dave Chinner wrote: >>> On Thu, Apr 05, 2018 at 08:54:50PM +0200, Dmitry Vyukov wrote: On Tue, Apr 3, 2018 at 6:38 AM, Dave Chinner wrote: >

Re: [PATCH] xfs: Change URL for the project in xfs.txt

On 3/2/18 3:57 PM, Dave Chinner wrote: > On Fri, Mar 02, 2018 at 09:24:01AM -0800, Darrick J. Wong wrote: >> On Fri, Mar 02, 2018 at 10:30:13PM +0900, Masanari Iida wrote: >>> The oss.sgi.com doesn't exist any more. >>> Change it to current project URL, https://xfs.wiki.kernel.org/ >>> >>>

Re: [PATCH] xfs: Change URL for the project in xfs.txt

On 3/2/18 3:57 PM, Dave Chinner wrote: > On Fri, Mar 02, 2018 at 09:24:01AM -0800, Darrick J. Wong wrote: >> On Fri, Mar 02, 2018 at 10:30:13PM +0900, Masanari Iida wrote: >>> The oss.sgi.com doesn't exist any more. >>> Change it to current project URL, https://xfs.wiki.kernel.org/ >>> >>>

Re: [lkp-robot] [fs] 332391a993: WARNING:at_fs/iomap.c:#iomap_dio_complete

On 10/10/17 9:36 AM, Jeff Moyer wrote: > kernel test robot writes: > >> FYI, we noticed the following commit (built with gcc-6): >> >> commit: 332391a9935da939319e473b4680e173df75afcf ("fs: Fix page cache >> inconsistency when mixing buffered and AIO DIO") >>

Re: [lkp-robot] [fs] 332391a993: WARNING:at_fs/iomap.c:#iomap_dio_complete

On 10/10/17 9:36 AM, Jeff Moyer wrote: > kernel test robot writes: > >> FYI, we noticed the following commit (built with gcc-6): >> >> commit: 332391a9935da939319e473b4680e173df75afcf ("fs: Fix page cache >> inconsistency when mixing buffered and AIO DIO") >>

Re: [PATCH 1/7] xfs: always use DAX if mount option is used

On 9/26/17 6:09 AM, Dave Chinner wrote: > On Tue, Sep 26, 2017 at 11:35:48AM +0200, Jan Kara wrote: >> On Tue 26-09-17 09:38:12, Dave Chinner wrote: >>> On Mon, Sep 25, 2017 at 05:13:58PM -0600, Ross Zwisler wrote: Before support for the per-inode DAX flag was disabled the XFS the code had

Re: [PATCH 1/7] xfs: always use DAX if mount option is used

On 9/26/17 6:09 AM, Dave Chinner wrote: > On Tue, Sep 26, 2017 at 11:35:48AM +0200, Jan Kara wrote: >> On Tue 26-09-17 09:38:12, Dave Chinner wrote: >>> On Mon, Sep 25, 2017 at 05:13:58PM -0600, Ross Zwisler wrote: Before support for the per-inode DAX flag was disabled the XFS the code had

Re: [linux-next][XFS][trinity] WARNING: CPU: 32 PID: 31369 at fs/iomap.c:993

On 9/18/17 4:31 PM, Dave Chinner wrote: > On Mon, Sep 18, 2017 at 09:28:55AM -0600, Jens Axboe wrote: >> On 09/18/2017 09:27 AM, Christoph Hellwig wrote: >>> On Mon, Sep 18, 2017 at 08:26:05PM +0530, Abdul Haleem wrote: Hi, A warning is triggered from: file fs/iomap.c in

Re: [linux-next][XFS][trinity] WARNING: CPU: 32 PID: 31369 at fs/iomap.c:993

On 9/18/17 4:31 PM, Dave Chinner wrote: > On Mon, Sep 18, 2017 at 09:28:55AM -0600, Jens Axboe wrote: >> On 09/18/2017 09:27 AM, Christoph Hellwig wrote: >>> On Mon, Sep 18, 2017 at 08:26:05PM +0530, Abdul Haleem wrote: Hi, A warning is triggered from: file fs/iomap.c in

Re: [PATCH 0/9] add ext4 per-inode DAX flag

On 9/5/17 5:35 PM, Ross Zwisler wrote: > The original intent of this series was to add a per-inode DAX flag to ext4 > so that it would be consistent with XFS. In my travels I found and fixed > several related issues in both ext4 and XFS. Hi Ross - hch had a lot of reasons to nuke the dax flag

Re: [PATCH 0/9] add ext4 per-inode DAX flag

On 9/5/17 5:35 PM, Ross Zwisler wrote: > The original intent of this series was to add a per-inode DAX flag to ext4 > so that it would be consistent with XFS. In my travels I found and fixed > several related issues in both ext4 and XFS. Hi Ross - hch had a lot of reasons to nuke the dax flag

Re: [PATCH 2/2] ext4: Improve a size determination in two functions

to make the corresponding size > determination a bit safer according to the Linux coding style convention. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net> Looks good, Reviewed-by: Eric Sandeen <sand..

Re: [PATCH 2/2] ext4: Improve a size determination in two functions

nation a bit safer according to the Linux coding style convention. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Looks good, Reviewed-by: Eric Sandeen > --- > fs/ext4/dir.c | 2 +- > fs/ext4/mmp.c | 2 +- > 2 files chan

Re: [PATCH 1/2] ext4: Delete an error message for a failed memory allocation in ext4_multi_mount_protect()

On 8/19/17 6:47 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 19 Aug 2017 13:04:50 +0200 > > Omit an extra message for a memory allocation failure in this function. I might be dense, but what makes this message "extra?" (I suppose kmalloc

Re: [PATCH 1/2] ext4: Delete an error message for a failed memory allocation in ext4_multi_mount_protect()

On 8/19/17 6:47 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 19 Aug 2017 13:04:50 +0200 > > Omit an extra message for a memory allocation failure in this function. I might be dense, but what makes this message "extra?" (I suppose kmalloc squawks too if it fails, but is

Re: [PATCH] xfs: avoid harmless gcc-7 warnings

y: Arnd Bergmann <a...@arndb.de> Thanks Arnd - Reviewed-by: Eric Sandeen <sand...@redhat.com> > --- > fs/xfs/xfs_bmap_util.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c >

Re: [PATCH] xfs: avoid harmless gcc-7 warnings

> '<' ? [-Werror=int-in-bool-context] > fs/xfs/xfs_bmap_util.c:1629:8: error: '<<' in boolean context, did you mean > '<' ? [-Werror=int-in-bool-context] > > This one is clearly fine, and we can add a comparison to zero > to shut up the warning. > > Signed

Re: [PATCH] xfs: do not call xfs_buf_hash_destroy on a NULL pag

On 1/20/17 8:26 AM, Colin King wrote: > From: Colin Ian King > > If pag cannot be allocated, the current error exit path will trip > a null pointer deference error when calling xfs_buf_hash_destroy > with a null pag. Fix this by adding a new error exit lable and >

Re: [PATCH] xfs: do not call xfs_buf_hash_destroy on a NULL pag

On 1/20/17 8:26 AM, Colin King wrote: > From: Colin Ian King > > If pag cannot be allocated, the current error exit path will trip > a null pointer deference error when calling xfs_buf_hash_destroy > with a null pag. Fix this by adding a new error exit lable and > jumping to this, avoiding the

Re: [PATCH 1/1 linux-next] xfs: remove unnecessary return

On 12/14/16 10:17 PM, Eric Sandeen wrote: > On 12/10/16 12:52 AM, Fabian Frederick wrote: >> Commit f7a136aee3c1 >> ("xfs: several xattr functions can be void") >> >> updated 2 end of function return 0 to return in void >> functions. Remove it. >> &

Re: [PATCH 1/1 linux-next] xfs: remove unnecessary return

On 12/14/16 10:17 PM, Eric Sandeen wrote: > On 12/10/16 12:52 AM, Fabian Frederick wrote: >> Commit f7a136aee3c1 >> ("xfs: several xattr functions can be void") >> >> updated 2 end of function return 0 to return in void >> functions. Remove it. >>

Re: [PATCH 1/1 linux-next] xfs: remove unnecessary return

On 12/10/16 12:52 AM, Fabian Frederick wrote: > Commit f7a136aee3c1 > ("xfs: several xattr functions can be void") > > updated 2 end of function return 0 to return in void > functions. Remove it. > > Signed-off-by: Fabian Frederick <f...@skynet.be> Oh, sure.

  1   2   3   4   5   6   7   >