Suggest non-gki kernel users to backport path_umount

[backslashxx]

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 https://github.com/OnlyTomInSecond/android_kernel_xiaomi_sdm845/commit/03d233db8bbe9fe101509430bfa09d1899168aa7 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.8.1/source/fs/namespace.c#L1889 https://github.com/tiann/KernelSU/pull/1464#issuecomment-2002492107

Kernel side change examples 5.4 https://github.com/natsumerinchan/kernel_oneplus_sm8350/commit/961d9788624e88c3c58918b3781b9fbdd19ecbeb 4.19 https://github.com/backslashxx/android_karnol_ximi_fog/commit/164917f56d0e75ab51bb9f1bdf489acac7a6d3db 4.14 https://github.com/backslashxx/mojito_krenol/commit/686e90b6a63ad0851e964bddab7add54ec52b973 4.9 https://github.com/backslashxx/msm8953-los21/commit/195f07593ae9769a992f3945bcdc43ff7fc99827 4.4 https://github.com/riarumoda/android_kernel_samsung_a9y18qlte/commit/21ea33fe41ce079ec1d663c0bd2201bc00a8084a 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

[Asyanx]

+1 work

[xennin]

pro

[Fede2782]

+1. It could really uniform things up. I can confirm works on my 4.9 and 4.14. Maybe could be implemented directly in KernelSU source, without requiring to manually add to source

[alternoegraha]

+1

[losshye]

+1 work on my kramel 😋

[privacyguy123]

+1

[Fede2782]

@backslashxx I don't know if there is a way to do this but the best way would be to dynamically enable/disable modules umount feature if there is the path_umount code in fs/namespace.c, because very likely @tiann will close this issue as he did with the other one

[backslashxx]

@backslashxx I don't know if there is a way to do this but the best way would be to dynamically enable/disable modules umount feature if there is the path_umount code in fs/namespace.c, because very likely @tiann will close this issue as he did with the other one

is there a way to test a function if it exists before linking? if so then thats a plausible way to do it.

[FerryAr]

+1, it was already tested, and it works! So, why not?

[riarumoda]

Hi, 4.4 kernel user in here, i used the 4.9 patch and it works. my messy commit is in here: https://github.com/riarumoda/android_kernel_samsung_a9y18qlte/commit/046ec1c9482a4b6828e112dcfd2966d1cd765129 https://github.com/riarumoda/android_kernel_samsung_a9y18qlte/commit/d370283ea8744cdb989d786404cd3acc6237bb44 https://github.com/riarumoda/android_kernel_samsung_a9y18qlte/commit/21ea33fe41ce079ec1d663c0bd2201bc00a8084a

[Fede2782]

@backslashxx I don't know if there is a way to do this but the best way would be to dynamically enable/disable modules umount feature if there is the path_umount code in fs/namespace.c, because very likely @tiann will close this issue as he did with the other one

is there a way to test a function if it exists before linking? if so then thats a plausible way to do it.

I would say to make that little part of code separated and it could be built or not by a Makefile statement if it locates the code in fs/namespace.c. I will try to implement this if i have time in these days if it is possible

[backslashxx]

I would say to make that little part of code separated and it could be built or not by a Makefile statement if it locates the code in fs/namespace.c. I will try to implement this if i have time in these days if it is possible

Good idea. check latest change I continue with #error warning and still forcing builder to do it, or of course, do nothing?? b-b-b-but I want everyone to do it bruv

testing with gcc

[backslashxx]

Yes i think it could work, good job. I'll try to build later and see if works. In any case you should not force this change i think. Let the devs choose

so something like this? #warning instead of #error

and ofcourse, I have to edit PR topic/title if that's what they want

[backslashxx]

I'm still all for forcing it to atleast have feature parity across GKI and non-GKI. but yeah, It'll depend on them at this point I guess.

[backslashxx]

ready to squash I guess. I'll squash after another approving review

Not so attention grabbing

gcc-14 clang-19-git

[tiann]

ready to squash I guess. I'll squash after another approving review

You don't need to squash, i will make a squash merge.

[backslashxx]

Heres how it looks if a builder doesnt backport path_umount. might want to make it noticeable or something

[ghost]

+1 but why don't use latest code ?

https://elixir.bootlin.com/linux/latest/A/ident/path_umount

/**
 * path_mounted - check whether path is mounted
 * @path: path to check
 *
 * Determine whether @path refers to the root of a mount.
 *
 * Return: true if @path is the root of a mount, false if not.
 */
static inline bool path_mounted(const struct path *path)
{
	return path->mnt->mnt_root == path->dentry;
}

static int can_umount(const struct path *path, int flags)
{
	struct mount *mnt = real_mount(path->mnt);

	if (!may_mount())
		return -EPERM;
	if (!path_mounted(path))
		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;
}

// caller is responsible for flags being sane
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;
}

[backslashxx]

+1 but why don't use latest code ?

the backport becomes bloody as path_mounted also is needed the easiest backports are on either 5.9 or 5.10.9 but yeah let's see tiann's opinion can be added though :+1: as having that inline might be beneficial if that is being called a lot

[Fede2782]

Is this attention grabbing enough?

The thing is, the normal output is not even noticeable.

I would not waste time on this. Just write clearly in release notes and in the documentation (must be written clearly in both sections: krpobes and manual) and developers will notice. If some dev doesn't read, the users will very likely complain to him and will implementation asap. I'll write the docs page to better explain why and when is required to backport

[Fede2782]

For the docs i think is more coherent this https://github.com/Fede2782/KernelSU/blob/main/website/docs/guide/how-to-integrate-for-non-gki.md

[ExtremeXT]

+1

[Zerototheleft122105]

Todo lo que proponéis me resulta complicado Pero llegará el momento de que lo domine. Un gran +1

[Fede2782]

Lol, it seems that non-gki support will be completely removed, I hope won't be applied https://github.com/tiann/KernelSU/tree/drop_nongki

[backslashxx]

Lol, it seems that non-gki support will be completely removed, I hope won't be applied https://github.com/tiann/KernelSU/tree/drop_nongki

lmao, time to start backporting fsopen