Suggest non-gki kernel users to backport path_umount (#1464)

Most kernel builders have to touch their kernel source code anyway, why
not also tell them to backport path_umount so even non-gki users can
benefit from this?

I know this might be a bit controversial as this will raise the barrier
of entry, but the benefits are just so high.

Idea was from OnlyTomInSecond on KernelSU group chat way back, and it
has been on the discussions for some time

references:
https://t.me/KernelSU_group/27237/176515
https://t.me/KernelSU_group/3249/184908

https://github.com/tiann/KernelSU/discussions/955#discussioncomment-7617166

03d233db8b
https://github.com/tiann/KernelSU/pull/1060 


https://elixir.bootlin.com/linux/v5.9.1/source/fs/namespace.c#L1728
https://elixir.bootlin.com/linux/v5.10.9/source/fs/namespace.c#L1730
https://elixir.bootlin.com/linux/v6.5/source/fs/namespace.c#L1887
https://github.com/tiann/KernelSU/pull/1464#issuecomment-2002492107


Kernel side change examples
5.4
961d978862
4.19
164917f56d
4.14
c07c70a0c5
4.9
195f07593a
4.4
21ea33fe41
https://github.com/tiann/KernelSU/pull/1464#issuecomment-2002424069
ofcourse having someone on 3.18 confirm this will be nice.

**PROS**: umount modules for everyone
**CONS**: barrier of entry +1

---------

Co-authored-by: Christoph Hellwig <hch@lst.de>
Co-authored-by: Fede2782 <78815152+Fede2782@users.noreply.github.com>
Co-authored-by: Tom <31297720+onlytominsecond@users.noreply.github.com>
This commit is contained in:
backslashxx
2024-03-18 10:27:31 +08:00
committed by GitHub
parent 6016937d5a
commit b4cfc2f298
3 changed files with 62 additions and 1 deletions

View File

@@ -62,6 +62,13 @@ $(info -- KernelSU Manager signature hash: $(KSU_EXPECTED_HASH))
ccflags-y += -DEXPECTED_SIZE=$(KSU_EXPECTED_SIZE) ccflags-y += -DEXPECTED_SIZE=$(KSU_EXPECTED_SIZE)
ccflags-y += -DEXPECTED_HASH=\"$(KSU_EXPECTED_HASH)\" ccflags-y += -DEXPECTED_HASH=\"$(KSU_EXPECTED_HASH)\"
ifeq ($(shell grep -q "int path_umount" $(srctree)/fs/namespace.c; echo $$?),0)
ccflags-y += -DKSU_UMOUNT
else
$(info -- Did you know you can backport path_umount to fs/namespace.c from 5.9?)
$(info -- Read: https://kernelsu.org/guide/how-to-integrate-for-non-gki.html#path_umount)
endif
ccflags-y += -Wno-implicit-function-declaration -Wno-strict-prototypes -Wno-int-conversion -Wno-gcc-compat ccflags-y += -Wno-implicit-function-declaration -Wno-strict-prototypes -Wno-int-conversion -Wno-gcc-compat
ccflags-y += -Wno-declaration-after-statement -Wno-unused-function ccflags-y += -Wno-declaration-after-statement -Wno-unused-function

View File

@@ -513,7 +513,7 @@ static bool should_umount(struct path *path)
static void ksu_umount_mnt(struct path *path, int flags) static void ksu_umount_mnt(struct path *path, int flags)
{ {
#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 9, 0) #if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 9, 0) || KSU_UMOUNT
int err = path_umount(path, flags); int err = path_umount(path, flags);
if (err) { if (err) {
pr_info("umount %s failed: %d\n", path->dentry->d_iname, err); pr_info("umount %s failed: %d\n", path->dentry->d_iname, err);

View File

@@ -40,6 +40,11 @@ But if you encounter a boot loop when integrated KernelSU, it is maybe *kprobe i
comment out `ksu_enable_sucompat()` and `ksu_enable_ksud()` in `KernelSU/kernel/ksu.c`, if the device boots normally, then kprobe may be broken. comment out `ksu_enable_sucompat()` and `ksu_enable_ksud()` in `KernelSU/kernel/ksu.c`, if the device boots normally, then kprobe may be broken.
::: :::
:::info How to get module umount feature working on pre-GKI?
If your kernel is older than 5.9, you should backport ```path_umount``` to ```fs/namespace.c```. This is required to get module umount feature working. If you don't backport ```path_umount```, module umount feature won't work. You can get more info on how to achieve this at the end of this page.
:::
## Manually modify the kernel source ## Manually modify the kernel source
If kprobe does not work in your kernel (may be an upstream or kernel bug below 4.8), then you can try this way: If kprobe does not work in your kernel (may be an upstream or kernel bug below 4.8), then you can try this way:
@@ -292,6 +297,55 @@ index 45306f9ef247..815091ebfca4 100755
add_input_randomness(type, code, value); add_input_randomness(type, code, value);
``` ```
## path_umount
You can get module umount feature working on pre-GKI kernels by manually backporting ```path_umount``` from 5.9. You can use this patch as reference:
```diff
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1739,6 +1739,39 @@ static inline bool may_mandlock(void)
}
#endif
+static int can_umount(const struct path *path, int flags)
+{
+ struct mount *mnt = real_mount(path->mnt);
+
+ if (flags & ~(MNT_FORCE | MNT_DETACH | MNT_EXPIRE | UMOUNT_NOFOLLOW))
+ return -EINVAL;
+ if (!may_mount())
+ return -EPERM;
+ if (path->dentry != path->mnt->mnt_root)
+ return -EINVAL;
+ if (!check_mnt(mnt))
+ return -EINVAL;
+ if (mnt->mnt.mnt_flags & MNT_LOCKED) /* Check optimistically */
+ return -EINVAL;
+ if (flags & MNT_FORCE && !capable(CAP_SYS_ADMIN))
+ return -EPERM;
+ return 0;
+}
+
+int path_umount(struct path *path, int flags)
+{
+ struct mount *mnt = real_mount(path->mnt);
+ int ret;
+
+ ret = can_umount(path, flags);
+ if (!ret)
+ ret = do_umount(mnt, flags);
+
+ /* we mustn't call path_put() as that would clear mnt_expiry_mark */
+ dput(path->dentry);
+ mntput_no_expire(mnt);
+ return ret;
+}
/*
* Now umount can handle mount points as well as block devices.
* This is important for filesystems which use unnamed block devices.
```
Finally, build your kernel again, KernelSU should work well. Finally, build your kernel again, KernelSU should work well.
:::info Entering safe mode accidiently? :::info Entering safe mode accidiently?