[PATCH] export kernel call set_task_comm()

[PATCH] export kernel call set_task_comm()

[majianpeng]

In Commit 7d74f492e4dd0034a61458eb80f70b1d2862ed07,author said:
"This allows drivers who call this function to be compiled modularly.
Otherwise, a driver who is interested in this type of functionality
has to implement their own get_task_comm() call, causing code
duplication in the Linux source tree."

But author did not say about set_task_comm().At present,I used it but
compiled error.To the same purpose, it should export.

Signed-off-by: majianpeng <majianpeng@gmail.com>
---
 fs/exec.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index 52c9e2f..2b0178b 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1072,6 +1072,7 @@ void set_task_comm(struct task_struct *tsk, char *buf)
 	task_unlock(tsk);
 	perf_event_comm(tsk);
 }
+EXPORT_SYMBOL_GPL(set_task_comm);
 
 static void filename_to_taskname(char *tcomm, const char *fn, unsigned int len)
 {
-- 
1.7.5.4

 				
--------------
majianpeng
2012-05-31

Re: [PATCH] export kernel call set_task_comm()

[Al Viro]

On Thu, May 31, 2012 at 03:16:18PM +0800, majianpeng wrote:
> In Commit 7d74f492e4dd0034a61458eb80f70b1d2862ed07,author said:
> "This allows drivers who call this function to be compiled modularly.
> Otherwise, a driver who is interested in this type of functionality
> has to implement their own get_task_comm() call, causing code
> duplication in the Linux source tree."
> 
> But author did not say about set_task_comm().At present,I used it but
> compiled error.To the same purpose, it should export.

Are you doing that to preexisting process?  Or just to a kernel thread
you are creating?  In the latter case, you really ought to use
kthread_create() instead of bare-metal kernel_thread()...

Re: Re: [PATCH] export kernel call set_task_comm()

[majianpeng]

On Thu, 31 May 2012 17:00:54 +0100 , viro wrote:
>On Thu, May 31, 2012 at 03:16:18PM +0800, majianpeng wrote:
>> In Commit 7d74f492e4dd0034a61458eb80f70b1d2862ed07,author said:
>> "This allows drivers who call this function to be compiled modularly.
>> Otherwise, a driver who is interested in this type of functionality
>> has to implement their own get_task_comm() call, causing code
>> duplication in the Linux source tree."
>> 
>> But author did not say about set_task_comm().At present,I used it but
>> compiled error.To the same purpose, it should export.

>Are you doing that to preexisting process?  Or just to a kernel thread
>you are creating?  In the latter case, you really ought to use
>kthread_create() instead of bare-metal kernel_thread()...

Yes, I am doing that to preexisting process and in module.So I think it should export.

------------------				 
majianpeng
2012-06-01

Re: Re: [PATCH] export kernel call set_task_comm()

[Al Viro]

On Fri, Jun 01, 2012 at 09:11:32AM +0800, majianpeng wrote:
> On Thu, 31 May 2012 17:00:54 +0100 , viro wrote:
> >On Thu, May 31, 2012 at 03:16:18PM +0800, majianpeng wrote:
> >> In Commit 7d74f492e4dd0034a61458eb80f70b1d2862ed07,author said:
> >> "This allows drivers who call this function to be compiled modularly.
> >> Otherwise, a driver who is interested in this type of functionality
> >> has to implement their own get_task_comm() call, causing code
> >> duplication in the Linux source tree."
> >> 
> >> But author did not say about set_task_comm().At present,I used it but
> >> compiled error.To the same purpose, it should export.
> 
> >Are you doing that to preexisting process?  Or just to a kernel thread
> >you are creating?  In the latter case, you really ought to use
> >kthread_create() instead of bare-metal kernel_thread()...
> 
> Yes, I am doing that to preexisting process and in module.So I think it should export.

Why is that module playing with ->comm[] of process it hadn't spawned?
Note that _reading_ ->comm[] has fairly mundane uses - debugging printks
and all such.   Changing it, OTOH...

Details, please; "my module calls that, so it should be exported" is not enough.

Re: Re: [PATCH] export kernel call set_task_comm()

[majianpeng]

On Thu, 31 May 2012 18:24:47 -0700, viro wrote:
>On Fri, Jun 01, 2012 at 09:11:32AM +0800, majianpeng wrote:
>> On Thu, 31 May 2012 17:00:54 +0100 , viro wrote:
>> >On Thu, May 31, 2012 at 03:16:18PM +0800, majianpeng wrote:
>> >> In Commit 7d74f492e4dd0034a61458eb80f70b1d2862ed07,author said:
>> >> "This allows drivers who call this function to be compiled modularly.
>> >> Otherwise, a driver who is interested in this type of functionality
>> >> has to implement their own get_task_comm() call, causing code
>> >> duplication in the Linux source tree."
>> >> 
>> >> But author did not say about set_task_comm().At present,I used it but
>> >> compiled error.To the same purpose, it should export.
>> 
>> >Are you doing that to preexisting process?  Or just to a kernel thread
>> >you are creating?  In the latter case, you really ought to use
>> >kthread_create() instead of bare-metal kernel_thread()...
>> 
>> Yes, I am doing that to preexisting process and in module.So I think it should export.
>
>Why is that module playing with ->comm[] of process it hadn't spawned?
>Note that _reading_ ->comm[] has fairly mundane uses - debugging printks
>and all such.   Changing it, OTOH...
>
>Details, please; "my module calls that, so it should be exported" is not enough.
This module is md.
It created a thread with kthread_run.But the name is wrong because using some old information.
Because it has mode places like this, so I thought to change the name at run-place .
If so, I can modify the ->comm[] directly?


--------------
majianpeng