kernel/hung_task.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
The proc_dohung_task_timeout_secs() function is incorrectly marked
as having a __user buffer as argument 3. However this is not the
case and it is casing multiple sparse warnings. Fix the following
warnings by removing __user from the argument:
kernel/hung_task.c:237:52: warning: incorrect type in argument 3 (different address spaces)
kernel/hung_task.c:237:52: expected void *
kernel/hung_task.c:237:52: got void [noderef] __user *buffer
kernel/hung_task.c:287:35: warning: incorrect type in initializer (incompatible argument 3 (different address spaces))
kernel/hung_task.c:287:35: expected int ( [usertype] *proc_handler )( ... )
kernel/hung_task.c:287:35: got int ( * )( ... )
kernel/hung_task.c:295:35: warning: incorrect type in initializer (incompatible argument 3 (different address spaces))
kernel/hung_task.c:295:35: expected int ( [usertype] *proc_handler )( ... )
kernel/hung_task.c:295:35: got int ( * )( ... )
Signed-off-by: Ben Dooks <ben.dooks@sifive.com>
---
kernel/hung_task.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/hung_task.c b/kernel/hung_task.c
index cff3ae8c818f..bb2354f73ded 100644
--- a/kernel/hung_task.c
+++ b/kernel/hung_task.c
@@ -229,7 +229,7 @@ static long hung_timeout_jiffies(unsigned long last_checked,
* Process updating of timeout sysctl
*/
static int proc_dohung_task_timeout_secs(struct ctl_table *table, int write,
- void __user *buffer,
+ void *buffer,
size_t *lenp, loff_t *ppos)
{
int ret;
--
2.35.1
On 14/07/2022 08:47, Ben Dooks wrote:
Hey Ben,
Odd CC list here? I assume you're piping get_maintainer into
send-email or something, but idk who is going to see or apply
this patch! Ditto your other one for this file.
Might be worth adding some of what get_maintainer spits out:
Petr Mladek <pmladek@suse.com> (commit_signer:4/4=100%,authored:1/4=25%,removed_lines:10/15=67%)
Andrew Morton <akpm@linux-foundation.org> (commit_signer:2/4=50%)
Rasmus Villemoes <linux@rasmusvillemoes.dk> (commit_signer:1/4=25%,authored:1/4=25%,removed_lines:1/15=7%)
John Ogness <john.ogness@linutronix.de> (commit_signer:1/4=25%,authored:1/4=25%,added_lines:10/90=11%,removed_lines:1/15=7%)
Kees Cook <keescook@chromium.org> (commit_signer:1/4=25%)
Xiaoming Ni <nixiaoming@huawei.com> (authored:1/4=25%,added_lines:78/90=87%,removed_lines:3/15=20%)
Thanks,
Conor.
> The proc_dohung_task_timeout_secs() function is incorrectly marked
> as having a __user buffer as argument 3. However this is not the
> case and it is casing multiple sparse warnings. Fix the following
> warnings by removing __user from the argument:
>
> kernel/hung_task.c:237:52: warning: incorrect type in argument 3 (different address spaces)
> kernel/hung_task.c:237:52: expected void *
> kernel/hung_task.c:237:52: got void [noderef] __user *buffer
> kernel/hung_task.c:287:35: warning: incorrect type in initializer (incompatible argument 3 (different address spaces))
> kernel/hung_task.c:287:35: expected int ( [usertype] *proc_handler )( ... )
> kernel/hung_task.c:287:35: got int ( * )( ... )
> kernel/hung_task.c:295:35: warning: incorrect type in initializer (incompatible argument 3 (different address spaces))
> kernel/hung_task.c:295:35: expected int ( [usertype] *proc_handler )( ... )
> kernel/hung_task.c:295:35: got int ( * )( ... )
>
> Signed-off-by: Ben Dooks <ben.dooks@sifive.com>
> ---
> kernel/hung_task.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/hung_task.c b/kernel/hung_task.c
> index cff3ae8c818f..bb2354f73ded 100644
> --- a/kernel/hung_task.c
> +++ b/kernel/hung_task.c
> @@ -229,7 +229,7 @@ static long hung_timeout_jiffies(unsigned long last_checked,
> * Process updating of timeout sysctl
> */
> static int proc_dohung_task_timeout_secs(struct ctl_table *table, int write,
> - void __user *buffer,
> + void *buffer,
> size_t *lenp, loff_t *ppos)
> {
> int ret;
On 14/07/2022 09:10, Conor.Dooley@microchip.com wrote: > On 14/07/2022 08:47, Ben Dooks wrote: > > Hey Ben, > Odd CC list here? I assume you're piping get_maintainer into > send-email or something, but idk who is going to see or apply > this patch! Ditto your other one for this file. Since (see below) the script wasn't clear I just cc our management. > > Might be worth adding some of what get_maintainer spits out: > Petr Mladek <pmladek@suse.com> (commit_signer:4/4=100%,authored:1/4=25%,removed_lines:10/15=67%) > Andrew Morton <akpm@linux-foundation.org> (commit_signer:2/4=50%) > Rasmus Villemoes <linux@rasmusvillemoes.dk> (commit_signer:1/4=25%,authored:1/4=25%,removed_lines:1/15=7%) > John Ogness <john.ogness@linutronix.de> (commit_signer:1/4=25%,authored:1/4=25%,added_lines:10/90=11%,removed_lines:1/15=7%) > Kees Cook <keescook@chromium.org> (commit_signer:1/4=25%) > Xiaoming Ni <nixiaoming@huawei.com> (authored:1/4=25%,added_lines:78/90=87%,removed_lines:3/15=20%) I think only akpm would be one of those, given no overall maintainer I had a look and just use the kernel list and hope someone picks it up.
On 14/07/2022 09:20, Ben Dooks wrote: > On 14/07/2022 09:10, Conor.Dooley@microchip.com wrote: >> On 14/07/2022 08:47, Ben Dooks wrote: >> >> Hey Ben, >> Odd CC list here? I assume you're piping get_maintainer into >> send-email or something, but idk who is going to see or apply >> this patch! Ditto your other one for this file. > > Since (see below) the script wasn't clear I just cc our management. > >> >> Might be worth adding some of what get_maintainer spits out: >> Petr Mladek <pmladek@suse.com> (commit_signer:4/4=100%,authored:1/4=25%,removed_lines:10/15=67%) >> Andrew Morton <akpm@linux-foundation.org> (commit_signer:2/4=50%) >> Rasmus Villemoes <linux@rasmusvillemoes.dk> (commit_signer:1/4=25%,authored:1/4=25%,removed_lines:1/15=7%) >> John Ogness <john.ogness@linutronix.de> (commit_signer:1/4=25%,authored:1/4=25%,added_lines:10/90=11%,removed_lines:1/15=7%) >> Kees Cook <keescook@chromium.org> (commit_signer:1/4=25%) >> Xiaoming Ni <nixiaoming@huawei.com> (authored:1/4=25%,added_lines:78/90=87%,removed_lines:3/15=20%) > > I think only akpm would be one of those, given no overall > maintainer I had a look and just use the kernel list and > hope someone picks it up. Yeah, adding Andrew would be a good option. And I guess kernel-janitors?
© 2016 - 2026 Red Hat, Inc.