* [PATCH] devtmpfs: move NULLing the thread pointer before unregistering fs
@ 2022-12-02 12:45 Alexander Atanasov
2022-12-02 15:56 ` Greg Kroah-Hartman
0 siblings, 1 reply; 3+ messages in thread
From: Alexander Atanasov @ 2022-12-02 12:45 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki
Cc: kernel, Alexander Atanasov, linux-kernel
In commit
31c779f293b3 ("devtmpfs: fix the dangling pointer of global devtmpfsd thread")
a dangling pointer on an error condition was fixed. But the fix
left the dangling pointer during unregister_filesystem and printk calls.
Improve the fix to clear the pointer before unregistration to close
the window where the dangling pointer can be potentially used.
Make it clear the pointer at only one place in the function.
Signed-off-by: Alexander Atanasov <alexander.atanasov@virtuozzo.com>
---
drivers/base/devtmpfs.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c
index e4bffeabf344..773e66ef5642 100644
--- a/drivers/base/devtmpfs.c
+++ b/drivers/base/devtmpfs.c
@@ -472,17 +472,15 @@ int __init devtmpfs_init(void)
}
thread = kthread_run(devtmpfsd, &err, "kdevtmpfs");
- if (!IS_ERR(thread)) {
+ if (!IS_ERR(thread))
wait_for_completion(&setup_done);
- } else {
+ else
err = PTR_ERR(thread);
- thread = NULL;
- }
if (err) {
+ thread = NULL;
printk(KERN_ERR "devtmpfs: unable to create devtmpfs %i\n", err);
unregister_filesystem(&dev_fs_type);
- thread = NULL;
return err;
}
base-commit: b7b275e60bcd5f89771e865a8239325f86d9927d
--
2.31.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] devtmpfs: move NULLing the thread pointer before unregistering fs
2022-12-02 12:45 [PATCH] devtmpfs: move NULLing the thread pointer before unregistering fs Alexander Atanasov
@ 2022-12-02 15:56 ` Greg Kroah-Hartman
2022-12-02 19:49 ` Alexander Atanasov
0 siblings, 1 reply; 3+ messages in thread
From: Greg Kroah-Hartman @ 2022-12-02 15:56 UTC (permalink / raw)
To: Alexander Atanasov; +Cc: Rafael J. Wysocki, kernel, linux-kernel
On Fri, Dec 02, 2022 at 02:45:01PM +0200, Alexander Atanasov wrote:
> In commit
> 31c779f293b3 ("devtmpfs: fix the dangling pointer of global devtmpfsd thread")
> a dangling pointer on an error condition was fixed. But the fix
> left the dangling pointer during unregister_filesystem and printk calls.
And how could it be used there?
> Improve the fix to clear the pointer before unregistration to close
> the window where the dangling pointer can be potentially used.
Again, how can that happen? And you have an extra ' ' in that line :(
> Make it clear the pointer at only one place in the function.
>
> Signed-off-by: Alexander Atanasov <alexander.atanasov@virtuozzo.com>
> ---
> drivers/base/devtmpfs.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c
> index e4bffeabf344..773e66ef5642 100644
> --- a/drivers/base/devtmpfs.c
> +++ b/drivers/base/devtmpfs.c
> @@ -472,17 +472,15 @@ int __init devtmpfs_init(void)
> }
>
> thread = kthread_run(devtmpfsd, &err, "kdevtmpfs");
> - if (!IS_ERR(thread)) {
> + if (!IS_ERR(thread))
> wait_for_completion(&setup_done);
> - } else {
> + else
> err = PTR_ERR(thread);
> - thread = NULL;
> - }
>
> if (err) {
> + thread = NULL;
> printk(KERN_ERR "devtmpfs: unable to create devtmpfs %i\n", err);
> unregister_filesystem(&dev_fs_type);
> - thread = NULL;
> return err;
> }
This all feels wrong and way too complex to have to clean up from a call
to kthread_run(). Are you sure this is the correct way to do this?
And how was this "issue" found? How does the call to kthread_run() ever
fail for you?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] devtmpfs: move NULLing the thread pointer before unregistering fs
2022-12-02 15:56 ` Greg Kroah-Hartman
@ 2022-12-02 19:49 ` Alexander Atanasov
0 siblings, 0 replies; 3+ messages in thread
From: Alexander Atanasov @ 2022-12-02 19:49 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Rafael J. Wysocki, kernel, linux-kernel
On 2.12.22 17:56, Greg Kroah-Hartman wrote:
> On Fri, Dec 02, 2022 at 02:45:01PM +0200, Alexander Atanasov wrote:
>> In commit
>> 31c779f293b3 ("devtmpfs: fix the dangling pointer of global devtmpfsd thread")
>> a dangling pointer on an error condition was fixed. But the fix
>> left the dangling pointer during unregister_filesystem and printk calls.
>
> And how could it be used there?
I don't said it can be used there - they might trigger events that get
back to it.
>
>> Improve the fix to clear the pointer before unregistration to close
>> the window where the dangling pointer can be potentially used.
>
> Again, how can that happen? And you have an extra ' ' in that line :(
Sorry for the extra ' ' i will check where it came from.
>
>> Make it clear the pointer at only one place in the function.
>>
>> Signed-off-by: Alexander Atanasov <alexander.atanasov@virtuozzo.com>
>> ---
>> drivers/base/devtmpfs.c | 8 +++-----
>> 1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c
>> index e4bffeabf344..773e66ef5642 100644
>> --- a/drivers/base/devtmpfs.c
>> +++ b/drivers/base/devtmpfs.c
>> @@ -472,17 +472,15 @@ int __init devtmpfs_init(void)
>> }
>>
>> thread = kthread_run(devtmpfsd, &err, "kdevtmpfs");
>> - if (!IS_ERR(thread)) {
>> + if (!IS_ERR(thread))
>> wait_for_completion(&setup_done);
>> - } else {
>> + else
>> err = PTR_ERR(thread);
>> - thread = NULL;
>> - }
>>
>> if (err) {
>> + thread = NULL;
>> printk(KERN_ERR "devtmpfs: unable to create devtmpfs %i\n", err);
>> unregister_filesystem(&dev_fs_type);
>> - thread = NULL;
>> return err;
>> }
>
> This all feels wrong and way too complex to have to clean up from a call
> to kthread_run(). Are you sure this is the correct way to do this?
Agree on this but this is the code as it is.
> And how was this "issue" found? How does the call to kthread_run() ever
> fail for you?
I was after something else and this stuck into my eye:
....
thread = kthread_run(devtmpfsd, &err, "kdevtmpfs");
if (!IS_ERR(thread)) {
wait_for_completion(&setup_done);
} else {
err = PTR_ERR(thread);
thread = NULL;
}
if (err) {
printk(KERN_ERR "devtmpfs: unable to create devtmpfs
%i\n", err);
unregister_filesystem(&dev_fs_type);
thread = NULL;
return err;
}
....
Why do we do thread = NULL twice ? One time before unregistration, one
time after unregistration.
So if it is going to handle the error the same way as the kthread_run
error (original) then when the thread completes with error we must do
the same. And do it one time.
...
thread = kthread_run(devtmpfsd, &err, "kdevtmpfs");
if (!IS_ERR(thread))
wait_for_completion(&setup_done);
else
err = PTR_ERR(thread);
if (err) {
thread = NULL;
printk(KERN_ERR "devtmpfs: unable to create devtmpfs
%i\n", err);
unregister_filesystem(&dev_fs_type);
return err;
}
...
Which is more readable ?
I guess I should have put this as the commit message.
--
Regards,
Alexander Atanasov
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-12-02 19:49 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-02 12:45 [PATCH] devtmpfs: move NULLing the thread pointer before unregistering fs Alexander Atanasov
2022-12-02 15:56 ` Greg Kroah-Hartman
2022-12-02 19:49 ` Alexander Atanasov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).