Hey guys, I have a module which defines a specific print function, and another module that uses said function. From the first module I have used EXPORT_SYMBOL(function_1). From within the second module I would like to rebind that function to another printing function, and once I'm finished, rebind it back to the original function. So in theory the pseudo-code would look something like this module_1.c function_1() { do some stuff } my_print_function = function_1 EXPORT_SYMBOL(my_print_function) module_2.c function_t() { doing different stuff } placeholder = my_print_function my_print_fuction = function_2 <do some other stuff> my_print_function = placeholder <END OF CODE> My question is: Is this the correct way of doing this? Or will this cause issues?
On Mon, Jun 02, 2014 at 08:29:16PM -0700, Peter Tosh wrote:
Hey guys,
I have a module which defines a specific print function, and another module that uses said function. From the first module I have used EXPORT_SYMBOL(function_1). From within the second module I would like to rebind that function to another printing function, and once I'm finished, rebind it back to the original function.
Wait, why? Don't have modules messing with the function pointers of other modules, that way lies madness. Or root kits, which honestly, there are better ways of making money if you have Linux kernel skills. don't do this. greg k-h
Is this just a horrible idea in general? Can you give some kind of general explanation? On Mon, 2014-06-02 at 20:57 -0700, Greg KH wrote:
On Mon, Jun 02, 2014 at 08:29:16PM -0700, Peter Tosh wrote:
Hey guys,
I have a module which defines a specific print function, and another module that uses said function. From the first module I have used EXPORT_SYMBOL(function_1). From within the second module I would like to rebind that function to another printing function, and once I'm finished, rebind it back to the original function.
Wait, why?
Don't have modules messing with the function pointers of other modules, that way lies madness.
Or root kits, which honestly, there are better ways of making money if you have Linux kernel skills.
don't do this.
greg k-h
On Mon, Jun 02, 2014 at 09:19:41PM -0700, Peter Tosh wrote:
Is this just a horrible idea in general? Can you give some kind of general explanation?
Messing with symbol address is a horrible idea in general. Step back, what problem are you trying to solve that ended up with this type of proposed solution? thanks, greg k-h
It's currently being done in a user space application which I am porting to a kernel module. Is there some other way of accomplishing the same thing safely? On Mon, 2014-06-02 at 21:47 -0700, Greg KH wrote:
On Mon, Jun 02, 2014 at 09:19:41PM -0700, Peter Tosh wrote:
Is this just a horrible idea in general? Can you give some kind of general explanation?
Messing with symbol address is a horrible idea in general.
Step back, what problem are you trying to solve that ended up with this type of proposed solution?
thanks,
greg k-h
A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Mon, Jun 02, 2014 at 10:10:16PM -0700, Peter Tosh wrote:
It's currently being done in a user space application which I am porting to a kernel module. Is there some other way of accomplishing the same thing safely?
Again, what is such a thing being done _for_? Why are they doing this? And why would a userspace program need to be ported to the kernel? What type of application is this? What does it do? Any pointers to the source to take a look at it? thanks, greg k-h
Hi Peter, I can think of two simple ways of achieving the same without messing up with exported symbols. 1. If your intention is to use a common api to call function_1/my_print_function and function_2, then use a common placeholder. Assign it to function_1/my_print_function. Use the placeholder to call function_1/my_print_function. Reassign placeholder to function_2. Use placeholder to call function_2. 2. A neater way would be to directly call function_1/my_print_function and function_2. This would reduce complexities. About your code, I am not sure if you were able to compile the code successfully because "my_print_fuction = function_2" is a potential compilation error. Even if compilation succeeds, the risk is any thread executing simultaneously and using my_print_function (exported symbol) might experience a weird behavior when it's definition is dynamically changed by a different thread. Hope this helps, lest I confused you. Regards, Ayan Kumar Halder On Tue, Jun 3, 2014 at 10:51 AM, Greg KH <greg@kroah.com> wrote:
A: No. Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Mon, Jun 02, 2014 at 10:10:16PM -0700, Peter Tosh wrote:
It's currently being done in a user space application which I am porting to a kernel module. Is there some other way of accomplishing the same thing safely?
Again, what is such a thing being done _for_?
Why are they doing this?
And why would a userspace program need to be ported to the kernel? What type of application is this? What does it do? Any pointers to the source to take a look at it?
thanks,
greg k-h
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Mon, 02 Jun 2014 20:29:16 -0700, Peter Tosh said:
function_1() { do some stuff }
my_print_function = function_1
EXPORT_SYMBOL(my_print_function)
No, you want EXPORT_SYMBOL(function_1) here.
function_t() { doing different stuff }
my_print_fuction = function_2
And just another function pointer assignment here
(other code)
my_print_function = function_1
My question is: Is this the correct way of doing this? Or will this cause issues?
The correct way to do this would be just use a call through a function pointer - that way any other code that's at a different point in execution doesn't end up calling something unexpected.(because let's face it - if the code is expecting to call function_1, and it suddenly ends up in function_2 anyhow, it will quite possibly misbehave).
participants (4)
-
AYAN KUMAR HALDER -
Greg KH -
Peter Tosh -
Valdis.Kletnieks＠vt.edu