Created attachment 133551 [details] kernel BUG report This bug is JFS and NFS related. If a jfs filesystem is exported by the kernel 3.14 nfsd, mounting the filesystem on a different computer yields to a kernel bug crashing the nfsd. The nfsd totally hangs afterwards and prevents a clean unmount. Either of the former yields to corrupted files on the jfs. It seems to me that all files written after the crash are corrupted but I'm not sure about that. In my case, .viminfo and the saved gnome-session got mostly corrupted. Maybe more - don't know yet. The Bug is always reproducible under 3.14 and 3.14.1.
Created attachment 133731 [details] tmpfs: Fix simple_set_acl()
Any file system that uses simple_set_acl() is likely to suffer from this issue.
I can confirm that the proposed patch fixes the problem for me.
I have to revert my previous comment. Bug is still there, behavior is unchanged. See attached kernel BUG report with the above mentioned patch applied.
Created attachment 134041 [details] kernel NULL pointer dereference with patch applied kernel still reports a NULL pointer dereference when accessing jfs over nfs3.
__jfs_set_acl() has the same bug as simple_set_acl(), possibly introduced by commit 2cc6a5a0.
Created attachment 134051 [details] Possible patch for bug I'm not very familiar with linux kernel fs. If acl is NULL, is it still necessary to set the inode->i_ctime, flag the inode dirty and write the xattrs like in the attached patch or should I simply return from the function immediately?
(In reply to Marco Munderloh from comment #7) > If acl is NULL, is it still necessary to set the inode->i_ctime, flag the > inode dirty and write the xattrs like in the attached patch or should I > simply return from the function immediately? You can look at other .set_acl functions under fs/ , and post your patch to linux-fsdevel@vger.kernel.org for review.
I think this issue was fixed in the kernel sources at some point as I don't see any problems with later kernels anymore.