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 kern
if we 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/
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]
>>
>> Adj
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]
> https://lore.kernel.org/lkml/3e28d2c7-fbe5-298a-1
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 thi
or some 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: Chan
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?
>
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 th
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
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
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;
>>
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, c
ts" [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 S
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 Sa
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
fr
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 /* Roo
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 danger
tions 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/xfs
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
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 i
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 the
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 workloa
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 b
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
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 wri
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 in
the
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 'n
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
M
not handle 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_SYS
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 outpu
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
>> Before 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 Sandee
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
ncy 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):
> test_sysctl: add proc_do_large_bitmap() test case
> sysctl: Fix proc_do_large_bitmap for large input buffers
Isn't
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
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
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
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 woul
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 hack
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 i
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_sys
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
PORT_ST
k the caller 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,
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
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 a/fs/xfs/xfs_i
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 112
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 instance
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
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 */
>> BUILD_BUG_ON(sizeof(s
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
>>> --
racter.
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
Signed-off-by: Eric Sandeen
---
diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
index 82f
label back to user space in getlabel().
> Using the correct sizeof() argument here 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: Marti
is wrinkle, 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 ;)
Revie
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(&mp->m_sb_lock);
memset(sbp->sb_fname, 0, sizeof(sbp->sb_fname));
-
ly skip the trailing
\0 when copying a 12-character label back to user space in getlabel().
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:
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 lear
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 mak
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 up
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 unti
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 dynamically
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
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:
> O
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/
>>>
>>> Signed
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")
>> https://git.kernel.org/cgit/linux/k
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
>
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 fu
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 fr
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
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 Cocci
ntext, did you mean
> '<' ? [-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 z
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 h
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.
>>
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
Oh, sure. :)
Reviewed-by:
On 12/12/16 2:50 PM, Joe Perches wrote:
> On Mon, 2016-12-12 at 14:41 -0600, Eric Sandeen wrote:
>> On 12/12/16 2:34 PM, Ozgur Karatas wrote:
> []
>>> Can you tell me the true code style? should use to (* uuid)?
>>> I'm learn to new and I'm newbies :)
On 12/12/16 2:34 PM, Ozgur Karatas wrote:
> 12.12.2016, 20:35, "Eric Sandeen" :
>> On 12/12/16 12:14 PM, Joe Perches wrote:
...
>>>>> {
>>>>> xfs_uu_t *uup = (xfs_uu_t *)uuid;
>>>>>
>>>>>
On 12/12/16 12:14 PM, Joe Perches wrote:
> On Mon, 2016-12-12 at 07:49 -0600, Eric Sandeen wrote:
>> On 12/12/16 4:53 AM, Ozgur Karatas wrote:
>>>
>>> Hello,
>>>
>>> I have error to use uuid and I think the functions should be used when -i
On 12/12/16 4:53 AM, Ozgur Karatas wrote:
>
> Hello,
>
> I have error to use uuid and I think the functions should be used when -i'm
> eye-catching- "(* uuid)".
> I tested it.
>
> Regards,
>
> Signed-off-by: Ozgur Karatas
NAK
This doesn't fix code style at all; there is no need and no
prece
hex filename
> 801 0 8 809 329 fs/xfs/xfs_icreate_item.o
>
> Signed-off-by: Bhumika Goyal
Sure, every other xfs_item_ops structure is a const.
Reviewed-by: Eric Sandeen
> ---
> fs/xfs/xfs_icreate_item.c | 2 +-
> 1 file changed, 1 insertion(+
On 9/1/16 12:16 PM, Al Viro wrote:
> On Thu, Sep 01, 2016 at 08:10:44AM -0500, Eric Sandeen wrote:
>> On 8/4/16 8:57 AM, Al Viro wrote:
>>
>>> Don't feed the troll. On all paths leading to that place we have
>>> result->name = kname;
>>&g
On 8/4/16 8:57 AM, Al Viro wrote:
> Don't feed the troll. On all paths leading to that place we have
> result->name = kname;
> len = strncpy_from_user(kname, filename, EMBEDDED_NAME_MAX);
> or
> result->name = kname;
> len = strncpy_from_user(kname,
On 5/10/16 11:23 AM, Toshi Kani wrote:
> When a partition is not aligned by 4KB, mount -o dax succeeds,
Sorry for being late, but -
Shouldn't this and all subsequent patch commits refer to
PAGE_SIZE, rather than "4kB?"
-Eric
On 5/15/16 8:42 PM, kernel test robot wrote:
> FYI, we noticed the following commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> commit a08ee40a79653d082911cab9fbeff94baa7714cb ("xfs: sanitize remount
> options")
>
> on test machine: vm-kbuild-4G: 4 threads qe
On 4/18/16 1:20 PM, Florian Margaine wrote:
> On Mon, 2016-04-18 at 11:20 -0400, Eric Sandeen wrote:
>> >
>> > On 4/14/16 10:17 PM, Dave Chinner wrote:
>>> > > On Thu, Apr 14, 2016 at 09:57:07AM +0200, Florian Margaine wrote:
>>>> > > > T
On 4/14/16 10:17 PM, Dave Chinner wrote:
> On Thu, Apr 14, 2016 at 09:57:07AM +0200, Florian Margaine wrote:
>> This lets userland get the filesystem freezing status, aka whether the
>> filesystem is frozen or not. This is so that an application can know if
>> it should freeze the filesystem or i
On 3/16/16 7:15 PM, Theodore Ts'o wrote:
> On Wed, Mar 16, 2016 at 03:45:49PM -0600, Andreas Dilger wrote:
>>> Clearly, the performance hit of unwritten extent conversion is large
>>> enough to tempt people to ask for no-hide-stale. But I'd rather hear
>>> that directly from a developer, Ceph or o
On 3/15/16 7:06 PM, Linus Torvalds wrote:
> On Tue, Mar 15, 2016 at 4:52 PM, Dave Chinner wrote:
>> >
>> > It is pretty clear that the onus is on the patch submitter to
>> > provide justification for inclusion, not for the reviewer/Maintainer
>> > to have to prove that the solution is unworkable.
On 3/15/16 3:14 PM, Dave Chinner wrote:
> What we are missing is actual numbers that show that exposing stale
> data is a /significant/ win for these applications that are
> demanding it. And then we need evidence proving that the problem is
> actually systemic and not just a hack around a bad impl
Dave just sent a patch to the xfs list to fix this,
[PATCH] xfs: log recovery needs to be aware of CONFIG_XFS_RT now
Thanks,
-Eric
On 2/8/16 6:17 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the xfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> ER
On 9/3/15 1:22 PM, Richard Yao wrote:
> What happens with this patch if /dev/$DEVICE is ext4 formatted and someone
> runs
> `mount -t ext3 /dev/$DEVICE $MNT`?
>
> This should fail with the ext3 driver, but it looks like it will work fine
> with
> CONFIG_EXT4_USE_FOR_EXT23 because ext3_fs_type ma
> initializing inode. Move the inode initialization after the mapping
>> null check to avoid a potential null pointer dereference.
>>
>> Fixes: 22e757a49cf0 ("xfs: don't dirty buffers beyond EOF")
>> Signed-off-by: Colin Ian King
>> ---
>
> Review
On 8/31/15 5:39 PM, Linus Torvalds wrote:
> On Mon, Aug 31, 2015 at 3:31 PM, Raymond Jennings wrote:
>>
>> That said, I wouldn't mind myself if the ext4 driver were given a very
>> grueling regression test to make sure it can actually handle old ext3
>> systems as well as the ext3 driver can.
>
>
On 7/22/15 8:34 AM, Mike Snitzer wrote:
> On Tue, Jul 21 2015 at 10:37pm -0400,
> Dave Chinner wrote:
>
>> On Tue, Jul 21, 2015 at 09:40:29PM -0400, Mike Snitzer wrote:
>>
>>> I'm open to considering alternative interfaces for getting you the info
>>> you need. I just don't have a great sense fo
On 7/20/15 5:36 PM, Dave Chinner wrote:
> On Mon, Jul 20, 2015 at 11:18:49AM -0400, Mike Snitzer wrote:
>> If XFS fails to write metadata it will retry the write indefinitely
>> (with the hope that the write will succeed at some point in the future).
>>
>> Others can possibly speak to historic reas
On 7/15/15 10:09 AM, Randy Dunlap wrote:
> On 07/15/15 08:05, Randy Dunlap wrote:
>> On 07/15/15 07:18, Theodore Ts'o wrote:
>>> On Wed, Jul 15, 2015 at 12:26:24PM +0200, Jan Kara wrote:
so I have created this patch set which removes ext3 driver (and some
related support
code
On 5/7/15 10:24 PM, Andy Lutomirski wrote:
> On May 8, 2015 8:11 AM, "Dave Chinner" wrote:
>>
>> On Thu, May 07, 2015 at 10:20:53AM -0700, Zach Brown wrote:
>>> On Thu, May 07, 2015 at 10:26:17AM +1000, Dave Chinner wrote:
On Wed, May 06, 2015 at 03:00:12PM -0700, Zach Brown wrote:
> Add
On 4/15/15 2:15 AM, Beata Michalska wrote:
> Introduce configurable generic interface for file
> system-wide event notifications to provide file
> systems with a common way of reporting any potential
> issues as they emerge.
>
> The notifications are to be issued through generic
> netlink interfac
On 2/4/15 10:26 PM, Enrico Mioso wrote:
> That's fine - as long as we can say that a possibly very very big of
> "nobarrier" options could be stored some place in memory and cause damage.
> Thank you for the reply and attention.
> Please - don't remove me from CC as I am not subscribed to any list
On 2/4/15 9:22 PM, Enrico Mioso wrote:
> Hello guys.
> I noticed from some time, that I can make mount options accumulate simply
> continously repeating them.
> By typing:
> sudo mount -t ext4 -o rw,noatime,nobarrier,nobarrier,nobarrier, ...
> I can get:
> $ dmesg | tail
> [ 216.075581] EXT4-fs (
Commit-ID: a8b686b3af4419f92e0ea5be1c76fb68363df8e6
Gitweb: http://git.kernel.org/tip/a8b686b3af4419f92e0ea5be1c76fb68363df8e6
Author: Eric Sandeen
AuthorDate: Tue, 16 Dec 2014 16:25:28 -0600
Committer: Ingo Molnar
CommitDate: Wed, 14 Jan 2015 13:34:14 +0100
sched/debug: Check for
On 1/8/15 2:18 PM, Jaegeuk Kim wrote:
> On Thu, Jan 08, 2015 at 01:54:20PM -0600, Eric Sandeen wrote:
>> On 1/8/15 12:10 PM, Jaegeuk Kim wrote:
>>> This patch add an ioctl to shutdown f2fs, which stops all the further block
>>> writes after this point.
>>
>>
1 - 100 of 348 matches
Mail list logo
