Suggest non-gki kernel users to backport path_umount #1464

backslashxx · 2024-03-17T09:13:16Z

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
#955 (comment)
OnlyTomInSecond/android_kernel_xiaomi_sdm845@03d233d
#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 #1464 (comment)

Kernel side change examples
5.4 natsumerinchan/kernel_oneplus_sm8350@961d978
4.19 https://github.com/backslashxx/android_karnol_ximi_fog/commit/164917f56d0e75ab51bb9f1bdf489acac7a6d3db
4.14 crdroidandroid/android_kernel_xiaomi_sm6150@c07c70a
4.9 backslashxx/msm8953-kernel@195f075
4.4 https://github.com/riarumoda/android_kernel_samsung_a9y18qlte/commit/21ea33fe41ce079ec1d663c0bd2201bc00a8084a #1464 (comment)
ofcourse having someone on 3.18 confirm this will be nice.

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

Asyanx · 2024-03-17T10:07:36Z

+1 work

xennin · 2024-03-17T10:08:49Z

pro

Fede2782 · 2024-03-17T10:12:41Z

+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 · 2024-03-17T10:13:05Z

+1

losshye · 2024-03-17T10:21:36Z

+1 work on my kramel 😋

privacyguy123 · 2024-03-17T10:32:55Z

+1

Fede2782 · 2024-03-17T10:40:52Z

@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 · 2024-03-17T10:45:02Z

@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 · 2024-03-17T11:28:49Z

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

riarumoda · 2024-03-17T11:42:35Z

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 · 2024-03-17T11:51:08Z

@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 · 2024-03-17T12:06:42Z

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 · 2024-03-17T12:30:49Z

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 · 2024-03-17T13:01:16Z

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.

Fede2782

Really good idea

website/docs/guide/how-to-integrate-for-non-gki.md

kernel/core_hook.c

website/docs/guide/how-to-integrate-for-non-gki.md

kernel/core_hook.c

backslashxx · 2024-03-17T13:27:09Z

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

Not so attention grabbing

gcc-14

clang-19-git

Legacy kernel builders have to touch their kernel source code anyway so we might as well tell them to backport things to achieve some sort of feature parity. As for others, it is a common thing on the scene to backport things, so this breaks kernel versioning assumptions. As for those, we scan and check kernel source. Required: - get_cred_rcu: context: tiann/KernelSU#2320 (comment) apply: torvalds/linux@97d0fb2 if above conflicts, try: xiaomi-sdm678/android_kernel_xiaomi_mojito@3fbad8b Optional: - path_umount: context: tiann/KernelSU#1464 (comment) apply: xiaomi-sdm678/android_kernel_xiaomi_mojito@2d51422 - strncpy_from_user_nofault for 5.4, apply: torvalds/linux@bd88bb5 for 4.x, apply: xiaomi-sdm678/android_kernel_xiaomi_mojito@424e21f for any failures, check dependency chain of gregkh/linux@f43434e - kernel_read / kernel_write < 4.14, backport chain, tested on 4.9 torvalds/linux@e13ec93 torvalds/linux@bdd1d2d torvalds/linux@c41fbad torvalds/linux@ac452ac - hint, `curl $url.patch | git am` Signed-off-by: backslashxx <[email protected]>

Legacy kernel builders have to touch their kernel source code anyway so we might as well tell them to backport things to achieve some sort of feature parity. As for others, it is a common thing on the scene to backport things, so this breaks kernel versioning assumptions. As for those, we scan and check kernel source. Required: - get_cred_rcu: context: tiann#2320 (comment) apply: torvalds/linux@97d0fb2 if above conflicts, try: xiaomi-sdm678/android_kernel_xiaomi_mojito@3fbad8b Optional: - path_umount: context: tiann#1464 (comment) apply: xiaomi-sdm678/android_kernel_xiaomi_mojito@2d51422 - strncpy_from_user_nofault for 5.4, apply: torvalds/linux@bd88bb5 for 4.x, apply: xiaomi-sdm678/android_kernel_xiaomi_mojito@424e21f for any failures, check dependency chain of gregkh/linux@f43434e - kernel_read / kernel_write < 4.14, backport chain, tested on 4.9 torvalds/linux@e13ec93 torvalds/linux@bdd1d2d torvalds/linux@c41fbad torvalds/linux@ac452ac - hint, `curl $url.patch | git am` Signed-off-by: backslashxx <[email protected]>

It is a common thing on the scene to backport things, so this breaks kernel versioning assumptions. As for those, we scan and check kernel source. The following are backportable: - get_cred_rcu: context: tiann#2320 (comment) apply: torvalds/linux@97d0fb2 if above conflicts, try: xiaomi-sdm678/android_kernel_xiaomi_mojito@3fbad8b - path_umount: context: tiann#1464 (comment) apply: xiaomi-sdm678/android_kernel_xiaomi_mojito@2d51422 - strncpy_from_user_nofault for 5.4, apply: torvalds/linux@bd88bb5 for 4.x, apply: xiaomi-sdm678/android_kernel_xiaomi_mojito@424e21f for any failures, check dependency chain of gregkh/linux@f43434e - kernel_read / kernel_write < 4.14, backport chain, tested on 4.9 torvalds/linux@e13ec93 torvalds/linux@bdd1d2d torvalds/linux@c41fbad torvalds/linux@ac452ac - hint, `curl $url.patch | git am` Signed-off-by: backslashxx <[email protected]>

It is a common thing on the scene to backport things, so this breaks kernel versioning assumptions. As for those, we scan and check kernel source. The following are backportable: - path_umount: context: tiann#1464 (comment) apply: xiaomi-sdm678/android_kernel_xiaomi_mojito@2d51422 - strncpy_from_user_nofault for 5.4, apply: torvalds/linux@bd88bb5 for 4.x, apply: xiaomi-sdm678/android_kernel_xiaomi_mojito@424e21f for any failures, check dependency chain of gregkh/linux@f43434e - kernel_read / kernel_write < 4.14, backport chain, tested on 4.9 torvalds/linux@e13ec93 torvalds/linux@bdd1d2d torvalds/linux@c41fbad torvalds/linux@ac452ac - hint, `curl $url.patch | git am` Signed-off-by: backslashxx <[email protected]>

Legacy kernel builders have to touch their kernel source code anyway so we might as well tell them to backport things to achieve some sort of feature parity. As for others, it is a common thing on the scene to backport things, so this breaks kernel versioning assumptions. As for those, we scan and check kernel source. Required: - get_cred_rcu: context: tiann/KernelSU#2320 (comment) apply: torvalds/linux@97d0fb2 if above conflicts, try: xiaomi-sdm678/android_kernel_xiaomi_mojito@3fbad8b Optional: - path_umount: context: tiann/KernelSU#1464 (comment) apply: xiaomi-sdm678/android_kernel_xiaomi_mojito@2d51422 - strncpy_from_user_nofault for 5.4, apply: torvalds/linux@bd88bb5 for 4.x, apply: xiaomi-sdm678/android_kernel_xiaomi_mojito@424e21f for any failures, check dependency chain of gregkh/linux@f43434e - kernel_read / kernel_write < 4.14, backport chain, tested on 4.9 torvalds/linux@e13ec93 torvalds/linux@bdd1d2d torvalds/linux@c41fbad torvalds/linux@ac452ac - hint, `curl $url.patch | git am` Signed-off-by: backslashxx <[email protected]>

It is a common thing on the scene to backport things, so this breaks kernel versioning assumptions. As for those, we scan and check kernel source. The following are backportable: - path_umount: context: tiann#1464 (comment) apply: xiaomi-sdm678/android_kernel_xiaomi_mojito@2d51422 - strncpy_from_user_nofault for 5.4, apply: torvalds/linux@bd88bb5 for 4.x, apply: xiaomi-sdm678/android_kernel_xiaomi_mojito@424e21f for any failures, check dependency chain of gregkh/linux@f43434e - kernel_read / kernel_write < 4.14, backport chain, tested on 4.9 torvalds/linux@e13ec93 torvalds/linux@bdd1d2d torvalds/linux@c41fbad torvalds/linux@ac452ac - hint, `curl $url.patch | git am` Signed-off-by: backslashxx <[email protected]>

Legacy kernel builders have to touch their kernel source code anyway so we might as well tell them to backport things to achieve some sort of feature parity. As for others, it is a common thing on the scene to backport things, so this breaks kernel versioning assumptions. As for those, we scan and check kernel source. Required: - get_cred_rcu: context: tiann/KernelSU#2320 (comment) apply: torvalds/linux@97d0fb2 if above conflicts, try: xiaomi-sdm678/android_kernel_xiaomi_mojito@3fbad8b Optional: - path_umount: context: tiann/KernelSU#1464 (comment) apply: xiaomi-sdm678/android_kernel_xiaomi_mojito@2d51422 - strncpy_from_user_nofault for 5.4, apply: torvalds/linux@bd88bb5 for 4.x, apply: xiaomi-sdm678/android_kernel_xiaomi_mojito@424e21f for any failures, check dependency chain of gregkh/linux@f43434e - kernel_read / kernel_write < 4.14, backport chain, tested on 4.9 torvalds/linux@e13ec93 torvalds/linux@bdd1d2d torvalds/linux@c41fbad torvalds/linux@ac452ac - hint, `curl $url.patch | git am` Signed-off-by: backslashxx <[email protected]>

It is a common thing on the scene to backport things, so this breaks kernel versioning assumptions. As for those, we scan and check kernel source. The following are backportable: - path_umount: context: tiann#1464 (comment) apply: xiaomi-sdm678/android_kernel_xiaomi_mojito@2d51422 - strncpy_from_user_nofault for 5.4, apply: torvalds/linux@bd88bb5 for 4.x, apply: xiaomi-sdm678/android_kernel_xiaomi_mojito@424e21f for any failures, check dependency chain of gregkh/linux@f43434e - kernel_read / kernel_write < 4.14, backport chain, tested on 4.9 torvalds/linux@e13ec93 torvalds/linux@bdd1d2d torvalds/linux@c41fbad torvalds/linux@ac452ac - hint, `curl $url.patch | git am` Signed-off-by: backslashxx <[email protected]>

backslashxx mentioned this pull request Mar 17, 2024

Force non-gki kernel users to backport path_umount #1463

Closed

backslashxx force-pushed the pr-umount-2 branch from 2dd4574 to 3e302dc Compare March 17, 2024 10:16

backslashxx force-pushed the pr-umount-2 branch from 3e302dc to 2e0f0f2 Compare March 17, 2024 10:36

backslashxx mentioned this pull request Mar 17, 2024

kernel: Make it compile on 3.18 (maybe older) kernels #1460

Merged

backslashxx mentioned this pull request Mar 17, 2024

porting KernelSU to android kernel3.18 failed #539

Closed

backslashxx force-pushed the pr-umount-2 branch from 2e0f0f2 to a7a1eec Compare March 17, 2024 12:02

backslashxx force-pushed the pr-umount-2 branch from df9e2ef to ae2d84c Compare March 17, 2024 12:10

backslashxx force-pushed the pr-umount-2 branch 2 times, most recently from b9f98c2 to a973393 Compare March 17, 2024 12:47

backslashxx force-pushed the pr-umount-2 branch from a973393 to a54eca1 Compare March 17, 2024 13:12

Fede2782 suggested changes Mar 17, 2024

View reviewed changes

website/docs/guide/how-to-integrate-for-non-gki.md Outdated Show resolved Hide resolved

kernel/core_hook.c Outdated Show resolved Hide resolved

website/docs/guide/how-to-integrate-for-non-gki.md Outdated Show resolved Hide resolved

backslashxx commented Mar 17, 2024

View reviewed changes

kernel/core_hook.c Outdated Show resolved Hide resolved

backslashxx force-pushed the pr-umount-2 branch from 24171c7 to 4677047 Compare March 17, 2024 13:18

Fede2782 approved these changes Mar 17, 2024

View reviewed changes

backslashxx force-pushed the pr-umount-2 branch from b301b55 to 848047a Compare March 17, 2024 13:24

Uh oh!

Suggest non-gki kernel users to backport path_umount #1464

Suggest non-gki kernel users to backport path_umount #1464

Uh oh!

Conversation

backslashxx commented Mar 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Asyanx commented Mar 17, 2024

Uh oh!

xennin commented Mar 17, 2024

Uh oh!

Fede2782 commented Mar 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alternoegraha commented Mar 17, 2024

Uh oh!

losshye commented Mar 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

privacyguy123 commented Mar 17, 2024

Uh oh!

Fede2782 commented Mar 17, 2024

Uh oh!

backslashxx commented Mar 17, 2024

Uh oh!

FerryAr commented Mar 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

riarumoda commented Mar 17, 2024

Uh oh!

Fede2782 commented Mar 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

backslashxx commented Mar 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

backslashxx commented Mar 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

backslashxx commented Mar 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Fede2782 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

backslashxx commented Mar 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

backslashxx commented Mar 17, 2024 •

edited

Loading

Fede2782 commented Mar 17, 2024 •

edited

Loading

losshye commented Mar 17, 2024 •

edited

Loading

FerryAr commented Mar 17, 2024 •

edited

Loading

Fede2782 commented Mar 17, 2024 •

edited

Loading

backslashxx commented Mar 17, 2024 •

edited

Loading

backslashxx commented Mar 17, 2024 •

edited

Loading

backslashxx commented Mar 17, 2024 •

edited

Loading

backslashxx commented Mar 17, 2024 •

edited

Loading