View Issue Details

IDProjectCategoryView StatusLast Update
0001294channel: elrepo/el9kmod-ecryptfspublic2022-12-06 20:45
Reporterjcpunk Assigned Totoracat  
PrioritynormalSeveritycrashReproducibilitysometimes
Status resolvedResolutionfixed 
Summary0001294: umount and remount ecryptfs causes kernel panic
DescriptionLooks like the memory folio and namespace bits changed enough that there are some panics possible with ecryptfs
Steps To Reproducemount and unmount an ecryptfs volume a bunch of times. About 1 out of every 3 causes a panic.
Additional Informationhttps://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/fs/ecryptfs?h=v5.15.80

Possible patch attached
TagsNo 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)) {
mempatch.diff (1,715 bytes)   

Activities

jcpunk

2022-12-01 11:09

reporter   ~0008796

It might be worth just rebasing off of the 5.15.80 source....

toracat

2022-12-01 12:10

administrator   ~0008798

Will try getting the source from 5.15.80.

toracat

2022-12-01 13:45

administrator   ~0008799

(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. :)

jcpunk

2022-12-01 15:10

reporter   ~0008800

https://cbs.centos.org/koji/buildinfo?buildID=42135 is working for me on CentOS Stream9

toracat

2022-12-04 15:11

administrator   ~0008816

The c9s source code does not build on el9. Backporting is not successful so far.

jcpunk

2022-12-05 12:38

reporter   ~0008818

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....

toracat

2022-12-05 13:59

administrator   ~0008819

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 (???).

toracat

2022-12-05 14:26

administrator   ~0008820

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

jcpunk

2022-12-05 14:31

reporter   ~0008821

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

jcpunk

2022-12-05 14:49

reporter   ~0008822

That package installs and doesn't panic my boxes on a bunch of mount/umounts, so I'd say this seems to be working.

toracat

2022-12-05 19:55

administrator   ~0008823

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

jcpunk

2022-12-05 21:11

reporter   ~0008825

Interesting, I didn't intend to.....

toracat

2022-12-06 20:45

administrator   ~0008826

Thanks for the fix and the testing. Now closing as ;resolved'.

Issue History

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