Re: [PATCH 3/3] btrfs: switch to kvmalloc and GFP_KERNEL in lzo/zlib alloc_workspace

@@ -59,7 +59,7 @@ static struct list_head *zlib_alloc_workspace(void) workspacesize = max(zlib_deflate_workspacesize(MAX_WBITS, MAX_MEM_LEVEL), zlib_inflate_workspacesize()); - workspace->strm.workspace = vmalloc(workspacesize); +

Re: [PATCH 2/3] btrfs: switch kmallocs to GFP_KERNEL in lzo/zlib alloc_workspace

On 05/31/17 23:41, David Sterba wrote: As alloc_workspace is now protected by memalloc_nofs where needed, we can switch the kmalloc to use GFP_KERNEL. Signed-off-by: David Sterba Reviewed-by: Anand Jain Thanks, Anand --- fs/btrfs/lzo.c | 2 +-

Re: [PATCH 1/3] btrfs: add memalloc_nofs protections around alloc_workspace callback

On 05/31/17 23:41, David Sterba wrote: The workspaces are preallocated at the beginning where we can safely use GFP_KERNEL, but in some cases the find_workspace might reach the allocation again, now in a more restricted context when the bios or pages are being compressed. To avoid potential

Re: [PATCH v4 05/20] btrfs-progs: Introduce wrapper to recover raid56 data

At 05/31/2017 09:52 PM, David Sterba wrote: On Thu, May 25, 2017 at 02:21:50PM +0800, Qu Wenruo wrote: Introduce a wrapper to recover raid56 data. The logical is the same with kernel one, but with different interfaces, since kernel ones cares the performance while in btrfs we don't care that

Re: [RFC PATCH v3.2 5/6] btrfs: qgroup: Introduce extent changeset for qgroup reserve functions

At 05/31/2017 10:30 PM, David Sterba wrote: On Wed, May 31, 2017 at 08:31:35AM +0800, Qu Wenruo wrote: Yes it's hard to find such deadlock especially when lockdep will not detect it. And this makes the advantage of using stack memory in v3 patch more obvious. I didn't realize the extra

Re: Debugging Deadlocks?

On Wed, May 31, 2017 at 5:54 AM, David Sterba wrote: > On Tue, May 30, 2017 at 09:12:39AM -0700, Sargun Dhillon wrote: >> We've been running BtrFS for a couple months now in production on >> several clusters. We're running on Canonical's 4.8 kernel, and >> currently, in the

Re: [PATCH v2] Btrfs: fix invalid extent maps due to hole punching

On Sun, May 28, 2017 at 10:31:05PM +0100, fdman...@kernel.org wrote: > From: Filipe Manana > > While punching a hole in a range that is not aligned with the sector size > (currently the same as the page size) we can end up leaving an extent map > in memory with a length that

Re: Debugging Deadlocks?

On Wed, May 31, 2017 at 06:47:09AM +, Duncan wrote: > Sargun Dhillon posted on Tue, 30 May 2017 09:12:39 -0700 as excerpted: > > currently, in the process of moving to our own patchset atop vanilla > > 4.10+ > > Good for getting off kernel 4.8, as in mainline kernel terms that's only > a

hi

-- Please contact me in the my e-mail addres,(griestkrist1...@gmail.com) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH 4/5] btrfs: use GFP_KERNEL in init_ipath

Now that init_ipath is called either from a safe context or with memalloc_nofs protection, we can switch to GFP_KERNEL allocations in init_path and init_data_container. Signed-off-by: David Sterba --- fs/btrfs/backref.c | 10 +- fs/btrfs/ioctl.c | 4 ++-- 2 files

[PATCH 0/5] More vmalloc cleanups

All vmalloc/vzalloc calls should be addressed, in this or the currently pending patches. David Sterba (5): btrfs: replace opencoded kvzalloc with the helper btrfs: send: use kvmalloc in iterate_dir_item btrfs: scrub: add memalloc_nofs protection around init_ipath btrfs: use GFP_KERNEL in

[PATCH 2/5] btrfs: send: use kvmalloc in iterate_dir_item

We use a growing buffer for xattrs larger than a page size, at some point vmalloc is unconditionally used for larger buffers. We can still try to avoid it using the kvmalloc helper. Signed-off-by: David Sterba --- fs/btrfs/send.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 3/5] btrfs: scrub: add memalloc_nofs protection around init_ipath

init_ipath is called from a safe ioctl context and from scrub when printing an error. The protection is added for three reasons: * init_data_container calls vmalloc and this does not work as expected in the GFP_NOFS context, so this silently does GFP_KERNEL and might deadlock in some cases *

[PATCH 1/5] btrfs: replace opencoded kvzalloc with the helper

The logic of kmalloc and vmalloc fallback is open coded in several places, we can now use the existing helper. Signed-off-by: David Sterba --- fs/btrfs/check-integrity.c | 11 --- fs/btrfs/raid56.c | 11 --- fs/btrfs/send.c| 9 +++-- 3

[PATCH 5/5] btrfs: adjust includes after vmalloc removal

As we don't use vmalloc/vzalloc/vfree directly in ctree.c, we can now use the proper header that defines kvmalloc. Signed-off-by: David Sterba --- fs/btrfs/ctree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c index

[PATCH 0/3] Update gfp flags in alloc_workspace

We can cheaply get rid of a few GFP_NOFS, as there are only two contexts, initializaton (GFP_KERNEL is ok), and potentially a "NOFS", but with memalloc_nofs it's made safe. David Sterba (3): btrfs: add memalloc_nofs protections around alloc_workspace callback btrfs: switch kmallocs to

[PATCH 1/3] btrfs: add memalloc_nofs protections around alloc_workspace callback

The workspaces are preallocated at the beginning where we can safely use GFP_KERNEL, but in some cases the find_workspace might reach the allocation again, now in a more restricted context when the bios or pages are being compressed. To avoid potential lockup when alloc_workspace -> vmalloc would

[PATCH 2/3] btrfs: switch kmallocs to GFP_KERNEL in lzo/zlib alloc_workspace

As alloc_workspace is now protected by memalloc_nofs where needed, we can switch the kmalloc to use GFP_KERNEL. Signed-off-by: David Sterba --- fs/btrfs/lzo.c | 2 +- fs/btrfs/zlib.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/lzo.c

[PATCH 3/3] btrfs: switch to kvmalloc and GFP_KERNEL in lzo/zlib alloc_workspace

The compression workspace buffers are larger than a page so we use vmalloc, unconditionally. This is not always necessary as there might be contiguous memory available. Let's use the kvmalloc helpers that will try kmalloc first and fallback to vmalloc. For that they require GFP_KERNEL flags. As

Re: [RFC PATCH v3.2 5/6] btrfs: qgroup: Introduce extent changeset for qgroup reserve functions

On Wed, May 31, 2017 at 08:31:35AM +0800, Qu Wenruo wrote: > >> Yes it's hard to find such deadlock especially when lockdep will not > >> detect it. > >> > >> And this makes the advantage of using stack memory in v3 patch more > >> obvious. > >> > >> I didn't realize the extra possible deadlock

Re: [PATCH v4 00/20] Btrfs-progs offline scrub

On Tue, May 30, 2017 at 08:54:32PM +0200, David Sterba wrote: > On Thu, May 25, 2017 at 02:21:45PM +0800, Qu Wenruo wrote: > > For any one who wants to try it, it can be get from my repo: > > https://github.com/adam900710/btrfs-progs/tree/offline_scrub > > Qu Wenruo (20): > > btrfs-progs:

Re: [PATCH v4 05/20] btrfs-progs: Introduce wrapper to recover raid56 data

On Thu, May 25, 2017 at 02:21:50PM +0800, Qu Wenruo wrote: > Introduce a wrapper to recover raid56 data. > > The logical is the same with kernel one, but with different interfaces, > since kernel ones cares the performance while in btrfs we don't care > that much. Can you please rephrase this

Re: [PATCH v4 01/20] btrfs-progs: raid56: Introduce raid56 header for later recovery usage

On Thu, May 25, 2017 at 02:21:46PM +0800, Qu Wenruo wrote: > @@ -0,0 +1,28 @@ > +/* > + * Copyright (C) 2017 Fujitsu. All rights reserved. Please use just plain GPL v2 header in newly created files. The history of who modified what in the given file is stored in git. I can't simply remove the

Re: Debugging Deadlocks?

On Tue, May 30, 2017 at 09:12:39AM -0700, Sargun Dhillon wrote: > We've been running BtrFS for a couple months now in production on > several clusters. We're running on Canonical's 4.8 kernel, and > currently, in the process of moving to our own patchset atop vanilla > 4.10+. I'm glad to say it's

Re: Btrfs wiki account

On Wed, May 31, 2017 at 01:46:17PM +0200, David Sterba wrote: > On Wed, May 31, 2017 at 07:35:24PM +0800, chou Dai wrote: > > Hi,I wanted to add some content and edit some content to wiki,but I > > made a registration two week ago(Account Name:Dai chou) . Now, I still > > cannot register, through

Re: Btrfs wiki account

On Wed, May 31, 2017 at 07:35:24PM +0800, chou Dai wrote: > Hi,I wanted to add some content and edit some content to wiki,but I > made a registration two week ago(Account Name:Dai chou) . Now, I still > cannot register, through registration request expired already. And > Btrfs wiki says"Just drop

Btrfs wiki account

Hi,I wanted to add some content and edit some content to wiki,but I made a registration two week ago(Account Name:Dai chou) . Now, I still cannot register, through registration request expired already. And Btrfs wiki says"Just drop a mail on linux kernel btrfs mailing list with an appropriate

[PATCH v2] Btrfs: fix invalid extent maps due to hole punching

From: Filipe Manana While punching a hole in a range that is not aligned with the sector size (currently the same as the page size) we can end up leaving an extent map in memory with a length that is smaller then the sector size, which is not expected and can lead to problems.

Re: [PATCH] Btrfs: fix invalid extent maps due to hole punching

On Tue, May 30, 2017 at 9:50 PM, Omar Sandoval wrote: > On Sun, May 28, 2017 at 05:31:53PM +0100, fdman...@kernel.org wrote: >> From: Filipe Manana > > [snip] > > Hey, Filipe, > > I saw this warning and tried to apply your patch, but it doesn't apply >

Re: [PATCH 09/10] xfs: nowait aio support

On Tue 30-05-17 11:13:29, Goldwyn Rodrigues wrote: > > Btw, can you write a small blurb up for the man page to document these > > ѕemantics in man-page like language? > > > > Yes, but which man page would it belong to? > Should it be a subsection of errors in io_getevents/io_submit. We don't >

[RFC PATCH] btrfs: qgroup: Fix hang when using inode_cache and qgroup

Commit 48a89bc4f2ce ("btrfs: qgroups: Retry after commit on getting EDQUOT") is causing hang, with the following backtrace: Call Trace: __schedule+0x374/0xaf0 schedule+0x3d/0x90 wait_for_commit+0x4a/0x80 [btrfs] ? wake_atomic_t_function+0x60/0x60 btrfs_commit_transaction+0xe0/0xa10 [btrfs]

Re: Debugging Deadlocks?

Sargun Dhillon posted on Tue, 30 May 2017 09:12:39 -0700 as excerpted: > We've been running BtrFS for a couple months now in production on > several clusters. We're running on Canonical's 4.8 kernel, and > currently, in the process of moving to our own patchset atop vanilla > 4.10+. I'm glad to