* [PATCH] bpf: move the bpf syscall sysctl table to its own module
@ 2022-02-23 1:35 Yan Zhu
2022-02-23 1:42 ` Luis Chamberlain
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Yan Zhu @ 2022-02-23 1:35 UTC (permalink / raw)
To: ast, daniel, andrii, kafai, songliubraving, yhs, john.fastabend,
kpsingh, mcgrof, keescook, yzaikin, netdev, bpf, linux-kernel,
linux-fsdevel
Cc: zengweilin, liucheng32, nixiaoming, xiechengliang1, zhuyan34
Sysctl table is easier to read under its own module.
Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
---
kernel/bpf/syscall.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++
kernel/sysctl.c | 71 ----------------------------------------------
2 files changed, 80 insertions(+), 71 deletions(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index fa4505f9b611..3cc50292a032 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -4850,3 +4850,83 @@ const struct bpf_verifier_ops bpf_syscall_verifier_ops = {
const struct bpf_prog_ops bpf_syscall_prog_ops = {
.test_run = bpf_prog_test_run_syscall,
};
+
+#ifdef CONFIG_SYSCTL
+static int bpf_stats_handler(struct ctl_table *table, int write,
+ void *buffer, size_t *lenp, loff_t *ppos)
+{
+ struct static_key *key = (struct static_key *)table->data;
+ static int saved_val;
+ int val, ret;
+ struct ctl_table tmp = {
+ .data = &val,
+ .maxlen = sizeof(val),
+ .mode = table->mode,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = SYSCTL_ONE,
+ };
+
+ if (write && !capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ mutex_lock(&bpf_stats_enabled_mutex);
+ val = saved_val;
+ ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
+ if (write && !ret && val != saved_val) {
+ if (val)
+ static_key_slow_inc(key);
+ else
+ static_key_slow_dec(key);
+ saved_val = val;
+ }
+ mutex_unlock(&bpf_stats_enabled_mutex);
+ return ret;
+}
+
+static int bpf_unpriv_handler(struct ctl_table *table, int write,
+ void *buffer, size_t *lenp, loff_t *ppos)
+{
+ int ret, unpriv_enable = *(int *)table->data;
+ bool locked_state = unpriv_enable == 1;
+ struct ctl_table tmp = *table;
+
+ if (write && !capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ tmp.data = &unpriv_enable;
+ ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
+ if (write && !ret) {
+ if (locked_state && unpriv_enable != 1)
+ return -EPERM;
+ *(int *)table->data = unpriv_enable;
+ }
+ return ret;
+}
+
+static struct ctl_table bpf_syscall_table[] = {
+ {
+ .procname = "unprivileged_bpf_disabled",
+ .data = &sysctl_unprivileged_bpf_disabled,
+ .maxlen = sizeof(sysctl_unprivileged_bpf_disabled),
+ .mode = 0644,
+ .proc_handler = bpf_unpriv_handler,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = SYSCTL_TWO,
+ },
+ {
+ .procname = "bpf_stats_enabled",
+ .data = &bpf_stats_enabled_key.key,
+ .maxlen = sizeof(bpf_stats_enabled_key),
+ .mode = 0644,
+ .proc_handler = bpf_stats_handler,
+ },
+ { }
+};
+
+static int __init bpf_syscall_sysctl_init(void)
+{
+ register_sysctl_init("kernel", bpf_syscall_table);
+ return 0;
+}
+late_initcall(bpf_syscall_sysctl_init);
+#endif /* CONFIG_SYSCTL */
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 22037f03cd2b..5ae905677eaf 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -139,59 +139,6 @@ static const int max_extfrag_threshold = 1000;
#endif /* CONFIG_SYSCTL */
-#if defined(CONFIG_BPF_SYSCALL) && defined(CONFIG_SYSCTL)
-static int bpf_stats_handler(struct ctl_table *table, int write,
- void *buffer, size_t *lenp, loff_t *ppos)
-{
- struct static_key *key = (struct static_key *)table->data;
- static int saved_val;
- int val, ret;
- struct ctl_table tmp = {
- .data = &val,
- .maxlen = sizeof(val),
- .mode = table->mode,
- .extra1 = SYSCTL_ZERO,
- .extra2 = SYSCTL_ONE,
- };
-
- if (write && !capable(CAP_SYS_ADMIN))
- return -EPERM;
-
- mutex_lock(&bpf_stats_enabled_mutex);
- val = saved_val;
- ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
- if (write && !ret && val != saved_val) {
- if (val)
- static_key_slow_inc(key);
- else
- static_key_slow_dec(key);
- saved_val = val;
- }
- mutex_unlock(&bpf_stats_enabled_mutex);
- return ret;
-}
-
-static int bpf_unpriv_handler(struct ctl_table *table, int write,
- void *buffer, size_t *lenp, loff_t *ppos)
-{
- int ret, unpriv_enable = *(int *)table->data;
- bool locked_state = unpriv_enable == 1;
- struct ctl_table tmp = *table;
-
- if (write && !capable(CAP_SYS_ADMIN))
- return -EPERM;
-
- tmp.data = &unpriv_enable;
- ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
- if (write && !ret) {
- if (locked_state && unpriv_enable != 1)
- return -EPERM;
- *(int *)table->data = unpriv_enable;
- }
- return ret;
-}
-#endif /* CONFIG_BPF_SYSCALL && CONFIG_SYSCTL */
-
/*
* /proc/sys support
*/
@@ -2125,24 +2072,6 @@ static struct ctl_table kern_table[] = {
.extra2 = SYSCTL_ONE,
},
#endif
-#ifdef CONFIG_BPF_SYSCALL
- {
- .procname = "unprivileged_bpf_disabled",
- .data = &sysctl_unprivileged_bpf_disabled,
- .maxlen = sizeof(sysctl_unprivileged_bpf_disabled),
- .mode = 0644,
- .proc_handler = bpf_unpriv_handler,
- .extra1 = SYSCTL_ZERO,
- .extra2 = SYSCTL_TWO,
- },
- {
- .procname = "bpf_stats_enabled",
- .data = &bpf_stats_enabled_key.key,
- .maxlen = sizeof(bpf_stats_enabled_key),
- .mode = 0644,
- .proc_handler = bpf_stats_handler,
- },
-#endif
#if defined(CONFIG_TREE_RCU)
{
.procname = "panic_on_rcu_stall",
--
2.12.3
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH] bpf: move the bpf syscall sysctl table to its own module
2022-02-23 1:35 [PATCH] bpf: move the bpf syscall sysctl table to its own module Yan Zhu
@ 2022-02-23 1:42 ` Luis Chamberlain
2022-02-23 10:28 ` [PATCH v2 sysctl-next] bpf: move the bpf syscall sysctl table to bpf module Yan Zhu
2022-02-23 4:28 ` [PATCH] bpf: move the bpf syscall sysctl table to its own module Matthew Wilcox
2022-02-23 5:06 ` Alexei Starovoitov
2 siblings, 1 reply; 21+ messages in thread
From: Luis Chamberlain @ 2022-02-23 1:42 UTC (permalink / raw)
To: Yan Zhu
Cc: ast, daniel, andrii, kafai, songliubraving, yhs, john.fastabend,
kpsingh, keescook, yzaikin, netdev, bpf, linux-kernel,
linux-fsdevel, zengweilin, liucheng32, nixiaoming,
xiechengliang1
On Wed, Feb 23, 2022 at 09:35:29AM +0800, Yan Zhu wrote:
> Sysctl table is easier to read under its own module.
Hey Yan, thanks for you patch!
This does not explain how this is being to help with maitenance as
otherwise this makes kernel/sysctl.c hard to maintain and we also
tend to get many conflicts. It also does not explain how all the
filesystem sysctls are not gone and that this is just the next step,
moving slowly the rest of the sysctls. Explaining this in the commit
log will help patch review and subsystem maintainers understand the
conext / logic behind the move.
> Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
I'd be more than happy to take this if bpf folks Ack. To avoid conflicts
I can route this through sysctl-next which is put forward in particular
to avoid conflicts across trees for this effort. Let me know.
Luis
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] bpf: move the bpf syscall sysctl table to its own module
2022-02-23 1:35 [PATCH] bpf: move the bpf syscall sysctl table to its own module Yan Zhu
2022-02-23 1:42 ` Luis Chamberlain
@ 2022-02-23 4:28 ` Matthew Wilcox
2022-02-23 5:06 ` Alexei Starovoitov
2 siblings, 0 replies; 21+ messages in thread
From: Matthew Wilcox @ 2022-02-23 4:28 UTC (permalink / raw)
To: Yan Zhu
Cc: ast, daniel, andrii, kafai, songliubraving, yhs, john.fastabend,
kpsingh, mcgrof, keescook, yzaikin, netdev, bpf, linux-kernel,
linux-fsdevel, zengweilin, liucheng32, nixiaoming,
xiechengliang1
On Wed, Feb 23, 2022 at 09:35:29AM +0800, Yan Zhu wrote:
> +static struct ctl_table bpf_syscall_table[] = {
> + {
> + .procname = "unprivileged_bpf_disabled",
> + .data = &sysctl_unprivileged_bpf_disabled,
> + .maxlen = sizeof(sysctl_unprivileged_bpf_disabled),
> + .mode = 0644,
> + .proc_handler = bpf_unpriv_handler,
> + .extra1 = SYSCTL_ZERO,
> + .extra2 = SYSCTL_TWO,
> + },
> + {
> + .procname = "bpf_stats_enabled",
> + .data = &bpf_stats_enabled_key.key,
> + .maxlen = sizeof(bpf_stats_enabled_key),
> + .mode = 0644,
> + .proc_handler = bpf_stats_handler,
> + },
> + { }
> +};
No progress towards a counted array instead of a NULL terminated one?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] bpf: move the bpf syscall sysctl table to its own module
2022-02-23 1:35 [PATCH] bpf: move the bpf syscall sysctl table to its own module Yan Zhu
2022-02-23 1:42 ` Luis Chamberlain
2022-02-23 4:28 ` [PATCH] bpf: move the bpf syscall sysctl table to its own module Matthew Wilcox
@ 2022-02-23 5:06 ` Alexei Starovoitov
2022-02-23 9:50 ` Yan Zhu
2 siblings, 1 reply; 21+ messages in thread
From: Alexei Starovoitov @ 2022-02-23 5:06 UTC (permalink / raw)
To: Yan Zhu
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Luis R. Rodriguez, Kees Cook, Iurii Zaikin,
Network Development, bpf, LKML, Linux-Fsdevel, zengweilin,
liucheng32, Xiaoming Ni, xiechengliang1
On Tue, Feb 22, 2022 at 5:35 PM Yan Zhu <zhuyan34@huawei.com> wrote:
>
> Sysctl table is easier to read under its own module.
"own module"?
What are you talking about?
It's not "easier to read" and looks like a pointless churn.
> Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
> ---
> kernel/bpf/syscall.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> kernel/sysctl.c | 71 ----------------------------------------------
> 2 files changed, 80 insertions(+), 71 deletions(-)
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] bpf: move the bpf syscall sysctl table to its own module
2022-02-23 5:06 ` Alexei Starovoitov
@ 2022-02-23 9:50 ` Yan Zhu
0 siblings, 0 replies; 21+ messages in thread
From: Yan Zhu @ 2022-02-23 9:50 UTC (permalink / raw)
To: alexei.starovoitov
Cc: andrii, ast, bpf, daniel, john.fastabend, kafai, keescook,
kpsingh, linux-fsdevel, linux-kernel, liucheng32, mcgrof, netdev,
nixiaoming, songliubraving, xiechengliang1, yhs, yzaikin,
zengweilin, zhuyan34
On Tue, Feb 22, 2022 at 9:06 PM Alexei Starovoitov wrote:
> On Tue, Feb 22, 2022 at 5:35 PM Yan Zhu <zhuyan34@huawei.com> wrote:
> >
> > Sysctl table is easier to read under its own module.
>
> "own module"?
> What are you talking about?
I'm sorry I didn't express it clearly. The meaning here is that
the code of bpf syscall sysctl is moved to the bpf module
I will fix it in v2 patch.
> It's not "easier to read" and looks like a pointless churn.
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v2 sysctl-next] bpf: move the bpf syscall sysctl table to bpf module
2022-02-23 1:42 ` Luis Chamberlain
@ 2022-02-23 10:28 ` Yan Zhu
2022-02-28 15:53 ` Daniel Borkmann
0 siblings, 1 reply; 21+ messages in thread
From: Yan Zhu @ 2022-02-23 10:28 UTC (permalink / raw)
To: mcgrof
Cc: andrii, ast, bpf, daniel, john.fastabend, kafai, keescook,
kpsingh, linux-fsdevel, linux-kernel, liucheng32, netdev,
nixiaoming, songliubraving, xiechengliang1, yhs, yzaikin,
zengweilin, zhuyan34
Aggregating the code of the feature in the code file of the feature
itself can improve readability and reduce merge conflicts. So move
the bpf syscall sysctl table to kernel/bpf/syscall.c
Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
---
v1->v2:
1.Added patch branch identifier sysctl-next.
2.Re-describe the reason for the patch submission.
---
kernel/bpf/syscall.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++
kernel/sysctl.c | 71 ----------------------------------------------
2 files changed, 80 insertions(+), 71 deletions(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 35646db3d950..50f85b47d478 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -4888,3 +4888,83 @@ const struct bpf_verifier_ops bpf_syscall_verifier_ops = {
const struct bpf_prog_ops bpf_syscall_prog_ops = {
.test_run = bpf_prog_test_run_syscall,
};
+
+#ifdef CONFIG_SYSCTL
+static int bpf_stats_handler(struct ctl_table *table, int write,
+ void *buffer, size_t *lenp, loff_t *ppos)
+{
+ struct static_key *key = (struct static_key *)table->data;
+ static int saved_val;
+ int val, ret;
+ struct ctl_table tmp = {
+ .data = &val,
+ .maxlen = sizeof(val),
+ .mode = table->mode,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = SYSCTL_ONE,
+ };
+
+ if (write && !capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ mutex_lock(&bpf_stats_enabled_mutex);
+ val = saved_val;
+ ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
+ if (write && !ret && val != saved_val) {
+ if (val)
+ static_key_slow_inc(key);
+ else
+ static_key_slow_dec(key);
+ saved_val = val;
+ }
+ mutex_unlock(&bpf_stats_enabled_mutex);
+ return ret;
+}
+
+static int bpf_unpriv_handler(struct ctl_table *table, int write,
+ void *buffer, size_t *lenp, loff_t *ppos)
+{
+ int ret, unpriv_enable = *(int *)table->data;
+ bool locked_state = unpriv_enable == 1;
+ struct ctl_table tmp = *table;
+
+ if (write && !capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ tmp.data = &unpriv_enable;
+ ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
+ if (write && !ret) {
+ if (locked_state && unpriv_enable != 1)
+ return -EPERM;
+ *(int *)table->data = unpriv_enable;
+ }
+ return ret;
+}
+
+static struct ctl_table bpf_syscall_table[] = {
+ {
+ .procname = "unprivileged_bpf_disabled",
+ .data = &sysctl_unprivileged_bpf_disabled,
+ .maxlen = sizeof(sysctl_unprivileged_bpf_disabled),
+ .mode = 0644,
+ .proc_handler = bpf_unpriv_handler,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = SYSCTL_TWO,
+ },
+ {
+ .procname = "bpf_stats_enabled",
+ .data = &bpf_stats_enabled_key.key,
+ .maxlen = sizeof(bpf_stats_enabled_key),
+ .mode = 0644,
+ .proc_handler = bpf_stats_handler,
+ },
+ { }
+};
+
+static int __init bpf_syscall_sysctl_init(void)
+{
+ register_sysctl_init("kernel", bpf_syscall_table);
+ return 0;
+}
+late_initcall(bpf_syscall_sysctl_init);
+#endif /* CONFIG_SYSCTL */
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index ae5e59396b5d..c64db3755d9c 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -146,59 +146,6 @@ static const int max_extfrag_threshold = 1000;
#endif /* CONFIG_SYSCTL */
-#if defined(CONFIG_BPF_SYSCALL) && defined(CONFIG_SYSCTL)
-static int bpf_stats_handler(struct ctl_table *table, int write,
- void *buffer, size_t *lenp, loff_t *ppos)
-{
- struct static_key *key = (struct static_key *)table->data;
- static int saved_val;
- int val, ret;
- struct ctl_table tmp = {
- .data = &val,
- .maxlen = sizeof(val),
- .mode = table->mode,
- .extra1 = SYSCTL_ZERO,
- .extra2 = SYSCTL_ONE,
- };
-
- if (write && !capable(CAP_SYS_ADMIN))
- return -EPERM;
-
- mutex_lock(&bpf_stats_enabled_mutex);
- val = saved_val;
- ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
- if (write && !ret && val != saved_val) {
- if (val)
- static_key_slow_inc(key);
- else
- static_key_slow_dec(key);
- saved_val = val;
- }
- mutex_unlock(&bpf_stats_enabled_mutex);
- return ret;
-}
-
-static int bpf_unpriv_handler(struct ctl_table *table, int write,
- void *buffer, size_t *lenp, loff_t *ppos)
-{
- int ret, unpriv_enable = *(int *)table->data;
- bool locked_state = unpriv_enable == 1;
- struct ctl_table tmp = *table;
-
- if (write && !capable(CAP_SYS_ADMIN))
- return -EPERM;
-
- tmp.data = &unpriv_enable;
- ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
- if (write && !ret) {
- if (locked_state && unpriv_enable != 1)
- return -EPERM;
- *(int *)table->data = unpriv_enable;
- }
- return ret;
-}
-#endif /* CONFIG_BPF_SYSCALL && CONFIG_SYSCTL */
-
/*
* /proc/sys support
*/
@@ -2188,24 +2135,6 @@ static struct ctl_table kern_table[] = {
.extra2 = SYSCTL_ONE,
},
#endif
-#ifdef CONFIG_BPF_SYSCALL
- {
- .procname = "unprivileged_bpf_disabled",
- .data = &sysctl_unprivileged_bpf_disabled,
- .maxlen = sizeof(sysctl_unprivileged_bpf_disabled),
- .mode = 0644,
- .proc_handler = bpf_unpriv_handler,
- .extra1 = SYSCTL_ZERO,
- .extra2 = SYSCTL_TWO,
- },
- {
- .procname = "bpf_stats_enabled",
- .data = &bpf_stats_enabled_key.key,
- .maxlen = sizeof(bpf_stats_enabled_key),
- .mode = 0644,
- .proc_handler = bpf_stats_handler,
- },
-#endif
#if defined(CONFIG_TREE_RCU)
{
.procname = "panic_on_rcu_stall",
--
2.12.3
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH v2 sysctl-next] bpf: move the bpf syscall sysctl table to bpf module
2022-02-23 10:28 ` [PATCH v2 sysctl-next] bpf: move the bpf syscall sysctl table to bpf module Yan Zhu
@ 2022-02-28 15:53 ` Daniel Borkmann
2022-02-28 23:41 ` Luis Chamberlain
0 siblings, 1 reply; 21+ messages in thread
From: Daniel Borkmann @ 2022-02-28 15:53 UTC (permalink / raw)
To: Yan Zhu, mcgrof
Cc: andrii, ast, bpf, john.fastabend, kafai, keescook, kpsingh,
linux-fsdevel, linux-kernel, liucheng32, netdev, nixiaoming,
songliubraving, xiechengliang1, yhs, yzaikin, zengweilin
Hi Yan,
On 2/23/22 11:28 AM, Yan Zhu wrote:
> Aggregating the code of the feature in the code file of the feature
> itself can improve readability and reduce merge conflicts. So move
> the bpf syscall sysctl table to kernel/bpf/syscall.c
>
> Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
>
> ---
> v1->v2:
> 1.Added patch branch identifier sysctl-next.
> 2.Re-describe the reason for the patch submission.
I'm not applying it given there is very little value in this change, see also what
has been said earlier:
https://lore.kernel.org/bpf/CAADnVQKmBoQEG1+nmrCg2ePVncn9rZJX9R4eucP9ULiY=xVGjQ@mail.gmail.com/
Thanks,
Daniel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v2 sysctl-next] bpf: move the bpf syscall sysctl table to bpf module
2022-02-28 15:53 ` Daniel Borkmann
@ 2022-02-28 23:41 ` Luis Chamberlain
2022-03-02 1:58 ` Yan Zhu
2022-03-02 2:04 ` [PATCH v3 sysctl-next] bpf: move bpf sysctls from kernel/sysctl.c " Yan Zhu
0 siblings, 2 replies; 21+ messages in thread
From: Luis Chamberlain @ 2022-02-28 23:41 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Yan Zhu, andrii, ast, bpf, john.fastabend, kafai, keescook,
kpsingh, linux-fsdevel, linux-kernel, liucheng32, netdev,
nixiaoming, songliubraving, xiechengliang1, yhs, yzaikin,
zengweilin
On Mon, Feb 28, 2022 at 04:53:44PM +0100, Daniel Borkmann wrote:
> Hi Yan,
>
> On 2/23/22 11:28 AM, Yan Zhu wrote:
> > Aggregating the code of the feature in the code file of the feature
> > itself can improve readability and reduce merge conflicts. So move
> > the bpf syscall sysctl table to kernel/bpf/syscall.c
> >
> > Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
> >
> > ---
> > v1->v2:
> > 1.Added patch branch identifier sysctl-next.
> > 2.Re-describe the reason for the patch submission.
>
> I'm not applying it given there is very little value in this change, see also what
> has been said earlier:
>
> https://lore.kernel.org/bpf/CAADnVQKmBoQEG1+nmrCg2ePVncn9rZJX9R4eucP9ULiY=xVGjQ@mail.gmail.com/
Daniel,
sorry folk are seing you patches with crap commit logs. The
justification should be made clearer: we're moving sysctls out of
kernel/sysctl.c as its a mess. I already moved all filesystem sysctls
out. And with time the goal is to move all sysctls out to their own
susbsystem/actual user.
kernel/sysctl.c has grown to an insane mess and its easy to run
into conflicts with it. The effort to move them out is part of this.
The commit logs should not suck though...
Luis
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v2 sysctl-next] bpf: move the bpf syscall sysctl table to bpf module
2022-02-28 23:41 ` Luis Chamberlain
@ 2022-03-02 1:58 ` Yan Zhu
2022-03-02 2:04 ` [PATCH v3 sysctl-next] bpf: move bpf sysctls from kernel/sysctl.c " Yan Zhu
1 sibling, 0 replies; 21+ messages in thread
From: Yan Zhu @ 2022-03-02 1:58 UTC (permalink / raw)
To: mcgrof
Cc: andrii, ast, bpf, daniel, john.fastabend, kafai, keescook,
kpsingh, linux-fsdevel, linux-kernel, liucheng32, netdev,
nixiaoming, songliubraving, xiechengliang1, yhs, yzaikin,
zengweilin, zhuyan34
Mon, 28 Feb 2022 15:41:40 -0800, Luis Chamberlain wrote:
> On Mon, Feb 28, 2022 at 04:53:44PM +0100, Daniel Borkmann wrote:
> > Hi Yan,
> >
> > On 2/23/22 11:28 AM, Yan Zhu wrote:
> > > Aggregating the code of the feature in the code file of the feature
> > > itself can improve readability and reduce merge conflicts. So move
> > > the bpf syscall sysctl table to kernel/bpf/syscall.c
> > >
> > > Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
> > >
> > > ---
> > > v1->v2:
> > > 1.Added patch branch identifier sysctl-next.
> > > 2.Re-describe the reason for the patch submission.
> >
> > I'm not applying it given there is very little value in this change, see also what
> > has been said earlier:
> >
> > https://lore.kernel.org/bpf/CAADnVQKmBoQEG1+nmrCg2ePVncn9rZJX9R4eucP9ULiY=xVGjQ@mail.gmail.com/
>
> Daniel,
>
> sorry folk are seing you patches with crap commit logs. The
> justification should be made clearer: we're moving sysctls out of
> kernel/sysctl.c as its a mess. I already moved all filesystem sysctls
> out. And with time the goal is to move all sysctls out to their own
> susbsystem/actual user.
> kernel/sysctl.c has grown to an insane mess and its easy to run
> into conflicts with it. The effort to move them out is part of this.
Luis,
Thanks for the suggestion, I will use it as my patch from the commit
message to be able to clearly describe the purpose of the patch.
> The commit logs should not suck though...
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v3 sysctl-next] bpf: move bpf sysctls from kernel/sysctl.c to bpf module
2022-02-28 23:41 ` Luis Chamberlain
2022-03-02 1:58 ` Yan Zhu
@ 2022-03-02 2:04 ` Yan Zhu
2022-03-02 20:39 ` Luis Chamberlain
1 sibling, 1 reply; 21+ messages in thread
From: Yan Zhu @ 2022-03-02 2:04 UTC (permalink / raw)
To: mcgrof
Cc: andrii, ast, bpf, daniel, john.fastabend, kafai, keescook,
kpsingh, linux-fsdevel, linux-kernel, liucheng32, netdev,
nixiaoming, songliubraving, xiechengliang1, yhs, yzaikin,
zengweilin, zhuyan34
We're moving sysctls out of kernel/sysctl.c as its a mess. We
already moved all filesystem sysctls out. And with time the goal is
to move all sysctls out to their own susbsystem/actual user.
kernel/sysctl.c has grown to an insane mess and its easy to run
into conflicts with it. The effort to move them out is part of this.
Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
---
v1->v2:
1.Added patch branch identifier sysctl-next.
2.Re-describe the reason for the patch submission.
v2->v3:
Re-describe the reason for the patch submission.
---
kernel/bpf/syscall.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++
kernel/sysctl.c | 71 ----------------------------------------------
2 files changed, 80 insertions(+), 71 deletions(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 35646db3d950..50f85b47d478 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -4888,3 +4888,83 @@ const struct bpf_verifier_ops bpf_syscall_verifier_ops = {
const struct bpf_prog_ops bpf_syscall_prog_ops = {
.test_run = bpf_prog_test_run_syscall,
};
+
+#ifdef CONFIG_SYSCTL
+static int bpf_stats_handler(struct ctl_table *table, int write,
+ void *buffer, size_t *lenp, loff_t *ppos)
+{
+ struct static_key *key = (struct static_key *)table->data;
+ static int saved_val;
+ int val, ret;
+ struct ctl_table tmp = {
+ .data = &val,
+ .maxlen = sizeof(val),
+ .mode = table->mode,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = SYSCTL_ONE,
+ };
+
+ if (write && !capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ mutex_lock(&bpf_stats_enabled_mutex);
+ val = saved_val;
+ ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
+ if (write && !ret && val != saved_val) {
+ if (val)
+ static_key_slow_inc(key);
+ else
+ static_key_slow_dec(key);
+ saved_val = val;
+ }
+ mutex_unlock(&bpf_stats_enabled_mutex);
+ return ret;
+}
+
+static int bpf_unpriv_handler(struct ctl_table *table, int write,
+ void *buffer, size_t *lenp, loff_t *ppos)
+{
+ int ret, unpriv_enable = *(int *)table->data;
+ bool locked_state = unpriv_enable == 1;
+ struct ctl_table tmp = *table;
+
+ if (write && !capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ tmp.data = &unpriv_enable;
+ ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
+ if (write && !ret) {
+ if (locked_state && unpriv_enable != 1)
+ return -EPERM;
+ *(int *)table->data = unpriv_enable;
+ }
+ return ret;
+}
+
+static struct ctl_table bpf_syscall_table[] = {
+ {
+ .procname = "unprivileged_bpf_disabled",
+ .data = &sysctl_unprivileged_bpf_disabled,
+ .maxlen = sizeof(sysctl_unprivileged_bpf_disabled),
+ .mode = 0644,
+ .proc_handler = bpf_unpriv_handler,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = SYSCTL_TWO,
+ },
+ {
+ .procname = "bpf_stats_enabled",
+ .data = &bpf_stats_enabled_key.key,
+ .maxlen = sizeof(bpf_stats_enabled_key),
+ .mode = 0644,
+ .proc_handler = bpf_stats_handler,
+ },
+ { }
+};
+
+static int __init bpf_syscall_sysctl_init(void)
+{
+ register_sysctl_init("kernel", bpf_syscall_table);
+ return 0;
+}
+late_initcall(bpf_syscall_sysctl_init);
+#endif /* CONFIG_SYSCTL */
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index ae5e59396b5d..c64db3755d9c 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -146,59 +146,6 @@ static const int max_extfrag_threshold = 1000;
#endif /* CONFIG_SYSCTL */
-#if defined(CONFIG_BPF_SYSCALL) && defined(CONFIG_SYSCTL)
-static int bpf_stats_handler(struct ctl_table *table, int write,
- void *buffer, size_t *lenp, loff_t *ppos)
-{
- struct static_key *key = (struct static_key *)table->data;
- static int saved_val;
- int val, ret;
- struct ctl_table tmp = {
- .data = &val,
- .maxlen = sizeof(val),
- .mode = table->mode,
- .extra1 = SYSCTL_ZERO,
- .extra2 = SYSCTL_ONE,
- };
-
- if (write && !capable(CAP_SYS_ADMIN))
- return -EPERM;
-
- mutex_lock(&bpf_stats_enabled_mutex);
- val = saved_val;
- ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
- if (write && !ret && val != saved_val) {
- if (val)
- static_key_slow_inc(key);
- else
- static_key_slow_dec(key);
- saved_val = val;
- }
- mutex_unlock(&bpf_stats_enabled_mutex);
- return ret;
-}
-
-static int bpf_unpriv_handler(struct ctl_table *table, int write,
- void *buffer, size_t *lenp, loff_t *ppos)
-{
- int ret, unpriv_enable = *(int *)table->data;
- bool locked_state = unpriv_enable == 1;
- struct ctl_table tmp = *table;
-
- if (write && !capable(CAP_SYS_ADMIN))
- return -EPERM;
-
- tmp.data = &unpriv_enable;
- ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
- if (write && !ret) {
- if (locked_state && unpriv_enable != 1)
- return -EPERM;
- *(int *)table->data = unpriv_enable;
- }
- return ret;
-}
-#endif /* CONFIG_BPF_SYSCALL && CONFIG_SYSCTL */
-
/*
* /proc/sys support
*/
@@ -2188,24 +2135,6 @@ static struct ctl_table kern_table[] = {
.extra2 = SYSCTL_ONE,
},
#endif
-#ifdef CONFIG_BPF_SYSCALL
- {
- .procname = "unprivileged_bpf_disabled",
- .data = &sysctl_unprivileged_bpf_disabled,
- .maxlen = sizeof(sysctl_unprivileged_bpf_disabled),
- .mode = 0644,
- .proc_handler = bpf_unpriv_handler,
- .extra1 = SYSCTL_ZERO,
- .extra2 = SYSCTL_TWO,
- },
- {
- .procname = "bpf_stats_enabled",
- .data = &bpf_stats_enabled_key.key,
- .maxlen = sizeof(bpf_stats_enabled_key),
- .mode = 0644,
- .proc_handler = bpf_stats_handler,
- },
-#endif
#if defined(CONFIG_TREE_RCU)
{
.procname = "panic_on_rcu_stall",
--
2.12.3
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH v3 sysctl-next] bpf: move bpf sysctls from kernel/sysctl.c to bpf module
2022-03-02 2:04 ` [PATCH v3 sysctl-next] bpf: move bpf sysctls from kernel/sysctl.c " Yan Zhu
@ 2022-03-02 20:39 ` Luis Chamberlain
2022-03-03 23:44 ` Daniel Borkmann
0 siblings, 1 reply; 21+ messages in thread
From: Luis Chamberlain @ 2022-03-02 20:39 UTC (permalink / raw)
To: Yan Zhu
Cc: andrii, ast, bpf, daniel, john.fastabend, kafai, keescook,
kpsingh, linux-fsdevel, linux-kernel, liucheng32, netdev,
nixiaoming, songliubraving, xiechengliang1, yhs, yzaikin,
zengweilin
On Wed, Mar 02, 2022 at 10:04:12AM +0800, Yan Zhu wrote:
> We're moving sysctls out of kernel/sysctl.c as its a mess. We
> already moved all filesystem sysctls out. And with time the goal is
> to move all sysctls out to their own susbsystem/actual user.
>
> kernel/sysctl.c has grown to an insane mess and its easy to run
> into conflicts with it. The effort to move them out is part of this.
>
> Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
Daniel, let me know if this makes more sense now, and if so I can
offer take it through sysctl-next to avoid conflicts more sysctl knobs
get moved out from kernel/sysctl.c.
Luis
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v3 sysctl-next] bpf: move bpf sysctls from kernel/sysctl.c to bpf module
2022-03-02 20:39 ` Luis Chamberlain
@ 2022-03-03 23:44 ` Daniel Borkmann
2022-03-04 0:23 ` Luis Chamberlain
0 siblings, 1 reply; 21+ messages in thread
From: Daniel Borkmann @ 2022-03-03 23:44 UTC (permalink / raw)
To: Luis Chamberlain, Yan Zhu
Cc: andrii, ast, bpf, john.fastabend, kafai, keescook, kpsingh,
linux-fsdevel, linux-kernel, liucheng32, netdev, nixiaoming,
songliubraving, xiechengliang1, yhs, yzaikin, zengweilin
On 3/2/22 9:39 PM, Luis Chamberlain wrote:
> On Wed, Mar 02, 2022 at 10:04:12AM +0800, Yan Zhu wrote:
>> We're moving sysctls out of kernel/sysctl.c as its a mess. We
>> already moved all filesystem sysctls out. And with time the goal is
>> to move all sysctls out to their own susbsystem/actual user.
>>
>> kernel/sysctl.c has grown to an insane mess and its easy to run
>> into conflicts with it. The effort to move them out is part of this.
>>
>> Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
>
> Daniel, let me know if this makes more sense now, and if so I can
> offer take it through sysctl-next to avoid conflicts more sysctl knobs
> get moved out from kernel/sysctl.c.
If this is a whole ongoing effort rather than drive-by patch, then it's
fine with me. Btw, the patch itself should also drop the linux/bpf.h
include from kernel/sysctl.c since nothing else is using it after the
patch.
Btw, related to cleanups.. historically, we have a bunch of other knobs
for BPF under net (in net_core_table), that is:
/proc/sys/net/core/bpf_jit_enable
/proc/sys/net/core/bpf_jit_harden
/proc/sys/net/core/bpf_jit_kallsyms
/proc/sys/net/core/bpf_jit_limit
Would be nice to consolidate all under e.g. /proc/sys/kernel/bpf_* for
future going forward, and technically, they should be usable also w/o
net configured into kernel. Is there infra to point the sysctl knobs
e.g. under net/core/ to kernel/, or best way would be to have single
struct ctl_table and register for both?
Cheers,
Daniel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v3 sysctl-next] bpf: move bpf sysctls from kernel/sysctl.c to bpf module
2022-03-03 23:44 ` Daniel Borkmann
@ 2022-03-04 0:23 ` Luis Chamberlain
2022-04-06 22:41 ` Luis Chamberlain
0 siblings, 1 reply; 21+ messages in thread
From: Luis Chamberlain @ 2022-03-04 0:23 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Yan Zhu, andrii, ast, bpf, john.fastabend, kafai, keescook,
kpsingh, linux-fsdevel, linux-kernel, liucheng32, netdev,
nixiaoming, songliubraving, xiechengliang1, yhs, yzaikin,
zengweilin
On Fri, Mar 04, 2022 at 12:44:48AM +0100, Daniel Borkmann wrote:
> On 3/2/22 9:39 PM, Luis Chamberlain wrote:
> > On Wed, Mar 02, 2022 at 10:04:12AM +0800, Yan Zhu wrote:
> > > We're moving sysctls out of kernel/sysctl.c as its a mess. We
> > > already moved all filesystem sysctls out. And with time the goal is
> > > to move all sysctls out to their own susbsystem/actual user.
> > >
> > > kernel/sysctl.c has grown to an insane mess and its easy to run
> > > into conflicts with it. The effort to move them out is part of this.
> > >
> > > Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
> >
> > Daniel, let me know if this makes more sense now, and if so I can
> > offer take it through sysctl-next to avoid conflicts more sysctl knobs
> > get moved out from kernel/sysctl.c.
>
> If this is a whole ongoing effort rather than drive-by patch,
It is ongoing effort, but it will take many releases before we tidy
this whole thing up.
> then it's
> fine with me.
OK great. Thanks for understanding the mess.
> Btw, the patch itself should also drop the linux/bpf.h
> include from kernel/sysctl.c since nothing else is using it after the
> patch.
I'll let Yan deal with that.
> Btw, related to cleanups.. historically, we have a bunch of other knobs
> for BPF under net (in net_core_table), that is:
>
> /proc/sys/net/core/bpf_jit_enable
> /proc/sys/net/core/bpf_jit_harden
> /proc/sys/net/core/bpf_jit_kallsyms
> /proc/sys/net/core/bpf_jit_limit
>
> Would be nice to consolidate all under e.g. /proc/sys/kernel/bpf_* for
Oh the actual "name" / directory location is not changing.
What changes is just where in code you declare them.
> future going forward, and technically, they should be usable also w/o
> net configured into kernel.
That's up to you, and just consider if you have scrupts using these
already. You may need backward compatibility. You don't need networking
to create the net directory for sysctls too. The first sysctl to create
the directory creates it, if its not created, it will be created.
> Is there infra to point the sysctl knobs
> e.g. under net/core/ to kernel/, or best way would be to have single
> struct ctl_table and register for both?
Try proc_symlink().
Luis
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v3 sysctl-next] bpf: move bpf sysctls from kernel/sysctl.c to bpf module
2022-03-04 0:23 ` Luis Chamberlain
@ 2022-04-06 22:41 ` Luis Chamberlain
2022-04-07 7:07 ` [PATCH v4 " Yan Zhu
0 siblings, 1 reply; 21+ messages in thread
From: Luis Chamberlain @ 2022-04-06 22:41 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Yan Zhu, andrii, ast, bpf, john.fastabend, kafai, keescook,
kpsingh, linux-fsdevel, linux-kernel, liucheng32, netdev,
nixiaoming, songliubraving, xiechengliang1, yhs, yzaikin,
zengweilin
On Thu, Mar 03, 2022 at 04:23:26PM -0800, Luis Chamberlain wrote:
> On Fri, Mar 04, 2022 at 12:44:48AM +0100, Daniel Borkmann wrote:
> > On 3/2/22 9:39 PM, Luis Chamberlain wrote:
> > > On Wed, Mar 02, 2022 at 10:04:12AM +0800, Yan Zhu wrote:
> > > > We're moving sysctls out of kernel/sysctl.c as its a mess. We
> > > > already moved all filesystem sysctls out. And with time the goal is
> > > > to move all sysctls out to their own susbsystem/actual user.
> > > >
> > > > kernel/sysctl.c has grown to an insane mess and its easy to run
> > > > into conflicts with it. The effort to move them out is part of this.
> > > >
> > > > Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
> > >
> > > Daniel, let me know if this makes more sense now, and if so I can
> > > offer take it through sysctl-next to avoid conflicts more sysctl knobs
> > > get moved out from kernel/sysctl.c.
> >
> > If this is a whole ongoing effort rather than drive-by patch,
>
> It is ongoing effort, but it will take many releases before we tidy
> this whole thing up.
>
> > then it's
> > fine with me.
>
> OK great. Thanks for understanding the mess.
>
> > Btw, the patch itself should also drop the linux/bpf.h
> > include from kernel/sysctl.c since nothing else is using it after the
> > patch.
>
> I'll let Yan deal with that.
Yan, feel free to resubmit based on sysctl-next [0].
[0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=sysctl-next
Luis
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v4 sysctl-next] bpf: move bpf sysctls from kernel/sysctl.c to bpf module
2022-04-06 22:41 ` Luis Chamberlain
@ 2022-04-07 7:07 ` Yan Zhu
2022-04-13 14:45 ` Daniel Borkmann
0 siblings, 1 reply; 21+ messages in thread
From: Yan Zhu @ 2022-04-07 7:07 UTC (permalink / raw)
To: mcgrof
Cc: andrii, ast, bpf, daniel, john.fastabend, kafai, keescook,
kpsingh, linux-fsdevel, linux-kernel, liucheng32, netdev,
nixiaoming, songliubraving, xiechengliang1, yhs, yzaikin,
zengweilin, zhuyan34, leeyou.li, laiyuanyuan.lai
We're moving sysctls out of kernel/sysctl.c as its a mess. We
already moved all filesystem sysctls out. And with time the goal is
to move all sysctls out to their own subsystem/actual user.
kernel/sysctl.c has grown to an insane mess and its easy to run
into conflicts with it. The effort to move them out is part of this.
Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
---
v1->v2:
1.Added patch branch identifier sysctl-next.
2.Re-describe the reason for the patch submission.
v2->v3:
Re-describe the reason for the patch submission.
v3->v4:
1.Remove '#include <linux/bpf.h>' in kernel/sysctl.c
2.re-adaptive the patch
---
kernel/bpf/syscall.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++++
kernel/sysctl.c | 79 -----------------------------------------------
2 files changed, 87 insertions(+), 79 deletions(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index cdaa1152436a..e9621cfa09f2 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -4908,3 +4908,90 @@ const struct bpf_verifier_ops bpf_syscall_verifier_ops = {
const struct bpf_prog_ops bpf_syscall_prog_ops = {
.test_run = bpf_prog_test_run_syscall,
};
+
+#ifdef CONFIG_SYSCTL
+static int bpf_stats_handler(struct ctl_table *table, int write,
+ void *buffer, size_t *lenp, loff_t *ppos)
+{
+ struct static_key *key = (struct static_key *)table->data;
+ static int saved_val;
+ int val, ret;
+ struct ctl_table tmp = {
+ .data = &val,
+ .maxlen = sizeof(val),
+ .mode = table->mode,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = SYSCTL_ONE,
+ };
+
+ if (write && !capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ mutex_lock(&bpf_stats_enabled_mutex);
+ val = saved_val;
+ ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
+ if (write && !ret && val != saved_val) {
+ if (val)
+ static_key_slow_inc(key);
+ else
+ static_key_slow_dec(key);
+ saved_val = val;
+ }
+ mutex_unlock(&bpf_stats_enabled_mutex);
+ return ret;
+}
+
+void __weak unpriv_ebpf_notify(int new_state)
+{
+}
+
+static int bpf_unpriv_handler(struct ctl_table *table, int write,
+ void *buffer, size_t *lenp, loff_t *ppos)
+{
+ int ret, unpriv_enable = *(int *)table->data;
+ bool locked_state = unpriv_enable == 1;
+ struct ctl_table tmp = *table;
+
+ if (write && !capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ tmp.data = &unpriv_enable;
+ ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
+ if (write && !ret) {
+ if (locked_state && unpriv_enable != 1)
+ return -EPERM;
+ *(int *)table->data = unpriv_enable;
+ }
+
+ unpriv_ebpf_notify(unpriv_enable);
+
+ return ret;
+}
+
+static struct ctl_table bpf_syscall_table[] = {
+ {
+ .procname = "unprivileged_bpf_disabled",
+ .data = &sysctl_unprivileged_bpf_disabled,
+ .maxlen = sizeof(sysctl_unprivileged_bpf_disabled),
+ .mode = 0644,
+ .proc_handler = bpf_unpriv_handler,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = SYSCTL_TWO,
+ },
+ {
+ .procname = "bpf_stats_enabled",
+ .data = &bpf_stats_enabled_key.key,
+ .maxlen = sizeof(bpf_stats_enabled_key),
+ .mode = 0644,
+ .proc_handler = bpf_stats_handler,
+ },
+ { }
+};
+
+static int __init bpf_syscall_sysctl_init(void)
+{
+ register_sysctl_init("kernel", bpf_syscall_table);
+ return 0;
+}
+late_initcall(bpf_syscall_sysctl_init);
+#endif /* CONFIG_SYSCTL */
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 21172d3dad6e..c0fdf465a93d 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -62,7 +62,6 @@
#include <linux/binfmts.h>
#include <linux/sched/sysctl.h>
#include <linux/kexec.h>
-#include <linux/bpf.h>
#include <linux/mount.h>
#include <linux/userfaultfd_k.h>
#include <linux/latencytop.h>
@@ -139,66 +138,6 @@ static const int max_extfrag_threshold = 1000;
#endif /* CONFIG_SYSCTL */
-#if defined(CONFIG_BPF_SYSCALL) && defined(CONFIG_SYSCTL)
-static int bpf_stats_handler(struct ctl_table *table, int write,
- void *buffer, size_t *lenp, loff_t *ppos)
-{
- struct static_key *key = (struct static_key *)table->data;
- static int saved_val;
- int val, ret;
- struct ctl_table tmp = {
- .data = &val,
- .maxlen = sizeof(val),
- .mode = table->mode,
- .extra1 = SYSCTL_ZERO,
- .extra2 = SYSCTL_ONE,
- };
-
- if (write && !capable(CAP_SYS_ADMIN))
- return -EPERM;
-
- mutex_lock(&bpf_stats_enabled_mutex);
- val = saved_val;
- ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
- if (write && !ret && val != saved_val) {
- if (val)
- static_key_slow_inc(key);
- else
- static_key_slow_dec(key);
- saved_val = val;
- }
- mutex_unlock(&bpf_stats_enabled_mutex);
- return ret;
-}
-
-void __weak unpriv_ebpf_notify(int new_state)
-{
-}
-
-static int bpf_unpriv_handler(struct ctl_table *table, int write,
- void *buffer, size_t *lenp, loff_t *ppos)
-{
- int ret, unpriv_enable = *(int *)table->data;
- bool locked_state = unpriv_enable == 1;
- struct ctl_table tmp = *table;
-
- if (write && !capable(CAP_SYS_ADMIN))
- return -EPERM;
-
- tmp.data = &unpriv_enable;
- ret = proc_dointvec_minmax(&tmp, write, buffer, lenp, ppos);
- if (write && !ret) {
- if (locked_state && unpriv_enable != 1)
- return -EPERM;
- *(int *)table->data = unpriv_enable;
- }
-
- unpriv_ebpf_notify(unpriv_enable);
-
- return ret;
-}
-#endif /* CONFIG_BPF_SYSCALL && CONFIG_SYSCTL */
-
/*
* /proc/sys support
*/
@@ -2112,24 +2051,6 @@ static struct ctl_table kern_table[] = {
.extra2 = SYSCTL_ONE,
},
#endif
-#ifdef CONFIG_BPF_SYSCALL
- {
- .procname = "unprivileged_bpf_disabled",
- .data = &sysctl_unprivileged_bpf_disabled,
- .maxlen = sizeof(sysctl_unprivileged_bpf_disabled),
- .mode = 0644,
- .proc_handler = bpf_unpriv_handler,
- .extra1 = SYSCTL_ZERO,
- .extra2 = SYSCTL_TWO,
- },
- {
- .procname = "bpf_stats_enabled",
- .data = &bpf_stats_enabled_key.key,
- .maxlen = sizeof(bpf_stats_enabled_key),
- .mode = 0644,
- .proc_handler = bpf_stats_handler,
- },
-#endif
#if defined(CONFIG_TREE_RCU)
{
.procname = "panic_on_rcu_stall",
--
2.12.3
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH v4 sysctl-next] bpf: move bpf sysctls from kernel/sysctl.c to bpf module
2022-04-07 7:07 ` [PATCH v4 " Yan Zhu
@ 2022-04-13 14:45 ` Daniel Borkmann
2022-04-13 19:00 ` Luis Chamberlain
0 siblings, 1 reply; 21+ messages in thread
From: Daniel Borkmann @ 2022-04-13 14:45 UTC (permalink / raw)
To: Yan Zhu, mcgrof
Cc: andrii, ast, bpf, john.fastabend, kafai, keescook, kpsingh,
linux-fsdevel, linux-kernel, liucheng32, netdev, nixiaoming,
songliubraving, xiechengliang1, yhs, yzaikin, zengweilin,
leeyou.li, laiyuanyuan.lai
On 4/7/22 9:07 AM, Yan Zhu wrote:
> We're moving sysctls out of kernel/sysctl.c as its a mess. We
> already moved all filesystem sysctls out. And with time the goal is
> to move all sysctls out to their own subsystem/actual user.
>
> kernel/sysctl.c has grown to an insane mess and its easy to run
> into conflicts with it. The effort to move them out is part of this.
>
> Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Given the desire is to route this via sysctl-next and we're not shortly
before but after the merge win, could we get a feature branch for bpf-next
to pull from to avoid conflicts with ongoing development cycle?
Thanks,
Daniel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v4 sysctl-next] bpf: move bpf sysctls from kernel/sysctl.c to bpf module
2022-04-13 14:45 ` Daniel Borkmann
@ 2022-04-13 19:00 ` Luis Chamberlain
2022-04-13 19:40 ` Daniel Borkmann
0 siblings, 1 reply; 21+ messages in thread
From: Luis Chamberlain @ 2022-04-13 19:00 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Yan Zhu, andrii, ast, bpf, john.fastabend, kafai, keescook,
kpsingh, linux-fsdevel, linux-kernel, liucheng32, netdev,
nixiaoming, songliubraving, xiechengliang1, yhs, yzaikin,
zengweilin, leeyou.li, laiyuanyuan.lai
On Wed, Apr 13, 2022 at 04:45:00PM +0200, Daniel Borkmann wrote:
> On 4/7/22 9:07 AM, Yan Zhu wrote:
> > We're moving sysctls out of kernel/sysctl.c as its a mess. We
> > already moved all filesystem sysctls out. And with time the goal is
> > to move all sysctls out to their own subsystem/actual user.
> >
> > kernel/sysctl.c has grown to an insane mess and its easy to run
> > into conflicts with it. The effort to move them out is part of this.
> >
> > Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
>
> Given the desire is to route this via sysctl-next and we're not shortly
> before but after the merge win, could we get a feature branch for bpf-next
> to pull from to avoid conflicts with ongoing development cycle?
Sure thing. So I've never done this sort of thing, so forgive me for
being new at it. Would it make sense to merge this change to sysctl-next
as-is today and put a frozen branch sysclt-next-bpf to reflect this,
which bpf-next can merge. And then sysctl-next just continues to chug on
its own? As-is my goal is to keep sysctl-next as immutable as well.
Or is there a better approach you can recommend?
Luis
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v4 sysctl-next] bpf: move bpf sysctls from kernel/sysctl.c to bpf module
2022-04-13 19:00 ` Luis Chamberlain
@ 2022-04-13 19:40 ` Daniel Borkmann
2022-04-13 19:46 ` Luis Chamberlain
0 siblings, 1 reply; 21+ messages in thread
From: Daniel Borkmann @ 2022-04-13 19:40 UTC (permalink / raw)
To: Luis Chamberlain
Cc: Yan Zhu, andrii, ast, bpf, john.fastabend, kafai, keescook,
kpsingh, linux-fsdevel, linux-kernel, liucheng32, netdev,
nixiaoming, songliubraving, xiechengliang1, yhs, yzaikin,
zengweilin, leeyou.li, laiyuanyuan.lai
On 4/13/22 9:00 PM, Luis Chamberlain wrote:
> On Wed, Apr 13, 2022 at 04:45:00PM +0200, Daniel Borkmann wrote:
>> On 4/7/22 9:07 AM, Yan Zhu wrote:
>>> We're moving sysctls out of kernel/sysctl.c as its a mess. We
>>> already moved all filesystem sysctls out. And with time the goal is
>>> to move all sysctls out to their own subsystem/actual user.
>>>
>>> kernel/sysctl.c has grown to an insane mess and its easy to run
>>> into conflicts with it. The effort to move them out is part of this.
>>>
>>> Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
>>
>> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
>>
>> Given the desire is to route this via sysctl-next and we're not shortly
>> before but after the merge win, could we get a feature branch for bpf-next
>> to pull from to avoid conflicts with ongoing development cycle?
>
> Sure thing. So I've never done this sort of thing, so forgive me for
> being new at it. Would it make sense to merge this change to sysctl-next
> as-is today and put a frozen branch sysclt-next-bpf to reflect this,
> which bpf-next can merge. And then sysctl-next just continues to chug on
> its own? As-is my goal is to keep sysctl-next as immutable as well.
>
> Or is there a better approach you can recommend?
Are you able to merge the pr/bpf-sysctl branch into your sysctl-next tree?
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/log/?h=pr/bpf-sysctl
This is based off common base for both trees (3123109284176b1532874591f7c81f3837bbdc17)
so should only pull in the single commit then.
Thanks,
Daniel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v4 sysctl-next] bpf: move bpf sysctls from kernel/sysctl.c to bpf module
2022-04-13 19:40 ` Daniel Borkmann
@ 2022-04-13 19:46 ` Luis Chamberlain
2022-04-13 19:50 ` Daniel Borkmann
0 siblings, 1 reply; 21+ messages in thread
From: Luis Chamberlain @ 2022-04-13 19:46 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Yan Zhu, andrii, ast, bpf, john.fastabend, kafai, keescook,
kpsingh, linux-fsdevel, linux-kernel, liucheng32, netdev,
nixiaoming, songliubraving, xiechengliang1, yhs, yzaikin,
zengweilin, leeyou.li, laiyuanyuan.lai
On Wed, Apr 13, 2022 at 09:40:58PM +0200, Daniel Borkmann wrote:
> On 4/13/22 9:00 PM, Luis Chamberlain wrote:
> > On Wed, Apr 13, 2022 at 04:45:00PM +0200, Daniel Borkmann wrote:
> > > On 4/7/22 9:07 AM, Yan Zhu wrote:
> > > > We're moving sysctls out of kernel/sysctl.c as its a mess. We
> > > > already moved all filesystem sysctls out. And with time the goal is
> > > > to move all sysctls out to their own subsystem/actual user.
> > > >
> > > > kernel/sysctl.c has grown to an insane mess and its easy to run
> > > > into conflicts with it. The effort to move them out is part of this.
> > > >
> > > > Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
> > >
> > > Acked-by: Daniel Borkmann <daniel@iogearbox.net>
> > >
> > > Given the desire is to route this via sysctl-next and we're not shortly
> > > before but after the merge win, could we get a feature branch for bpf-next
> > > to pull from to avoid conflicts with ongoing development cycle?
> >
> > Sure thing. So I've never done this sort of thing, so forgive me for
> > being new at it. Would it make sense to merge this change to sysctl-next
> > as-is today and put a frozen branch sysclt-next-bpf to reflect this,
> > which bpf-next can merge. And then sysctl-next just continues to chug on
> > its own? As-is my goal is to keep sysctl-next as immutable as well.
> >
> > Or is there a better approach you can recommend?
>
> Are you able to merge the pr/bpf-sysctl branch into your sysctl-next tree?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/log/?h=pr/bpf-sysctl
>
> This is based off common base for both trees (3123109284176b1532874591f7c81f3837bbdc17)
> so should only pull in the single commit then.
Yup. That worked just fine. I pushed it.
Luis
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v4 sysctl-next] bpf: move bpf sysctls from kernel/sysctl.c to bpf module
2022-04-13 19:46 ` Luis Chamberlain
@ 2022-04-13 19:50 ` Daniel Borkmann
0 siblings, 0 replies; 21+ messages in thread
From: Daniel Borkmann @ 2022-04-13 19:50 UTC (permalink / raw)
To: Luis Chamberlain
Cc: Yan Zhu, andrii, ast, bpf, john.fastabend, kafai, keescook,
kpsingh, linux-fsdevel, linux-kernel, liucheng32, netdev,
nixiaoming, songliubraving, xiechengliang1, yhs, yzaikin,
zengweilin, leeyou.li, laiyuanyuan.lai
On 4/13/22 9:46 PM, Luis Chamberlain wrote:
> On Wed, Apr 13, 2022 at 09:40:58PM +0200, Daniel Borkmann wrote:
>> On 4/13/22 9:00 PM, Luis Chamberlain wrote:
>>> On Wed, Apr 13, 2022 at 04:45:00PM +0200, Daniel Borkmann wrote:
>>>> On 4/7/22 9:07 AM, Yan Zhu wrote:
>>>>> We're moving sysctls out of kernel/sysctl.c as its a mess. We
>>>>> already moved all filesystem sysctls out. And with time the goal is
>>>>> to move all sysctls out to their own subsystem/actual user.
>>>>>
>>>>> kernel/sysctl.c has grown to an insane mess and its easy to run
>>>>> into conflicts with it. The effort to move them out is part of this.
>>>>>
>>>>> Signed-off-by: Yan Zhu <zhuyan34@huawei.com>
>>>>
>>>> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
>>>>
>>>> Given the desire is to route this via sysctl-next and we're not shortly
>>>> before but after the merge win, could we get a feature branch for bpf-next
>>>> to pull from to avoid conflicts with ongoing development cycle?
>>>
>>> Sure thing. So I've never done this sort of thing, so forgive me for
>>> being new at it. Would it make sense to merge this change to sysctl-next
>>> as-is today and put a frozen branch sysclt-next-bpf to reflect this,
>>> which bpf-next can merge. And then sysctl-next just continues to chug on
>>> its own? As-is my goal is to keep sysctl-next as immutable as well.
>>>
>>> Or is there a better approach you can recommend?
>>
>> Are you able to merge the pr/bpf-sysctl branch into your sysctl-next tree?
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/log/?h=pr/bpf-sysctl
>>
>> This is based off common base for both trees (3123109284176b1532874591f7c81f3837bbdc17)
>> so should only pull in the single commit then.
>
> Yup. That worked just fine. I pushed it.
Great, thanks!
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] bpf: move the bpf syscall sysctl table to its own module
@ 2022-02-23 2:24 zhuyan (M)
0 siblings, 0 replies; 21+ messages in thread
From: zhuyan (M) @ 2022-02-23 2:24 UTC (permalink / raw)
To: Luis Chamberlain
Cc: ast, daniel, andrii, kafai, songliubraving, yhs, john.fastabend,
kpsingh, keescook, yzaikin, netdev, bpf, linux-kernel,
linux-fsdevel, Zengweilin, liucheng (G),
Nixiaoming, xiechengliang
On Wed, Feb 23, 2022 at 09:42:00AM +0800, Luis Chamberlain wrote:
> On Wed, Feb 23, 2022 at 09:35:29AM +0800, Yan Zhu wrote:
> > Sysctl table is easier to read under its own module.
>
> Hey Yan, thanks for you patch!
>
> This does not explain how this is being to help with maitenance as otherwise this makes
> kernel/sysctl.c hard to maintain and we also tend to get many conflicts. It also does not
> explain how all the filesystem sysctls are not gone and that this is just the next step,
> moving slowly the rest of the sysctls. Explaining this in the commit log will help patch
> review and subsystem maintainers understand the conext / logic behind the move.
>
> I'd be more than happy to take this if bpf folks Ack. To avoid conflicts I can route this
> through sysctl-next which is put forward in particular to avoid conflicts across trees for
> this effort. Let me know.
Thank you for your reply.
My patch is based on sysctl-next, sorry I forgot to identify it as a patch from the
sysctl-next branch. I will send the v2 patch later.
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2022-04-13 20:07 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-23 1:35 [PATCH] bpf: move the bpf syscall sysctl table to its own module Yan Zhu
2022-02-23 1:42 ` Luis Chamberlain
2022-02-23 10:28 ` [PATCH v2 sysctl-next] bpf: move the bpf syscall sysctl table to bpf module Yan Zhu
2022-02-28 15:53 ` Daniel Borkmann
2022-02-28 23:41 ` Luis Chamberlain
2022-03-02 1:58 ` Yan Zhu
2022-03-02 2:04 ` [PATCH v3 sysctl-next] bpf: move bpf sysctls from kernel/sysctl.c " Yan Zhu
2022-03-02 20:39 ` Luis Chamberlain
2022-03-03 23:44 ` Daniel Borkmann
2022-03-04 0:23 ` Luis Chamberlain
2022-04-06 22:41 ` Luis Chamberlain
2022-04-07 7:07 ` [PATCH v4 " Yan Zhu
2022-04-13 14:45 ` Daniel Borkmann
2022-04-13 19:00 ` Luis Chamberlain
2022-04-13 19:40 ` Daniel Borkmann
2022-04-13 19:46 ` Luis Chamberlain
2022-04-13 19:50 ` Daniel Borkmann
2022-02-23 4:28 ` [PATCH] bpf: move the bpf syscall sysctl table to its own module Matthew Wilcox
2022-02-23 5:06 ` Alexei Starovoitov
2022-02-23 9:50 ` Yan Zhu
2022-02-23 2:24 zhuyan (M)
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.