Re: Rendering a btrfs filesystem unmountable with the btrfs command
Hi Eric, thanks for reporting this. I sent a small patch series to the list to fix this. Sorry I forgot to CC you, will send the patches to you directly again. It would be great if you could give it some testing. Thanks, Arne On 15.01.2013 21:44, hop...@omnifarious.org wrote: > mkfs.btrfs /dev/sdb > mkdir /tmp/mnt > mount /dev/sdb /tmp/mnt > cd /tmp/mnt > btrfs quota enable . > btrfs subvol create foo > btrfs qgroup create 1/0 > btrfs qgroup assign 0/257 1/0 > btrfs subvol snapshot foo bar > btrfs qgroup assign 0/258 1/0 > cd .. > umount /dev/sdb > mount /dev/sdb /tmp/mnt > # Still mountable! > cd mnt > btrfs qgroup destroy 1/0 > cd .. > umount /dev/sdb > mount /dev/sdb /tmp/mnt > # Oops, no longer mountable, even in recovery mode! > > Help! BTW, I'm not a mailing list subscriber. > > Thanks, -- 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 0/2] Btrfs: prevent qgroup config corruption by qgroup destroy
When destroying an active qgroup with qgroup destroy, the internal config will become corrupt. This series adds 2 fixes: the first add a recovery, if the config is already corrupt, and the second prevents the destroy if it is still active. Arne Jansen (2): btrfs: ignore orphan qgroup relations btrfs: prevent qgroup destroy when there are still relations fs/btrfs/qgroup.c | 20 +++- 1 files changed, 19 insertions(+), 1 deletions(-) -- 1.7.3.4 -- 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 2/2] Btrfs: prevent qgroup destroy when there are still relations
Currently you can just destroy a qgroup even though it is in use by other
qgroups
or has qgroups assigned to it. This patch prevents destruction of qgroups unless
they are completely unused. Otherwise destroy will return EBUSY.
Reported-by: Eric Hopper
Signed-off-by: Arne Jansen
---
fs/btrfs/qgroup.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
index 28f2b39..a5c8562 100644
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -963,17 +963,28 @@ int btrfs_remove_qgroup(struct btrfs_trans_handle *trans,
struct btrfs_fs_info *fs_info, u64 qgroupid)
{
struct btrfs_root *quota_root;
+ struct btrfs_qgroup *qgroup;
int ret = 0;
quota_root = fs_info->quota_root;
if (!quota_root)
return -EINVAL;
+ /* check if there are no relations to this qgroup */
+ spin_lock(&fs_info->qgroup_lock);
+ qgroup = find_qgroup_rb(fs_info, qgroupid);
+ if (qgroup) {
+ if (!list_empty(&qgroup->groups) ||
!list_empty(&qgroup->members)) {
+ spin_unlock(&fs_info->qgroup_lock);
+ return -EBUSY;
+ }
+ }
+ spin_unlock(&fs_info->qgroup_lock);
+
ret = del_qgroup_item(trans, quota_root, qgroupid);
spin_lock(&fs_info->qgroup_lock);
del_qgroup_rb(quota_root->fs_info, qgroupid);
-
spin_unlock(&fs_info->qgroup_lock);
return ret;
--
1.7.3.4
--
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 1/2] Btrfs: ignore orphan qgroup relations
If a qgroup that has still assignments is deleted by the user, the corresponding
relations are left in the tree. This leads to an unmountable filesystem.
With this patch, those relations are simple ignored.
Reported-by: Eric Hopper
Signed-off-by: Arne Jansen
---
fs/btrfs/qgroup.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
index fe9d02c..28f2b39 100644
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -379,6 +379,13 @@ next1:
ret = add_relation_rb(fs_info, found_key.objectid,
found_key.offset);
+ if (ret == -ENOENT) {
+ printk(KERN_WARNING
+ "btrfs: orphan qgroup relation
0x%llx->0x%llx\n",
+ (unsigned long long)found_key.objectid,
+ (unsigned long long)found_key.offset);
+ ret = 0;/* ignore the error */
+ }
if (ret)
goto out;
next2:
--
1.7.3.4
--
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
Re: [PATCH V2] mm/slab: add a leak decoder callback
Hello, Liu Bo.
On Wed, Jan 16, 2013 at 11:03:13AM +0800, Liu Bo wrote:
> This adds a leak decoder callback so that slab destruction
> can use to generate debugging output for the allocated objects.
>
> Callers like btrfs are using their own leak tracking which will
> manage allocated objects in a list(or something else), this does
> indeed the same thing as what slab does. So adding a callback
> for leak tracking can avoid this as well as runtime overhead.
>
> (The idea is from Zach Brown .)
>
> Signed-off-by: Liu Bo
> ---
> v2: add a wrapper API for slab destruction to make decoder only
> work in particular path.
>
> fs/btrfs/extent_io.c | 26 --
> fs/btrfs/extent_map.c| 13 -
> include/linux/slab.h |2 ++
> include/linux/slab_def.h |1 +
> include/linux/slub_def.h |1 +
> mm/slab_common.c | 17 -
> mm/slub.c|2 ++
> 7 files changed, 58 insertions(+), 4 deletions(-)
>
> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
> index bcc8dff..355c7fc 100644
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
> @@ -63,6 +63,26 @@ tree_fs_info(struct extent_io_tree *tree)
> return btrfs_sb(tree->mapping->host->i_sb);
> }
>
> +static void extent_state_leak_decoder(void *object)
> +{
> + struct extent_state *state = object;
> +
> + printk(KERN_ERR "btrfs state leak: start %llu end %llu "
> +"state %lu in tree %p refs %d\n",
> +(unsigned long long)state->start,
> +(unsigned long long)state->end,
> +state->state, state->tree, atomic_read(&state->refs));
> +}
> +
> +static void extent_buffer_leak_decoder(void *object)
> +{
> + struct extent_buffer *eb = object;
> +
> + printk(KERN_ERR "btrfs buffer leak start %llu len %lu "
> +"refs %d\n", (unsigned long long)eb->start,
> +eb->len, atomic_read(&eb->refs));
> +}
> +
> int __init extent_io_init(void)
> {
> extent_state_cache = kmem_cache_create("btrfs_extent_state",
> @@ -115,9 +135,11 @@ void extent_io_exit(void)
>*/
> rcu_barrier();
> if (extent_state_cache)
> - kmem_cache_destroy(extent_state_cache);
> + kmem_cache_destroy_decoder(extent_state_cache,
> +extent_state_leak_decoder);
> if (extent_buffer_cache)
> - kmem_cache_destroy(extent_buffer_cache);
> + kmem_cache_destroy_decoder(extent_buffer_cache,
> +extent_buffer_leak_decoder);
> }
>
> void extent_io_tree_init(struct extent_io_tree *tree,
> diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
> index f359e4c..bccba3d 100644
> --- a/fs/btrfs/extent_map.c
> +++ b/fs/btrfs/extent_map.c
> @@ -16,6 +16,16 @@ static LIST_HEAD(emaps);
> static DEFINE_SPINLOCK(map_leak_lock);
> #endif
>
> +static void extent_map_leak_decoder(void *object)
> +{
> + struct extent_map *em = object;
> +
> + printk(KERN_ERR "btrfs ext map leak: start %llu len %llu block %llu "
> +"flags %lu refs %d in tree %d compress %d\n",
> +em->start, em->len, em->block_start, em->flags,
> +atomic_read(&em->refs), em->in_tree, (int)em->compress_type);
> +}
> +
> int __init extent_map_init(void)
> {
> extent_map_cache = kmem_cache_create("btrfs_extent_map",
> @@ -39,7 +49,8 @@ void extent_map_exit(void)
> }
>
> if (extent_map_cache)
> - kmem_cache_destroy(extent_map_cache);
> + kmem_cache_destroy_decoder(extent_map_cache,
> +extent_map_leak_decoder);
> }
>
> /**
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index 5d168d7..5c6a8d8 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -114,6 +114,7 @@ struct kmem_cache {
> const char *name; /* Slab name for sysfs */
> int refcount; /* Use counter */
> void (*ctor)(void *); /* Called on object slot creation */
> + void (*decoder)(void *);/* Called on object slot leak detection */
> struct list_head list; /* List of all slab caches on the system */
> };
> #endif
> @@ -132,6 +133,7 @@ struct kmem_cache *
> kmem_cache_create_memcg(struct mem_cgroup *, const char *, size_t, size_t,
> unsigned long, void (*)(void *), struct kmem_cache *);
> void kmem_cache_destroy(struct kmem_cache *);
> +void kmem_cache_destroy_decoder(struct kmem_cache *, void (*)(void *));
> int kmem_cache_shrink(struct kmem_cache *);
> void kmem_cache_free(struct kmem_cache *, void *);
>
For SLUB,
kmem_cache_destroy_decoder works when CONFIG_SLUB_DEBUG is enable.
But, user for kmem_cache_destroy_decoder can't know about it.
How about below approach?
#ifdef CONFIG_SLUB_DEBUG
void kmem_cache_destroy_decoder(struct kmem_cache *, void (*)(void *));
#else
#define kmem_cache_destroy_decoder(s) kmem_cache_destor
Re: kernel BUG at fs/btrfs/volumes.c:3707 still not fixed in 3.7.1 (btrfs-zero-log required) but shown as "RIP btrfs_num_copies"
On Sat, Jan 12, 2013 at 07:12:12PM -0800, Marc MERLIN wrote: > On Fri, Jan 11, 2013 at 09:49:52AM -0500, Josef Bacik wrote: > > Probably just related to whatever corruption it is you are seeing. > > So I have no corruption afterall, correct? > > That's good news, but then it does mean that unclean sudden shutdowns in the > wrong place. > > I still have a truncated fs_image if someone wants it, and with an > apparently uncorrupted FS, btrfs-image is still dying for me: > andalfthegreat:~# btrfs-image -c 9 /dev/mapper/cryptroot /var/tmp/fs_image2 > Check tree block failed, want=4261896192, have=10797364022063960087 > Check tree block failed, want=4261896192, have=10797364022063960087 > Check tree block failed, want=4261896192, have=13996544474027288730 > Check tree block failed, want=4261896192, have=10797364022063960087 > Check tree block failed, want=4261896192, have=10797364022063960087 want= are around 4G, have= numbers are way off, very likely a corruption. the number does not translate into a meaningful pattern. david -- 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
Re: kernel BUG at fs/btrfs/volumes.c:3707 still not fixed in 3.7.1 (btrfs-zero-log required) but shown as "RIP btrfs_num_copies"
On Thu, Jan 17, 2013 at 12:31:22PM +0100, David Sterba wrote: > On Sat, Jan 12, 2013 at 07:12:12PM -0800, Marc MERLIN wrote: > > On Fri, Jan 11, 2013 at 09:49:52AM -0500, Josef Bacik wrote: > > > Probably just related to whatever corruption it is you are seeing. > > > > So I have no corruption afterall, correct? > > > > That's good news, but then it does mean that unclean sudden shutdowns in > > the wrong place. > > > > I still have a truncated fs_image if someone wants it, and with an > > apparently uncorrupted FS, btrfs-image is still dying for me: > > andalfthegreat:~# btrfs-image -c 9 /dev/mapper/cryptroot /var/tmp/fs_image2 > > Check tree block failed, want=4261896192, have=10797364022063960087 > > Check tree block failed, want=4261896192, have=10797364022063960087 > > Check tree block failed, want=4261896192, have=13996544474027288730 > > Check tree block failed, want=4261896192, have=10797364022063960087 > > Check tree block failed, want=4261896192, have=10797364022063960087 > > want= are around 4G, have= numbers are way off, very likely a > corruption. the number does not translate into a meaningful pattern. Thanks for your answer, I appreciate it. So this is the corruption that ends up in my log, and if I remove the log that happened before the laptop died, then the rest of the filesystem seems ok and scrub finds nothing wrong. My very uneducatd guess is that when my SSD craps out, just before my laptop locks up, it's either responsible for causing that corrupted log to be written, or there is a bug in btrfs that happens where truncated writes happen before a device comes of the sata bus. Either way, I got this bug multiple times with the same device (which I just replaced yesterday, just in case). Here's what I've seen so far in case there is a useful pattern. There is a mix of what I got from btrfs-zero-log and btrfs-image. I did get the problem more often than just those, but those are the ones I recorded before zero'ing the log. Check tree block failed, want=259264512, have=12301165138967429629 Check tree block failed, want=259264512, have=12301165138967429629 Check tree block failed, want=259264512, have=7949122546735189447 Check tree block failed, want=259264512, have=12301165138967429629 Check tree block failed, want=259264512, have=12301165138967429629 Check tree block failed, want=4268204032, have=2075122916315869932 Check tree block failed, want=4268204032, have=2075122916315869932 Check tree block failed, want=4268204032, have=12746175583536274708 Check tree block failed, want=4268204032, have=2075122916315869932 Check tree block failed, want=4268204032, have=2075122916315869932 Check tree block failed, want=5212229632, have=12481778023482407252 Check tree block failed, want=5212229632, have=12481778023482407252 Check tree block failed, want=5212229632, have=14440972074482314957 Check tree block failed, want=5212229632, have=12481778023482407252 Check tree block failed, want=5212229632, have=12481778023482407252 Check tree block failed, want=73949184, have=14419929907352990360 Check tree block failed, want=73949184, have=14419929907352990360 Check tree block failed, want=73949184, have=12288424950725929455 Check tree block failed, want=73949184, have=14419929907352990360 Check tree block failed, want=73949184, have=14419929907352990360 Check tree block failed, want=4261896192, have=10797364022063960087 Check tree block failed, want=4261896192, have=10797364022063960087 Check tree block failed, want=4261896192, have=13996544474027288730 Check tree block failed, want=4261896192, have=10797364022063960087 Check tree block failed, want=4261896192, have=10797364022063960087 I'm hopeful this is useful somehow, and hopefully btrfs will stop oops'ing at boot time, requiring a recovery disk and specialized knowledge to recover, when this happens. Thanks, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ -- 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
Re: [PATCH V5] Btrfs: snapshot-aware defrag
On Wed, Jan 16, 2013 at 6:36 AM, Liu Bo wrote:
> This comes from one of btrfs's project ideas,
> As we defragment files, we break any sharing from other snapshots.
> The balancing code will preserve the sharing, and defrag needs to grow this
> as well.
>
> Now we're able to fill the blank with this patch, in which we make full use of
> backref walking stuff.
>
> Here is the basic idea,
> o set the writeback ranges started by defragment with flag EXTENT_DEFRAG
> o at endio, after we finish updating fs tree, we use backref walking to find
>all parents of the ranges and re-link them with the new COWed file layout
> by
>adding corresponding backrefs.
>
> Signed-off-by: Li Zefan
> Signed-off-by: Liu Bo
> ---
> v4->v5:
> - Clarify the comments for duplicated refs.
> - Clear defrag flag after we're ready to defrag.
> - Fix a bug on HOLE extent.
> v3->v4:
> - Fix duplicated refs bugs detected by mounting with autodefrag, thanks
> for the bug report from Mitch and Chris.
> v2->v3:
> - Rebase
> v1->v2:
> - Address comments from David.
>
I've been testing this patch on a 3.7.2 kernel merged with the
for-linus branch for the 3.8_rc kernels, and I'm seeing the following
error:
[16028.159400] general protection fault: [#1] SMP
[16028.159461] Modules linked in: ipv6 snd_hda_codec_analog
snd_hda_intel snd_hda_codec tg3 snd_hwdep snd_pcm snd_page_alloc
snd_timer snd sr_mod ppdev parport_pc parport microcode iTCO_wdt
iTCO_vendor_support floppy lpc_ich i2c_i801 serio_raw pcspkr
ablk_helper cryptd lrw xts gf128mul aes_x86_64 sha256_generic fuse xfs
nfs lockd sunrpc reiserfs btrfs zlib_deflate ext4 jbd2 ext3 jbd ext2
mbcache sl811_hcd hid_generic xhci_hcd ohci_hcd uhci_hcd ehci_hcd
[16028.159952] CPU 0
[16028.159975] Pid: 4420, comm: btrfs-cleaner Not tainted 3.7.2-sad+
#4 Dell Inc. OptiPlex 745 /0WF810
[16028.160002] RIP: 0010:[] []
btrfs_clean_old_snapshots+0xa6/0x12c [btrfs]
[16028.160002] RSP: :880078609e38 EFLAGS: 00010282
[16028.160002] RAX: dead00200200 RBX: 8800 RCX: 00018e20
[16028.160002] RDX: dead00100100 RSI: 001b RDI: 001b
[16028.160002] RBP: 880078609e78 R08: 001c001b R09: a015aa01
[16028.160002] R10: a016bbbd R11: 8800183a4800 R12: 1600
[16028.160002] R13: 880078609e38 R14: 8800183a4800 R15: 8800183a4c38
[16028.160002] FS: () GS:88007f20()
knlGS:
[16028.160002] CS: 0010 DS: ES: CR0: 8005003b
[16028.160002] CR2: 7f64f5214d96 CR3: 11ef2000 CR4: 07f0
[16028.160002] DR0: DR1: DR2:
[16028.160002] DR3: DR6: 0ff0 DR7: 0400
[16028.160002] Process btrfs-cleaner (pid: 4420, threadinfo
880078608000, task 88007ca62120)
[16028.160002] Stack:
[16028.160002] 8800183a4c38 8800020e3c38 880078609e48
88007921b800
[16028.160002] 88007ca62120 88007ca62120 88007ca62120
[16028.160002] 880078609eb8 a0173f68 88007921b800
[16028.160002] Call Trace:
[16028.160002] [] cleaner_kthread+0x5a/0xe6 [btrfs]
[16028.160002] [] ? transaction_kthread+0x1a0/0x1a0 [btrfs]
[16028.160002] [] kthread+0xba/0xc2
[16028.160002] [] ? kthread_freezable_should_stop+0x52/0x52
[16028.160002] [] ret_from_fork+0x7c/0xb0
[16028.160002] [] ? kthread_freezable_should_stop+0x52/0x52
[16028.160002] Code: 49 bc 00 00 00 00 00 16 00 00 48 bb 00 00 00 00
00 88 ff ff eb 7d 4d 8d b7 c8 fb ff ff 4d 85 ff 75 02 0f 0b 49 8b 17
49 8b 47 08 <48> 89 42 08 48 89 10 48 be 00 01 10 00 00 00 ad de 49 89
37 48
[16028.160002] RIP []
btrfs_clean_old_snapshots+0xa6/0x12c [btrfs]
[16028.160002] RSP
[16028.170584] ---[ end trace 4034e68ac40e6c2b ]---
Using gdb to identify the location of the GPF gives me the following:
(gdb) list *(btrfs_clean_old_snapshots+0xa6)
0x2a4f2 is in btrfs_clean_old_snapshots (include/linux/list.h:88).
83 * This is only for internal list manipulation where we know
84 * the prev/next entries already!
85 */
86 static inline void __list_del(struct list_head * prev, struct
list_head * next)
87 {
88 next->prev = prev;
89 prev->next = next;
90 }
91
92 /**
I've tried to trap the error with a BUG_ON prior to deleting the list,
but my attempt isn't catching the error:
@@ -1769,6 +1769,7 @@ int btrfs_clean_old_snapshots(struct btrfs_root *root)
int ret;
root = list_entry(list.next, struct btrfs_root, root_list);
+ BUG_ON(&root->root_list == NULL);
list_del(&root->root_list);
btrfs_kill_all_delayed_nodes(root);
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More
[PATCH] trivial patch for btrfs-progs
Hi, please find attached a trivial patch for btrfs-progs. Likely not strictly needed but I noticed valgrind complaining about uninitialised memory in the ioctl call. Regards, Arvin -- Arvin Schnell, Senior Software Engineer, Research & Development SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany diff --git a/cmds-send.c b/cmds-send.c index 9b47e70..aa8c5a3 100644 --- a/cmds-send.c +++ b/cmds-send.c @@ -271,6 +271,7 @@ static int do_send(struct btrfs_send *send, u64 root_id, u64 parent_root) goto out; } + memset(&io_send, 0, sizeof(io_send)); io_send.send_fd = pipefd[1]; send->send_fd = pipefd[0];
Re: [PATCH] remove "device show" from btrfs man page
On Wed, Jan 09, 2013 at 03:14:13PM +0800, Jeff Liu wrote: > Hi Simon, > > For the next time when you post btrfs-progs related patches, please > indicate it with a suffix "Btrfs-progs: " on the subject. And please add a Signed-off-by: line (no need to resend the patch). david -- 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
[GIT PULL] btrfs-progs: more bugfixes for 0.20-rc1
Hi Chris, please pull a few more fixes to the 0.20-rc series. I have reviewed and verified them where possible. There are the long awaited ARM fixes, help updates and unsorted code fixes. git://repo.or.cz/btrfs-progs-unstable/devel.git for-chris Based on top of master commit 91d9eec1ff044394f2b98ee7fcb76713dd33b994 Thanks. david --- btrfs-list.c | 69 +- btrfsck.c |3 +- cmds-filesystem.c | 26 cmds-inspect.c|5 ++- cmds-receive.c|4 ++- cmds-scrub.c |4 ++- cmds-send.c |9 ++- convert.c |5 +++ ctree.h |8 -- debug-tree.c | 10 +++ disk-io.c | 13 -- kerncompat.h | 12 + man/btrfs.8.in|4 --- mkfs.c| 35 ++- restore.c |7 +++-- utils.c | 48 + utils.h |2 + version.sh|2 - volumes.c |8 +++--- 19 files changed, 159 insertions(+), 115 deletions(-) --- Alex Lyakas (1): btrfs-progs: Receive: preserve ownership for symlinks, by using 'lchown' Arne Jansen (1): Btrfs-progs: fix unaligned accesses David Sterba (2): btrfs-progs: do not send stream into a terminal btrfs-progs: ignore -a option in mkfs Goffredo Baroncelli (3): Move parse_size() to utils.[hc] parse_size(): replace atoll() with strtoull() parse_size(): add new suffixes Kenji Okimoto (3): btrfs-progs: plug a memory leak reported by cppcheck btrfs-progs: check malloc() result btrfs-progs: plug memory leaks in btrfs_scan_one_dir() reported by cppcheck. Lluis Batlle i Rossell (1): btrfs-progs: Fix getopt on arm platforms Sergei Trofimovich (1): version.sh: fix version when built from tarball Simon Xu (2): btrfs-progs: remove "device show" from btrfs man page btrfs-progs: remove '-h' from btrfs man page Wade Cline (1): Btrfs-progs: Fix compiler warnings on PPC64 Wang Sheng-Hui (3): btrfs-progs: add -V description in print_usage btrfs-progs: update usage description for debug-tree.c btrfs-progs: print the right mount checking info in restore.c Zach Brown (1): btrfs-progs: fix 32bit int/pointer cast warnings -- 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
Re: [GIT PULL] btrfs-progs: more bugfixes for 0.20-rc1
On Thu, Jan 17, 2013 at 10:47:21AM -0700, David Sterba wrote: > Hi Chris, > > please pull a few more fixes to the 0.20-rc series. I have reviewed and > verified them where possible. There are the long awaited ARM fixes, help > updates and unsorted code fixes. > > git://repo.or.cz/btrfs-progs-unstable/devel.git for-chris > > Based on top of master commit > 91d9eec1ff044394f2b98ee7fcb76713dd33b994 Thanks Dave, pulling these in. -chris -- 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
Re: [PATCH 4/4] fs: remove obsolete simple_strto
On Fri, 7 Dec 2012 17:25:19 +0530
Abhijit Pawar wrote:
> This patch replace the obsolete simple_strto with kstrto
>
The XFS part (or something like it) has been applied.
>
> ...
>
> --- a/fs/9p/v9fs.c
> +++ b/fs/9p/v9fs.c
> @@ -112,7 +112,7 @@ static int v9fs_parse_options(struct v9fs_session_info
> *v9ses, char *opts)
> substring_t args[MAX_OPT_ARGS];
> char *p;
> int option = 0;
> - char *s, *e;
> + char *s;
> int ret = 0;
>
> /* setup defaults */
> @@ -249,8 +249,8 @@ static int v9fs_parse_options(struct v9fs_session_info
> *v9ses, char *opts)
> v9ses->flags |= V9FS_ACCESS_CLIENT;
> } else {
> v9ses->flags |= V9FS_ACCESS_SINGLE;
> - v9ses->uid = simple_strtoul(s, &e, 10);
> - if (*e != '\0') {
> + ret = kstrtouint(s, 10, &v9ses->uid);
> + if (ret) {
> ret = -EINVAL;
> pr_info("Unknown access argument %s\n",
> s);
Here we should propagate the kstrtouint() errno back to the caller
rather than overwriting it with EINVAL.
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index 5b3429a..95d9e09 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -1335,7 +1335,11 @@ static noinline int btrfs_ioctl_resize(struct
> btrfs_root *root,
> sizestr = devstr + 1;
> *devstr = '\0';
> devstr = vol_args->name;
> - devid = simple_strtoull(devstr, &end, 10);
> + ret = kstrtoull(devstr, 10, &devid);
> + if (ret) {
> + ret = -EINVAL;
> + goto out_free;
> + }
Propagate the kstrtoull errno back to the caller.
> printk(KERN_INFO "btrfs: resizing devid %llu\n",
> (unsigned long long)devid);
> }
>
> ...
>
> @@ -609,8 +610,9 @@ static ssize_t cifs_security_flags_proc_write(struct file
> *file,
> }
> /* else we have a number */
>
> - flags = simple_strtoul(flags_string, NULL, 0);
> -
> + rc = kstrtouint(flags_string, 0, &flags);
> + if (rc)
> + return -EINVAL;
Here we should propagate the return value.
But if this error path is taken, we might already have altered
global_secflags. Perhaps that change should be undone. Or, better,
check the string before starting to change state.
> cFYI(1, "sec flags 0x%x", flags);
>
> if (flags <= 0) {
> --- a/fs/dlm/config.c
> +++ b/fs/dlm/config.c
> @@ -156,11 +156,14 @@ static ssize_t cluster_set(struct dlm_cluster *cl,
> unsigned int *cl_field,
> const char *buf, size_t len)
> {
> unsigned int x;
> + int rc;
>
> if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
>
> - x = simple_strtoul(buf, NULL, 0);
> + rc = kstrtouint(buf, 0, &x);
> + if (rc)
> + return -EINVAL;
Propagate it back.
> if (check_zero && !x)
> return -EINVAL;
> @@ -729,7 +732,10 @@ static ssize_t comm_nodeid_read(struct dlm_comm *cm,
> char *buf)
> static ssize_t comm_nodeid_write(struct dlm_comm *cm, const char *buf,
>size_t len)
> {
> - cm->nodeid = simple_strtol(buf, NULL, 0);
> + int rc;
> + rc = kstrtoint(buf, 0, &cm->nodeid);
> + if (rc)
> + return -EINVAL;
Ditto
> return len;
> }
>
> @@ -741,7 +747,10 @@ static ssize_t comm_local_read(struct dlm_comm *cm, char
> *buf)
> static ssize_t comm_local_write(struct dlm_comm *cm, const char *buf,
> size_t len)
> {
> - cm->local= simple_strtol(buf, NULL, 0);
> + int rc;
> + rc = kstrtoint(buf, 0, &cm->local);
> + if (rc)
> + return -EINVAL;
Ditto
> if (cm->local && !local_comm)
> local_comm = cm;
> return len;
> @@ -845,7 +854,10 @@ static ssize_t node_nodeid_write(struct dlm_node *nd,
> const char *buf,
>size_t len)
> {
> uint32_t seq = 0;
> - nd->nodeid = simple_strtol(buf, NULL, 0);
> + int rc;
> + rc = kstrtoint(buf, 0, &nd->nodeid);
> + if (rc)
> + return -EINVAL;
Ditto
> dlm_comm_seq(nd->nodeid, &seq);
> nd->comm_seq = seq;
> return len;
> @@ -859,7 +871,10 @@ static ssize_t node_weight_read(struct dlm_node *nd,
> char *buf)
> static ssize_t node_weight_write(struct dlm_node *nd, const char *buf,
>size_t len)
> {
> - nd->weight = simple_strtol(buf, NULL, 0);
> + int rc;
> + rc = kstrtoint(buf, 0, &nd->weight);
> + if (rc)
> + return -EINVAL;
Ditto
> return len;
> }
>
> diff --git a/fs/dlm/lockspace.c b/fs/dlm/lockspace.c
> index 2e99fb0..e83abfb 100644
> -
Re: [PATCH V5] Btrfs: snapshot-aware defrag
On Thu, Jan 17, 2013 at 08:42:46AM -0600, Mitch Harder wrote:
> On Wed, Jan 16, 2013 at 6:36 AM, Liu Bo wrote:
> > This comes from one of btrfs's project ideas,
> > As we defragment files, we break any sharing from other snapshots.
> > The balancing code will preserve the sharing, and defrag needs to grow this
> > as well.
> >
> > Now we're able to fill the blank with this patch, in which we make full use
> > of
> > backref walking stuff.
> >
> > Here is the basic idea,
> > o set the writeback ranges started by defragment with flag EXTENT_DEFRAG
> > o at endio, after we finish updating fs tree, we use backref walking to
> > find
> >all parents of the ranges and re-link them with the new COWed file
> > layout by
> >adding corresponding backrefs.
> >
> > Signed-off-by: Li Zefan
> > Signed-off-by: Liu Bo
> > ---
> > v4->v5:
> > - Clarify the comments for duplicated refs.
> > - Clear defrag flag after we're ready to defrag.
> > - Fix a bug on HOLE extent.
> > v3->v4:
> > - Fix duplicated refs bugs detected by mounting with autodefrag,
> > thanks
> > for the bug report from Mitch and Chris.
> > v2->v3:
> > - Rebase
> > v1->v2:
> > - Address comments from David.
> >
>
> I've been testing this patch on a 3.7.2 kernel merged with the
> for-linus branch for the 3.8_rc kernels, and I'm seeing the following
> error:
Hi Mitch,
Insteresting! I don't even change the snapshot code ever.
Is it reproducable stably from your side? Still with the
snapshot-test-pub scripts?
thanks,
liubo
>
> [16028.159400] general protection fault: [#1] SMP
> [16028.159461] Modules linked in: ipv6 snd_hda_codec_analog
> snd_hda_intel snd_hda_codec tg3 snd_hwdep snd_pcm snd_page_alloc
> snd_timer snd sr_mod ppdev parport_pc parport microcode iTCO_wdt
> iTCO_vendor_support floppy lpc_ich i2c_i801 serio_raw pcspkr
> ablk_helper cryptd lrw xts gf128mul aes_x86_64 sha256_generic fuse xfs
> nfs lockd sunrpc reiserfs btrfs zlib_deflate ext4 jbd2 ext3 jbd ext2
> mbcache sl811_hcd hid_generic xhci_hcd ohci_hcd uhci_hcd ehci_hcd
> [16028.159952] CPU 0
> [16028.159975] Pid: 4420, comm: btrfs-cleaner Not tainted 3.7.2-sad+
> #4 Dell Inc. OptiPlex 745 /0WF810
> [16028.160002] RIP: 0010:[] []
> btrfs_clean_old_snapshots+0xa6/0x12c [btrfs]
> [16028.160002] RSP: :880078609e38 EFLAGS: 00010282
> [16028.160002] RAX: dead00200200 RBX: 8800 RCX:
> 00018e20
> [16028.160002] RDX: dead00100100 RSI: 001b RDI:
> 001b
> [16028.160002] RBP: 880078609e78 R08: 001c001b R09:
> a015aa01
> [16028.160002] R10: a016bbbd R11: 8800183a4800 R12:
> 1600
> [16028.160002] R13: 880078609e38 R14: 8800183a4800 R15:
> 8800183a4c38
> [16028.160002] FS: () GS:88007f20()
> knlGS:
> [16028.160002] CS: 0010 DS: ES: CR0: 8005003b
> [16028.160002] CR2: 7f64f5214d96 CR3: 11ef2000 CR4:
> 07f0
> [16028.160002] DR0: DR1: DR2:
>
> [16028.160002] DR3: DR6: 0ff0 DR7:
> 0400
> [16028.160002] Process btrfs-cleaner (pid: 4420, threadinfo
> 880078608000, task 88007ca62120)
> [16028.160002] Stack:
> [16028.160002] 8800183a4c38 8800020e3c38 880078609e48
> 88007921b800
> [16028.160002] 88007ca62120 88007ca62120 88007ca62120
>
> [16028.160002] 880078609eb8 a0173f68 88007921b800
>
> [16028.160002] Call Trace:
> [16028.160002] [] cleaner_kthread+0x5a/0xe6 [btrfs]
> [16028.160002] [] ? transaction_kthread+0x1a0/0x1a0 [btrfs]
> [16028.160002] [] kthread+0xba/0xc2
> [16028.160002] [] ? kthread_freezable_should_stop+0x52/0x52
> [16028.160002] [] ret_from_fork+0x7c/0xb0
> [16028.160002] [] ? kthread_freezable_should_stop+0x52/0x52
> [16028.160002] Code: 49 bc 00 00 00 00 00 16 00 00 48 bb 00 00 00 00
> 00 88 ff ff eb 7d 4d 8d b7 c8 fb ff ff 4d 85 ff 75 02 0f 0b 49 8b 17
> 49 8b 47 08 <48> 89 42 08 48 89 10 48 be 00 01 10 00 00 00 ad de 49 89
> 37 48
> [16028.160002] RIP []
> btrfs_clean_old_snapshots+0xa6/0x12c [btrfs]
> [16028.160002] RSP
> [16028.170584] ---[ end trace 4034e68ac40e6c2b ]---
>
> Using gdb to identify the location of the GPF gives me the following:
>
> (gdb) list *(btrfs_clean_old_snapshots+0xa6)
> 0x2a4f2 is in btrfs_clean_old_snapshots (include/linux/list.h:88).
> 83 * This is only for internal list manipulation where we know
> 84 * the prev/next entries already!
> 85 */
> 86 static inline void __list_del(struct list_head * prev, struct
> list_head * next)
> 87 {
> 88 next->prev = prev;
> 89 prev->next = next;
> 90 }
> 91
> 92 /**
>
> I've tried to trap the error with a BUG_ON prior to deleting the list,
> but my attempt isn
Re: [PATCH V2] mm/slab: add a leak decoder callback
On Thu, Jan 17, 2013 at 05:34:46PM +0900, Joonsoo Kim wrote:
> Hello, Liu Bo.
>
> On Wed, Jan 16, 2013 at 11:03:13AM +0800, Liu Bo wrote:
> > This adds a leak decoder callback so that slab destruction
> > can use to generate debugging output for the allocated objects.
> >
> > Callers like btrfs are using their own leak tracking which will
> > manage allocated objects in a list(or something else), this does
> > indeed the same thing as what slab does. So adding a callback
> > for leak tracking can avoid this as well as runtime overhead.
> >
> > (The idea is from Zach Brown .)
> >
> > Signed-off-by: Liu Bo
> > ---
> > v2: add a wrapper API for slab destruction to make decoder only
> > work in particular path.
> >
> > fs/btrfs/extent_io.c | 26 --
> > fs/btrfs/extent_map.c| 13 -
> > include/linux/slab.h |2 ++
> > include/linux/slab_def.h |1 +
> > include/linux/slub_def.h |1 +
> > mm/slab_common.c | 17 -
> > mm/slub.c|2 ++
> > 7 files changed, 58 insertions(+), 4 deletions(-)
> >
> > diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
> > index bcc8dff..355c7fc 100644
> > --- a/fs/btrfs/extent_io.c
> > +++ b/fs/btrfs/extent_io.c
> > @@ -63,6 +63,26 @@ tree_fs_info(struct extent_io_tree *tree)
> > return btrfs_sb(tree->mapping->host->i_sb);
> > }
> >
> > +static void extent_state_leak_decoder(void *object)
> > +{
> > + struct extent_state *state = object;
> > +
> > + printk(KERN_ERR "btrfs state leak: start %llu end %llu "
> > + "state %lu in tree %p refs %d\n",
> > + (unsigned long long)state->start,
> > + (unsigned long long)state->end,
> > + state->state, state->tree, atomic_read(&state->refs));
> > +}
> > +
> > +static void extent_buffer_leak_decoder(void *object)
> > +{
> > + struct extent_buffer *eb = object;
> > +
> > + printk(KERN_ERR "btrfs buffer leak start %llu len %lu "
> > + "refs %d\n", (unsigned long long)eb->start,
> > + eb->len, atomic_read(&eb->refs));
> > +}
> > +
> > int __init extent_io_init(void)
> > {
> > extent_state_cache = kmem_cache_create("btrfs_extent_state",
> > @@ -115,9 +135,11 @@ void extent_io_exit(void)
> > */
> > rcu_barrier();
> > if (extent_state_cache)
> > - kmem_cache_destroy(extent_state_cache);
> > + kmem_cache_destroy_decoder(extent_state_cache,
> > + extent_state_leak_decoder);
> > if (extent_buffer_cache)
> > - kmem_cache_destroy(extent_buffer_cache);
> > + kmem_cache_destroy_decoder(extent_buffer_cache,
> > + extent_buffer_leak_decoder);
> > }
> >
> > void extent_io_tree_init(struct extent_io_tree *tree,
> > diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
> > index f359e4c..bccba3d 100644
> > --- a/fs/btrfs/extent_map.c
> > +++ b/fs/btrfs/extent_map.c
> > @@ -16,6 +16,16 @@ static LIST_HEAD(emaps);
> > static DEFINE_SPINLOCK(map_leak_lock);
> > #endif
> >
> > +static void extent_map_leak_decoder(void *object)
> > +{
> > + struct extent_map *em = object;
> > +
> > + printk(KERN_ERR "btrfs ext map leak: start %llu len %llu block %llu "
> > + "flags %lu refs %d in tree %d compress %d\n",
> > + em->start, em->len, em->block_start, em->flags,
> > + atomic_read(&em->refs), em->in_tree, (int)em->compress_type);
> > +}
> > +
> > int __init extent_map_init(void)
> > {
> > extent_map_cache = kmem_cache_create("btrfs_extent_map",
> > @@ -39,7 +49,8 @@ void extent_map_exit(void)
> > }
> >
> > if (extent_map_cache)
> > - kmem_cache_destroy(extent_map_cache);
> > + kmem_cache_destroy_decoder(extent_map_cache,
> > + extent_map_leak_decoder);
> > }
> >
> > /**
> > diff --git a/include/linux/slab.h b/include/linux/slab.h
> > index 5d168d7..5c6a8d8 100644
> > --- a/include/linux/slab.h
> > +++ b/include/linux/slab.h
> > @@ -114,6 +114,7 @@ struct kmem_cache {
> > const char *name; /* Slab name for sysfs */
> > int refcount; /* Use counter */
> > void (*ctor)(void *); /* Called on object slot creation */
> > + void (*decoder)(void *);/* Called on object slot leak detection */
> > struct list_head list; /* List of all slab caches on the system */
> > };
> > #endif
> > @@ -132,6 +133,7 @@ struct kmem_cache *
> > kmem_cache_create_memcg(struct mem_cgroup *, const char *, size_t, size_t,
> > unsigned long, void (*)(void *), struct kmem_cache *);
> > void kmem_cache_destroy(struct kmem_cache *);
> > +void kmem_cache_destroy_decoder(struct kmem_cache *, void (*)(void *));
> > int kmem_cache_shrink(struct kmem_cache *);
> > void kmem_cache_free(struct kmem_cache *, void *);
> >
>
> For SLUB,
> kmem_cache_destroy_decoder works when CONFIG_SLUB_DEBUG is enable.
> But, user f
Re: [PATCH V2] mm/slab: add a leak decoder callback
On Wed, Jan 16, 2013 at 03:20:57PM +, Christoph Lameter wrote:
> On Wed, 16 Jan 2013, Liu Bo wrote:
>
> > --- a/include/linux/slub_def.h
> > +++ b/include/linux/slub_def.h
> > @@ -93,6 +93,7 @@ struct kmem_cache {
> > gfp_t allocflags; /* gfp flags to use on each alloc */
> > int refcount; /* Refcount for slab cache destroy */
> > void (*ctor)(void *);
> > + void (*decoder)(void *);
>
> The field needs to be moved away from the first hot cachelines in
> kmem_cache.
>
>
> > index 3f3cd97..8c19bfd 100644
> > --- a/mm/slab_common.c
> > +++ b/mm/slab_common.c
> > @@ -193,6 +193,7 @@ kmem_cache_create_memcg(struct mem_cgroup *memcg, const
> > char *name, size_t size,
> > s->object_size = s->size = size;
> > s->align = calculate_alignment(flags, align, size);
> > s->ctor = ctor;
> > + s->decoder = NULL;
> >
> > if (memcg_register_cache(memcg, s, parent_cache)) {
> > kmem_cache_free(kmem_cache, s);
>
> Not necessary since s is filled with zeros on allocation.
>
> > @@ -248,7 +249,7 @@ kmem_cache_create(const char *name, size_t size, size_t
> > align,
> > }
> > EXPORT_SYMBOL(kmem_cache_create);
> >
> > -void kmem_cache_destroy(struct kmem_cache *s)
> > +static void __kmem_cache_destroy(struct kmem_cache *s, void
> > (*decoder)(void *))
> > {
> > /* Destroy all the children caches if we aren't a memcg cache */
> > kmem_cache_destroy_memcg_children(s);
> > @@ -259,6 +260,9 @@ void kmem_cache_destroy(struct kmem_cache *s)
> > if (!s->refcount) {
> > list_del(&s->list);
> >
> > + if (unlikely(decoder))
> > + s->decoder = decoder;
> > +
> > if (!__kmem_cache_shutdown(s)) {
> > mutex_unlock(&slab_mutex);
> > if (s->flags & SLAB_DESTROY_BY_RCU)
>
> Now that is a bit weird since __kmem_cache_destroy now sets a field in
> kmem_cache?
>
> If a kmem_cache has a decoder field set then it is no longer mergeable.
>
> It looks like the decoder field would have to be set on cache creation.
>
> If we do that then the functionality could be more generic. I always
> wanted to have a function that checks the object integrity as well.
>
> The cache validation could then go through all objects and in addition to
> checking the slab meta data integrity could also have the subsystem
> confirm the integrity of the object.
Hmm...right, seems that we have to set the decoder field on creation
part, it brings us lots of API update though.
>
> > index ba2ca53..34b3b75 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -3098,6 +3098,8 @@ static void list_slab_objects(struct kmem_cache *s,
> > struct page *page,
> > for_each_object(p, s, addr, page->objects) {
> >
> > if (!test_bit(slab_index(p, s, addr), map)) {
> > + if (unlikely(s->decoder))
> > + s->decoder(p);
> > printk(KERN_ERR "INFO: Object 0x%p @offset=%tu\n",
> > p, p - addr);
> > print_tracking(s, p);
> >
>
> Hmmm... The function is currently only used on kmem_cache_destroy but that
> may change.
Good point.
list_slab_objects(struct kmem_cache *, struct page *, const char *,
void (*)(void *))
what about this? At least we can interpret the objects as we want.
thanks,
liubo
--
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
Re: [PATCH V2] mm/slab: add a leak decoder callback
On Wed, Jan 16, 2013 at 01:34:38PM +0800, Miao Xie wrote: > On wed, 16 Jan 2013 11:03:13 +0800, Liu Bo wrote: > > This adds a leak decoder callback so that slab destruction > > can use to generate debugging output for the allocated objects. > > > > Callers like btrfs are using their own leak tracking which will > > manage allocated objects in a list(or something else), this does > > indeed the same thing as what slab does. So adding a callback > > for leak tracking can avoid this as well as runtime overhead. > > If the slab is merged with the other one, this patch can work well? Yes and no, so I'll disable merging slab in the next version :) thanks, liubo -- 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
Re: [PATCH V5] Btrfs: snapshot-aware defrag
On Thu, Jan 17, 2013 at 6:53 PM, Liu Bo wrote: > On Thu, Jan 17, 2013 at 08:42:46AM -0600, Mitch Harder wrote: >> On Wed, Jan 16, 2013 at 6:36 AM, Liu Bo wrote: >> > This comes from one of btrfs's project ideas, >> > As we defragment files, we break any sharing from other snapshots. >> > The balancing code will preserve the sharing, and defrag needs to grow this >> > as well. >> > >> > Now we're able to fill the blank with this patch, in which we make full >> > use of >> > backref walking stuff. >> > >> > Here is the basic idea, >> > o set the writeback ranges started by defragment with flag EXTENT_DEFRAG >> > o at endio, after we finish updating fs tree, we use backref walking to >> > find >> >all parents of the ranges and re-link them with the new COWed file >> > layout by >> >adding corresponding backrefs. >> > >> > Signed-off-by: Li Zefan >> > Signed-off-by: Liu Bo >> > --- >> > v4->v5: >> > - Clarify the comments for duplicated refs. >> > - Clear defrag flag after we're ready to defrag. >> > - Fix a bug on HOLE extent. >> > v3->v4: >> > - Fix duplicated refs bugs detected by mounting with autodefrag, >> > thanks >> > for the bug report from Mitch and Chris. >> > v2->v3: >> > - Rebase >> > v1->v2: >> > - Address comments from David. >> > >> >> I've been testing this patch on a 3.7.2 kernel merged with the >> for-linus branch for the 3.8_rc kernels, and I'm seeing the following >> error: > > Hi Mitch, > > Insteresting! I don't even change the snapshot code ever. Yes, this patch series has been excellent at tickling unrelated issues. > Is it reproducable stably from your side? Still with the > snapshot-test-pub scripts? I'm still using the same snapshot-test scripts, but they don't reproduce reliably. I have to run for a while after my script reaches the point where it starts deleting snapshots to make space. But, I've been able to hit this error four times with this script. I'll try to keep playing with this to make a better reproducer, and to isolate the problem with the parameter supplied to list_del. -- 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
