View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001294 | channel: elrepo/el9 | kmod-ecryptfs | public | 2022-12-01 11:08 | 2022-12-06 20:45 |
Reporter | jcpunk | Assigned To | toracat | ||
Priority | normal | Severity | crash | Reproducibility | sometimes |
Status | resolved | Resolution | fixed | ||
Summary | 0001294: umount and remount ecryptfs causes kernel panic | ||||
Description | Looks like the memory folio and namespace bits changed enough that there are some panics possible with ecryptfs | ||||
Steps To Reproduce | mount and unmount an ecryptfs volume a bunch of times. About 1 out of every 3 causes a panic. | ||||
Additional Information | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/fs/ecryptfs?h=v5.15.80 Possible patch attached | ||||
Tags | No tags attached. | ||||
Attached Files | mempatch.diff (1,715 bytes)
diff --git a/main.c b/main.c index d66bbd2..2dd23a8 100644 --- a/main.c +++ b/main.c @@ -537,7 +537,7 @@ static struct dentry *ecryptfs_mount(struct file_system_type *fs_type, int flags goto out_free; } - if (mnt_user_ns(path.mnt) != &init_user_ns) { + if (is_idmapped_mnt(path.mnt)) { rc = -EINVAL; printk(KERN_ERR "Mounting on idmapped mounts currently disallowed\n"); goto out_free; diff --git a/mmap.c b/mmap.c index 7d85e64..9ad61b5 100644 --- a/mmap.c +++ b/mmap.c @@ -540,12 +540,13 @@ const struct address_space_operations ecryptfs_aops = { * XXX: This is pretty broken for multiple reasons: ecryptfs does not * actually use buffer_heads, and ecryptfs will crash without * CONFIG_BLOCK. But it matches the behavior before the default for - * address_space_operations without the ->set_page_dirty method was + * address_space_operations without the ->dirty_folio method was * cleaned up, so this is the best we can do without maintainer * feedback. */ #ifdef CONFIG_BLOCK - .set_page_dirty = __set_page_dirty_buffers, + .dirty_folio = block_dirty_folio, + .invalidate_folio = block_invalidate_folio, #endif .writepage = ecryptfs_writepage, .readpage = ecryptfs_readpage, diff --git a/super.c b/super.c index 39116af..0b1c878 100644 --- a/super.c +++ b/super.c @@ -38,7 +38,7 @@ static struct inode *ecryptfs_alloc_inode(struct super_block *sb) struct ecryptfs_inode_info *inode_info; struct inode *inode = NULL; - inode_info = kmem_cache_alloc(ecryptfs_inode_info_cache, GFP_KERNEL); + inode_info = alloc_inode_sb(sb, ecryptfs_inode_info_cache, GFP_KERNEL); if (unlikely(!inode_info)) goto out; if (ecryptfs_init_crypt_stat(&inode_info->crypt_stat)) { | ||||
|
It might be worth just rebasing off of the 5.15.80 source.... |
|
Will try getting the source from 5.15.80. |
|
(1) Tried the source from 5.15.80. or (2) Tried the patch submitted. Both cases resulted in build errors. Will investigate later. In the meantime, if you have a working srpm, feel free to submit it. :) |
|
https://cbs.centos.org/koji/buildinfo?buildID=42135 is working for me on CentOS Stream9 |
|
The c9s source code does not build on el9. Backporting is not successful so far. |
|
This srpm seems to build, but when I try to install it I'm getting loads of symbol mismatches? did I do something weird? On the plus side, it seems we've proven ecryptfs will probably need another rebase for the RHEL 9.2 kernel.... |
|
I built from your srpm. The built kmod installed with no issue and modprobe worked fine. Note that the kmod was built against the el9.1 kernel and it is not backward compatible (no weak-link to the 9.0 kernel). I also noticed that hank #2 of your original patch (mmap.c) was not applied and that your source was taken from kernel-v6.1-rcX (???). |
|
I've just released the following packages to the elrepo-testing repo: src: kmod-ecryptfs-0.1-1.el9_1.elrepo.src.rpm x86_64: kmod-ecryptfs-0.1-1.el9_1.elrepo.x86_64.rpm |
|
I tried to take https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/fs/ecryptfs?h=v5.15.81 and revert patches that prevented the build |
|
That package installs and doesn't panic my boxes on a bunch of mount/umounts, so I'd say this seems to be working. |
|
Thank you for testing the package. I promoted it to the main repository. If I'm not mistaken, you seem to have applied one patch from kernel v6.0-rc1: commit 88569546e8a13a0c1ccf119dac72376784b0ea42 ecryptfs: constify path https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ecryptfs?h=v6.1-rc1&id=88569546e8a13a0c1ccf119dac72376784b0ea42 |
|
Interesting, I didn't intend to..... |
|
Thanks for the fix and the testing. Now closing as ;resolved'. |
Date Modified | Username | Field | Change |
---|---|---|---|
2022-12-01 11:08 | jcpunk | New Issue | |
2022-12-01 11:08 | jcpunk | Status | new => assigned |
2022-12-01 11:08 | jcpunk | Assigned To | => toracat |
2022-12-01 11:08 | jcpunk | File Added: mempatch.diff | |
2022-12-01 11:09 | jcpunk | Note Added: 0008796 | |
2022-12-01 12:10 | toracat | Note Added: 0008798 | |
2022-12-01 13:45 | toracat | Note Added: 0008799 | |
2022-12-01 15:10 | jcpunk | Note Added: 0008800 | |
2022-12-04 15:11 | toracat | Note Added: 0008816 | |
2022-12-05 12:38 | jcpunk | Note Added: 0008818 | |
2022-12-05 12:38 | jcpunk | File Added: kmod-ecryptfs-0.1-1.el9_1.src.rpm | |
2022-12-05 13:59 | toracat | Note Added: 0008819 | |
2022-12-05 14:26 | toracat | Note Added: 0008820 | |
2022-12-05 14:31 | jcpunk | Note Added: 0008821 | |
2022-12-05 14:49 | jcpunk | Note Added: 0008822 | |
2022-12-05 19:55 | toracat | Note Added: 0008823 | |
2022-12-05 21:11 | jcpunk | Note Added: 0008825 | |
2022-12-06 20:45 | toracat | Status | assigned => resolved |
2022-12-06 20:45 | toracat | Resolution | open => fixed |
2022-12-06 20:45 | toracat | Note Added: 0008826 |