linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [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).