Bug 600152 - nfsd -- IMA: unmeasured files on fsmagic: EF53 followed by kernel stacktrace
Summary: nfsd -- IMA: unmeasured files on fsmagic: EF53 followed by kernel stacktrace
Keywords:
Status: CLOSED DUPLICATE of bug 633540
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-04 03:11 UTC by Julian C. Dunn
Modified: 2010-10-12 19:29 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-10-12 19:29:20 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Julian C. Dunn 2010-06-04 03:11:21 UTC
Description of problem:

Kernel stack trace mounting an NFSv4 filesystem exported from a F13 box, to an F13 client.

Version-Release number of selected component (if applicable):

nfs-utils-1.2.2-2.fc13.x86_64
kernel-2.6.33.5-112.fc13.x86_64


How reproducible:

Always


Steps to Reproduce:
1. Bring server up, /home is exported
2. Bring client up, which mounts /home
3. After a few minutes the stacktrace appears.
  
Actual results:

Jun  3 22:55:47 demeter kernel: IMA: unmeasured files on fsmagic: EF53
Jun  3 22:55:47 demeter kernel: ima_dec_counts: open/free imbalance (r:1 w:-1 o:0)
Jun  3 22:55:47 demeter kernel: Pid: 1292, comm: nfsd Not tainted 2.6.33.5-112.fc13.x86_64 #1
Jun  3 22:55:47 demeter kernel: Call Trace:
Jun  3 22:55:47 demeter kernel: [<ffffffff811d8dc8>] ima_file_free+0x1e2/0x1f6
Jun  3 22:55:47 demeter kernel: [<ffffffff8110295f>] __fput+0x135/0x1d7
Jun  3 22:55:47 demeter kernel: [<ffffffff81102a16>] fput+0x15/0x17
Jun  3 22:55:47 demeter kernel: [<ffffffffa035cb7a>] nfsd_close+0x9/0xb [nfsd]
Jun  3 22:55:47 demeter kernel: [<ffffffffa036e9aa>] release_open_stateid+0x3a/0x47 [nfsd]
Jun  3 22:55:47 demeter kernel: [<ffffffffa03718b9>] nfsd4_close+0x8c/0x112 [nfsd]
Jun  3 22:55:47 demeter kernel: [<ffffffffa0366a84>] nfsd4_proc_compound+0x211/0x3d2 [nfsd]
Jun  3 22:55:47 demeter kernel: [<ffffffffa0358365>] nfsd_dispatch+0xec/0x1c7 [nfsd]
Jun  3 22:55:47 demeter kernel: [<ffffffffa02e9a94>] svc_process_common+0x2b9/0x4b4 [sunrpc]
Jun  3 22:55:47 demeter kernel: [<ffffffffa02e9eae>] svc_process+0x121/0x135 [sunrpc]
Jun  3 22:55:47 demeter kernel: [<ffffffffa03588a1>] nfsd+0xf1/0x13a [nfsd]
Jun  3 22:55:47 demeter kernel: [<ffffffffa03587b0>] ? nfsd+0x0/0x13a [nfsd]
Jun  3 22:55:47 demeter kernel: [<ffffffff810643bb>] kthread+0x7a/0x82
Jun  3 22:55:47 demeter kernel: [<ffffffff8100a924>] kernel_thread_helper+0x4/0x10
Jun  3 22:55:47 demeter kernel: [<ffffffff81064341>] ? kthread+0x0/0x82
Jun  3 22:55:47 demeter kernel: [<ffffffff8100a920>] ? kernel_thread_helper+0x0/0x10
Jun  3 22:55:47 demeter kernel: iint_free: readcount: 1
Jun  3 22:55:47 demeter kernel: iint_free: writecount: -1


Also, sometimes the filesystem metadata appears corrupted on the client. E.g. UID will be set to "nobody" as though the filesystem is being root_squashed (even though all files are owned by me)


Expected results:

Filesystem mounts properly without errors.


Additional info:

Yes, I did fsck the filesystem in question and it's clean.

Comment 1 Julian C. Dunn 2010-08-07 01:30:53 UTC
Seems to be a bug in NFSv4. If I remount the filesystem NFSv3 from the client, everything's fine.

The server is now running:

Linux ----------- 2.6.33.6-147.2.4.fc13.x86_64 #1 SMP Fri Jul 23 17:14:44 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

and dmesg shows:

Pid: 1299, comm: nfsd Not tainted 2.6.33.6-147.2.4.fc13.x86_64 #1
Call Trace:
 [<ffffffff811d87d4>] ima_file_free+0x1e2/0x1f6
 [<ffffffff811023eb>] __fput+0x135/0x1d7
 [<ffffffff811024a2>] fput+0x15/0x17
 [<ffffffffa035cb76>] nfsd_close+0x9/0xb [nfsd]
 [<ffffffffa036e9a6>] release_open_stateid+0x3a/0x47 [nfsd]
 [<ffffffffa03718b5>] nfsd4_close+0x8c/0x112 [nfsd]
 [<ffffffffa0366a80>] nfsd4_proc_compound+0x211/0x3d2 [nfsd]
 [<ffffffffa0358362>] nfsd_dispatch+0xec/0x1c7 [nfsd]
 [<ffffffffa02e9a94>] svc_process_common+0x2b9/0x4b4 [sunrpc]
 [<ffffffffa02e9eae>] svc_process+0x121/0x135 [sunrpc]
 [<ffffffffa035889e>] nfsd+0xf1/0x13a [nfsd]
 [<ffffffffa03587ad>] ? nfsd+0x0/0x13a [nfsd]
 [<ffffffff81063d6f>] kthread+0x7a/0x82
 [<ffffffff8100a924>] kernel_thread_helper+0x4/0x10
 [<ffffffff81063cf5>] ? kthread+0x0/0x82
 [<ffffffff8100a920>] ? kernel_thread_helper+0x0/0x10

the first time the client tries to mount the offending filesystem.

Comment 2 Jonathan Dieter 2010-08-20 11:05:16 UTC
One additional problem is that if you try to restart nfs after the above happens, it hangs on the start.

The above bug still exists with kernel-2.6.34.4-41.fc13.x86_64.

Comment 3 JM 2010-09-12 17:44:15 UTC
And the bug still exists with kernel 2.6.34.6-54.fc13.x86_64:

IMA: unmeasured files on fsmagic: EF53
ima_dec_counts: open/free imbalance (r:1 w:-1 o:0)
Pid: 1639, comm: nfsd Not tainted 2.6.34.6-54.fc13.x86_64 #1
Call Trace:
 [<ffffffff811e9ac7>] ima_file_free+0x1e7/0x1f8
 [<ffffffff8110efa3>] __fput+0x13a/0x1dc
 [<ffffffff8110f05f>] fput+0x1a/0x1c
 [<ffffffffa0248cb0>] nfsd_close+0xe/0x10 [nfsd]
 [<ffffffffa025b1ad>] release_open_stateid+0x3f/0x4c [nfsd]
 [<ffffffffa025e19d>] nfsd4_close+0x91/0x117 [nfsd]
 [<ffffffffa025303d>] nfsd4_proc_compound+0x216/0x3d7 [nfsd]
 [<ffffffffa024438f>] nfsd_dispatch+0xf1/0x1cc [nfsd]
 [<ffffffffa01bbec1>] svc_process_common+0x2be/0x4b9 [sunrpc]
 [<ffffffffa01bc2e5>] svc_process+0x126/0x13a [sunrpc]
 [<ffffffffa02448df>] nfsd+0xf6/0x13f [nfsd]
 [<ffffffffa02447e9>] ? nfsd+0x0/0x13f [nfsd]
 [<ffffffff81065cb9>] kthread+0x7f/0x87
 [<ffffffff8100aa64>] kernel_thread_helper+0x4/0x10
 [<ffffffff81065c3a>] ? kthread+0x0/0x87
 [<ffffffff8100aa60>] ? kernel_thread_helper+0x0/0x10

Comment 4 JM 2010-09-13 12:21:37 UTC
Actually this bug breaks NFSv4 in Fedora 13 completely, I can't use it at all and I thought NFSv4 is now the default in Fedora 13 (http://fedoraproject.org/wiki/Features/NFSv4Default). In Fedora 12 NFSv4 works without any problems...

Comment 5 J. Bruce Fields 2010-10-12 19:29:20 UTC
It would be interesting to confirm whether the patch attached to #633540 fixes this.

*** This bug has been marked as a duplicate of bug 633540 ***


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