Bug 972564 - Fedora19:Beta: Unable to modprobe btrfs module after a previous 'rmmod btrfs' operation.
Fedora19:Beta: Unable to modprobe btrfs module after a previous 'rmmod btrfs'...
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
ppc64 All
unspecified Severity medium
: ---
: ---
Assigned To: fedora-kernel-btrfs
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-10 01:20 EDT by IBM Bug Proxy
Modified: 2013-10-11 03:03 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-23 16:14:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg.txt (133.71 KB, text/plain)
2013-06-10 01:21 EDT, IBM Bug Proxy
no flags Details
var-log-messages.txt (287.69 KB, text/plain)
2013-06-10 01:21 EDT, IBM Bug Proxy
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 94324 None None None Never

  None (edit)
Description IBM Bug Proxy 2013-06-10 01:20:56 EDT
When Btrfs module is unloaded, the "btrfs_delayed_ref_head" kmem cache is left over as shown from the output of /proc/slabinfo:
slabinfo - version: 2.1
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
nf_conntrack_c000000001226080   1890   1890    312  210    1 : tunables    0    0    0 : slabdata      9      9      0
btrfs_delayed_ref_head    512    512    128  512    1 : tunables    0    0    0 : slabdata      1      1      0
scsi_tgt_cmd           0      0     80  819    1 : tunables    0    0    0 : slabdata      0      0      0
UDPLITEv6              0      0   1152   56    1 : tunables    0    0    0 : slabdata      0      0      0
UDPv6                280    280   1152   56    1 : tunables    0    0    0 : slabdata      5      5      0

Hence when Btrfs module is reloaded again, btrfs_delayed_ref_init() fails to create the same cache.

By the way, 'rmmod btrfs' and 'modprobe btrfs' works fine on mainline linux-3.9.4.
Comment 1 IBM Bug Proxy 2013-06-10 01:21:12 EDT
Created attachment 759033 [details]
dmesg.txt
Comment 2 IBM Bug Proxy 2013-06-10 01:21:27 EDT
Created attachment 759034 [details]
var-log-messages.txt
Comment 3 Dave Jones 2013-06-11 15:44:01 EDT
that doesn't make a lot of sense, as the btrfs code in 3.9.4 is 1:1 identical with what we're carrying in the Fedora 3.9.4 kernel.

Is this reproducible at will ? Do you have a test-case ?
Comment 4 IBM Bug Proxy 2013-06-13 10:20:47 EDT
------- Comment From chrajend@in.ibm.com 2013-06-13 14:14 EDT-------
> Is this reproducible at will ? Do you have a test-case ?

Yes, this is reproducible. We have a machine with a btrfs partition (although it is not listed in /etc/fstab and hence not mounted during bootup). Execute "rmmod btrfs" to unload the btrfs module. The very next "modprobe btrfs" command fails as shown below:

# modprobe btrfs
[  156.876142] kmem_cache_sanity_check (btrfs_delayed_ref_head): Cache name already exists.
[  156.876152] Call Trace:
[  156.876158] [c00000006868f7e0] [c000000000015b70] .show_stack+0x130/0x200 (unreliable)
[  156.876165] [c00000006868f8b0] [c0000000001dc7bc] .kmem_cache_create_memcg+0x1ac/0x470
[  156.876188] [c00000006868f9c0] [d000000001ce2db4] .btrfs_delayed_ref_init+0x34/0x100 [btrfs]
[  156.876210] [c00000006868fa40] [d000000001d0fb20] .init_btrfs_fs+0x8c/0x150 [btrfs]
[  156.876215] [c00000006868fac0] [c00000000000b4d4] .do_one_initcall+0x174/0x1f0
[  156.876220] [c00000006868fb70] [c0000000001190bc] .load_module+0x1afc/0x26e0
[  156.876225] [c00000006868fd40] [c000000000119eb0] .SyS_finit_module+0xc0/0x110
[  156.876230] [c00000006868fe30] [c000000000009e54] syscall_exit+0x0/0x98
modprobe: ERROR: could not insert 'btrfs': Cannot allocate memory

This behaviour is not observed on x86_64 architecture.
Comment 5 Josh Boyer 2013-09-18 16:36:49 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 6 Josef Bacik 2013-09-23 16:14:57 EDT
Closing this as it is fixed upstream.  If you are still experiencing this issue please file a bug at bugzilla.kernel.org and set the component to Btrfs.
Comment 7 IBM Bug Proxy 2013-10-11 03:03:52 EDT
------- Comment From iranna.ankad@in.ibm.com 2013-10-11 06:53 EDT-------
Verified this bug in Fedora20 Alpha & confirmed this is fixed. We can close this bug from IBM side. Thanks!

FYI

[root@jupiterioc-lp3 btrfs]# lsmod | grep -i btrfs
btrfs                1135252  0
raid6_pq              153318  1 btrfs
xor                    12405  1 btrfs
libcrc32c               1922  2 xfs,btrfs
[root@jupiterioc-lp3 btrfs]# dmesg -c
[root@jupiterioc-lp3 btrfs]# rmmod btrfs
[root@jupiterioc-lp3 btrfs]# modprobe btrfs
[root@jupiterioc-lp3 btrfs]# dmesg
[63295.259469] SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts
[63324.539287] Btrfs loaded
[63424.659585] Btrfs loaded
[root@jupiterioc-lp3 btrfs]#

[root@jupiterioc-lp3 btrfs]# uname -a
Linux jupiterioc-lp3.austin.ibm.com 3.11.0-300.fc20.ppc64p7 #1 SMP Thu Sep 5 16:13:50 MST 2013 ppc64 ppc64 ppc64 GNU/Linux

Note: I also ran the script mentioned in "steps to reproduce", it works fine too.

Note You need to log in before you can comment on or make changes to this bug.