help needed with EXPORT_SYMBOL

help needed with EXPORT_SYMBOL

[Aijaz Baig]

Hello,

Ive been trying to EXPORT a SYMBOL from a netfilter module (actually a
hook) to the KERNEL. Various modules seem to export various symbols to
the kernel (or so it seems), an example being x_tables which exports a
whole lot of functions like xt_register_target and so on and all other
netfilter modules which use these functions dont seem to have any
problems.

So why is it that when my netfilter module is exporting something to the
kernel and im tryin to use it from within a core kernel file, the
compiler flags a 'undefined reference to' error?

I googled and came to the conclusion from the kernelnewbies mailing list
that using kallsyms_lookup() seems to be the answer or is it?
So, if I do intend to use kallsyms_lookup how do I use it? There aren't
so many instances of it being used it seems.
 
Ive seen it being used in dev/core.c like so:
symname = kallsyms_lookup((unsigned long)sym, &symsize,&offset,&modname,
namebuf);

I am basically trying to call a function that MY module EXPORTs inside
one of the core linux routines. This would also mean that my netfilter
module must be compiled (and linked also maybe?..not so sound with link
time stuff) before the address becomes visible so that kallsyms_lookup
can find it. So do I really shd be using it and if so, how?

Any input is appreciated.

Regards,
Aijaz Baig.

Re: help needed with EXPORT_SYMBOL

[Jan Engelhardt]

On Saturday 2010-08-21 08:57, Aijaz Baig wrote:

>So why is it that when my netfilter module is exporting something to the
>kernel and im tryin to use it from within a core kernel file, the
>compiler flags a 'undefined reference to' error?

There, you answered yourself. Exports only go one way. And that is
core -> module -> module.

Re: help needed with EXPORT_SYMBOL

[Aijaz Baig]

Hello,

Yeah I do understand that part, but there has to be a way to do what I
am trying to do here isn't it?

And can anyone tell me can kallsyms_lookup() be used in such a
situation? If yes than how do I use it?

Regards,
Aijaz 

On Sat, Aug 21, 2010 at 2:53 PM, Jan  Engelhardt <jengelh@medozas.de>
wrote:
On Saturday 2010-08-21 08:57, Aijaz Baig wrote:
        
>So why is it that when my netfilter module is exporting something to
>the kernel and im tryin to use it from within a core kernel file, the
>compiler flags a 'undefined reference to' error?
        
There, you answered yourself. Exports only go one way. And that is
core -> module -> module.

On Sat, 2010-08-21 at 12:27 +0530, Aijaz Baig wrote:
> Hello,
> 
> Ive been trying to EXPORT a SYMBOL from a netfilter module (actually a
> hook) to the KERNEL. Various modules seem to export various symbols to
> the kernel (or so it seems), an example being x_tables which exports a
> whole lot of functions like xt_register_target and so on and all other
> netfilter modules which use these functions dont seem to have any
> problems.
> 
> So why is it that when my netfilter module is exporting something to the
> kernel and im tryin to use it from within a core kernel file, the
> compiler flags a 'undefined reference to' error?
> 
> I googled and came to the conclusion from the kernelnewbies mailing list
> that using kallsyms_lookup() seems to be the answer or is it?
> So, if I do intend to use kallsyms_lookup how do I use it? There aren't
> so many instances of it being used it seems.
>  
> Ive seen it being used in dev/core.c like so:
> symname = kallsyms_lookup((unsigned long)sym, &symsize,&offset,&modname,
> namebuf);
> 
> I am basically trying to call a function that MY module EXPORTs inside
> one of the core linux routines. This would also mean that my netfilter
> module must be compiled (and linked also maybe?..not so sound with link
> time stuff) before the address becomes visible so that kallsyms_lookup
> can find it. So do I really shd be using it and if so, how?
> 
> Any input is appreciated.
> 
> Regards,
> Aijaz Baig.
> 
> 

Re: help needed with EXPORT_SYMBOL

[Brian Gerst]

On Mon, Aug 23, 2010 at 1:14 AM, Aijaz Baig <aijazbaig1@gmail.com> wrote:
> Hello,
>
> Yeah I do understand that part, but there has to be a way to do what I
> am trying to do here isn't it?
>
> And can anyone tell me can kallsyms_lookup() be used in such a
> situation? If yes than how do I use it?
>
> Regards,
> Aijaz
>
> On Sat, Aug 21, 2010 at 2:53 PM, Jan  Engelhardt <jengelh@medozas.de>
> wrote:
> On Saturday 2010-08-21 08:57, Aijaz Baig wrote:
>
>>So why is it that when my netfilter module is exporting something to
>>the kernel and im tryin to use it from within a core kernel file, the
>>compiler flags a 'undefined reference to' error?
>
> There, you answered yourself. Exports only go one way. And that is
> core -> module -> module.
>
> On Sat, 2010-08-21 at 12:27 +0530, Aijaz Baig wrote:
>> Hello,
>>
>> Ive been trying to EXPORT a SYMBOL from a netfilter module (actually a
>> hook) to the KERNEL. Various modules seem to export various symbols to
>> the kernel (or so it seems), an example being x_tables which exports a
>> whole lot of functions like xt_register_target and so on and all other
>> netfilter modules which use these functions dont seem to have any
>> problems.
>>
>> So why is it that when my netfilter module is exporting something to the
>> kernel and im tryin to use it from within a core kernel file, the
>> compiler flags a 'undefined reference to' error?
>>
>> I googled and came to the conclusion from the kernelnewbies mailing list
>> that using kallsyms_lookup() seems to be the answer or is it?
>> So, if I do intend to use kallsyms_lookup how do I use it? There aren't
>> so many instances of it being used it seems.
>>
>> Ive seen it being used in dev/core.c like so:
>> symname = kallsyms_lookup((unsigned long)sym, &symsize,&offset,&modname,
>> namebuf);
>>
>> I am basically trying to call a function that MY module EXPORTs inside
>> one of the core linux routines. This would also mean that my netfilter
>> module must be compiled (and linked also maybe?..not so sound with link
>> time stuff) before the address becomes visible so that kallsyms_lookup
>> can find it. So do I really shd be using it and if so, how?
>>
>> Any input is appreciated.
>>
>> Regards,
>> Aijaz Baig.
>>
>>

Use an exported function pointer in the main kernel as a hook that the
module sets when it is loaded.  Note, you must use module_get and
module_put around the call to the module to prevent it from unloading
while in use.

--
Brian Gerst
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: help needed with EXPORT_SYMBOL

[Peter Zijlstra]

On Mon, 2010-08-23 at 07:48 -0400, Brian Gerst wrote:
> 
> Use an exported function pointer in the main kernel as a hook that the
> module sets when it is loaded.  Note, you must use module_get and
> module_put around the call to the module to prevent it from unloading
> while in use. 

Please don't do any such thing, its impossible to use correctly.

Suppose there are two modular users, A and B.

Both have something like:

extern void (*fptr)(void);

static void (*old_fptr)(void);

static void func(void)
{
	/* foo */
	if (old_fptr)
		old_fptr();
}

module_init()
{
	old_fptr = fptr;
	fptr = A_func;
}

Then you load A, load B and unload A, then guess what happens?

Re: help needed with EXPORT_SYMBOL

[Jan Engelhardt]

On Monday 2010-08-23 15:17, Peter Zijlstra wrote:

>On Mon, 2010-08-23 at 07:48 -0400, Brian Gerst wrote:
>> 
>> Use an exported function pointer in the main kernel as a hook that the
>> module sets when it is loaded.  Note, you must use module_get and
>> module_put around the call to the module to prevent it from unloading
>> while in use. 
>
>Please don't do any such thing, its impossible to use correctly.
>
>Suppose there are two modular users, A and B.

Though in case there is just a single user it can work out.
Just like bridge.c, and the bunch of nf_nat_*.c. :-)
Though yeah. Bad bad.

This is starting to sound pretty much like an XY problem: XY problem: 
You want to do X, but don't know how. You think you can solve it using 
Y, but don't know how to do that, either. You ask about Y, which is a 
strange thing to want to do. Just ask about X.

(And then there is still the "good idea to do X in the first place" 
thing.) Like what's so important to have as a module when you can build 
it in, given that the caller is built-in (obj-y) itself.

>module_init()
>{
>	old_fptr = fptr;
>	fptr = A_func;
>}
>
>Then you load A, load B and unload A, then guess what happens?
>

Re: help needed with EXPORT_SYMBOL

[Peter Zijlstra]

On Mon, 2010-08-23 at 15:32 +0200, Jan Engelhardt wrote:
> On Monday 2010-08-23 15:17, Peter Zijlstra wrote:
> 
> >On Mon, 2010-08-23 at 07:48 -0400, Brian Gerst wrote:
> >> 
> >> Use an exported function pointer in the main kernel as a hook that the
> >> module sets when it is loaded.  Note, you must use module_get and
> >> module_put around the call to the module to prevent it from unloading
> >> while in use. 
> >
> >Please don't do any such thing, its impossible to use correctly.
> >
> >Suppose there are two modular users, A and B.
> 
> Though in case there is just a single user it can work out.
> Just like bridge.c, and the bunch of nf_nat_*.c. :-)
> Though yeah. Bad bad.

We have this problem in several areas in the kernel (pm_idle being the
one I hate most since its in code I touch actually grew tons of users).

If you really need to export hooks, provide a registration mechanism and
an arbiter. A very simple, already existing, implementation of this
would be notification chains (include/linux/notifier.h), these provide a
registration interface, and the arbiter is a combination of static
priority combined with return codes.

A more complex example would be the cpuidle/pm_qos subsystem, where you
can register idle states and provide various attributes (exit latency,
energy break even duration, etc) and have the governor pick an idle
state depending on the predicted idle time and required exit latencies.

Bare function pointers suck.

Re: help needed with EXPORT_SYMBOL

[Brian Gerst]

On Mon, Aug 23, 2010 at 9:17 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Mon, 2010-08-23 at 07:48 -0400, Brian Gerst wrote:
>>
>> Use an exported function pointer in the main kernel as a hook that the
>> module sets when it is loaded.  Note, you must use module_get and
>> module_put around the call to the module to prevent it from unloading
>> while in use.
>
> Please don't do any such thing, its impossible to use correctly.
>
> Suppose there are two modular users, A and B.
>
> Both have something like:
>
> extern void (*fptr)(void);
>
> static void (*old_fptr)(void);
>
> static void func(void)
> {
>        /* foo */
>        if (old_fptr)
>                old_fptr();
> }
>
> module_init()
> {
>        old_fptr = fptr;
>        fptr = A_func;
> }
>
> Then you load A, load B and unload A, then guess what happens?
>

The assumption was that there was a single module using that hook.
For multiple users you'd need to use a register function that adds the
module to a linked list.

--
Brian Gerst
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: help needed with EXPORT_SYMBOL

[Peter Zijlstra]

On Mon, 2010-08-23 at 09:44 -0400, Brian Gerst wrote:
> The assumption was that there was a single module using that hook.

Not really a future-proof design, is it?

Re: help needed with EXPORT_SYMBOL

[Aijaz Baig]

Hello everyone, 

thanks for sending in the replies with so many options. I am still a
relative newbie so please do bear with me guys if I sound a bit naive at
times.

I'll first start with brian's suggestion. He said:
"Use an exported function pointer in the main kernel as a hook that the
module sets when it is loaded.  Note, you must use module_get and
module_put around the call to the module to prevent it from unloading
while in use."

I have never used such a technique and do not understand what you mean.
Could you please elaborate a little. Do you mean I should NF_HOOK within
the kernel code and then make the function that I would like to execute
as the hookfn? Well..if this is what u meant then wouldn't it also cause
all hooks at that particular position to be executed as well? 

And then peter and finally jan came up with, perhaps better suggestions
(i really cannot judge the quality of any of these suggestions..m too
much of a noob to do that). I got confused in the XY explanation by jan
since there both X and Y are modules it seems and I was talking about a
module exporting a certain symbol to be used by the kernel. Peter did
suggest notification chains. Is there a simple example that I can look
at? Will it allow the kernel to see symbols defined within the module? 

Lastly, will I be able to use kallsyms_lookup() to do what I can? I
notice that it replaced EXPORT_SYMTAB sometime back. So if yes I can use
it, does anyone know how to fill in the very first parameter of this
function which says address (of what exactly and how am I supposed to
know this address?)

Keen to hear from you and once again, thank you for your inputs,

Regards,
Aijaz Baig.

Re: Fwd: help needed with EXPORT_SYMBOL

[Aijaz Baig]

Hi everyone

I am trying to understand if its possible to add functions dynamically
to the kernel source based on the presence of certain modules in the
running kernel image.

I did try what brian suggested with the function pointer and yeah it
does work. But I could not understand what peter was trying to say about
modular users since I suppose he mentioned one module (B in this case)
using a function pointer defined in (or by) module A. In my case, since
it is the kernel that is gonna use the function, I need to make sure
that the module doesn't get unloaded while we are using the function.

By the way Jan I couldnt find bridge.c although there is an object file
called bridge.o within /net/bridge. Nonetheless, I did check
nf_nat_ftp.c as an example to see if something similar is being done
there too. What I did find out is that nf_nat_ftp_hook is rcu assigned
in nf_nat_ftp.c however this function pointer is being used with
nf_contrack_ftp.c (im talkin 2.6.27.45 here). In this case, it still is
module1 <- module2 and not kernel <- module. Could you please elaborate
a little how it affects the latter case. Or perhaps u were commenting on
the former case since peter brought that to our notice.

thanks again for your replies and keen to hear your input
Regards,
Aijaz Baig 

> 
> 
> ---------- Forwarded message ----------
> From: Brian Gerst <brgerst@gmail.com>
> Date: Tue, Aug 24, 2010 at 4:46 PM
> Subject: Re: help needed with EXPORT_SYMBOL
> To: aijazbaig1@gmail.com
> 
> 
> 
> On Tue, Aug 24, 2010 at 12:44 AM, Aijaz Baig <aijazbaig1@gmail.com>
> wrote:
> > Hello everyone,
> >
> > thanks for sending in the replies with so many options. I am still a
> > relative newbie so please do bear with me guys if I sound a bit
> naive at
> > times.
> >
> > I'll first start with brian's suggestion. He said:
> > "Use an exported function pointer in the main kernel as a hook that
> the
> > module sets when it is loaded.  Note, you must use module_get and
> > module_put around the call to the module to prevent it from
> unloading
> > while in use."
> >
> > I have never used such a technique and do not understand what you
> mean.
> > Could you please elaborate a little. Do you mean I should NF_HOOK
> within
> > the kernel code and then make the function that I would like to
> execute
> > as the hookfn? Well..if this is what u meant then wouldn't it also
> cause
> > all hooks at that particular position to be executed as well?
> >
> > And then peter and finally jan came up with, perhaps better
> suggestions
> > (i really cannot judge the quality of any of these suggestions..m
> too
> > much of a noob to do that). I got confused in the XY explanation by
> jan
> > since there both X and Y are modules it seems and I was talking
> about a
> > module exporting a certain symbol to be used by the kernel. Peter
> did
> > suggest notification chains. Is there a simple example that I can
> look
> > at? Will it allow the kernel to see symbols defined within the
> module?
> >
> > Lastly, will I be able to use kallsyms_lookup() to do what I can? I
> > notice that it replaced EXPORT_SYMTAB sometime back. So if yes I can
> use
> > it, does anyone know how to fill in the very first parameter of this
> > function which says address (of what exactly and how am I supposed
> to
> > know this address?)
> >
> > Keen to hear from you and once again, thank you for your inputs,
> 
> 
> You still haven't explained why you want to lookup a symbol in a
> module from the main kernel.  There is probably a better way of doing
> it.
> 
> --
> Brian Gerst
> 
> 

Re: Fwd: help needed with EXPORT_SYMBOL

[Jan Engelhardt]

On Wednesday 2010-08-25 11:27, Aijaz Baig wrote:

>By the way Jan I couldnt find bridge.c although there is an object file
>called bridge.o within /net/bridge.

$ git grep -e br_handle_frame_hook v2.6.35 net/bridge/

See that, which is used kernel<-module. This frame hook has been changed 
in 2.6.36-rc1 which is why looking at 2.6.35 would be the short route.

Re: Fwd: help needed with EXPORT_SYMBOL

[Peter Zijlstra]

On Wed, 2010-08-25 at 14:57 +0530, Aijaz Baig wrote:

> I am trying to understand if its possible to add functions dynamically
> to the kernel source based on the presence of certain modules in the
> running kernel image.
> 
> I did try what brian suggested with the function pointer and yeah it
> does work. But I could not understand what peter was trying to say about
> modular users since I suppose he mentioned one module (B in this case)
> using a function pointer defined in (or by) module A. In my case, since
> it is the kernel that is gonna use the function, I need to make sure
> that the module doesn't get unloaded while we are using the function.

Right, so there's two problems there:

 - the exposed function pointer
 - unload serialization

The problem with the exposed function pointer is that two competing
modules can set the function pointer:

extern void (*ptr)(void);

static void (*old_ptr)(void);

void func(void)
{
  /* do something */
}

module_init()
{
  old_ptr = ptr;
  ptr = func;
}

module_exit()
{
  ptr = old_ptr;
  synchronize_stuff();
}

Now suppose two modules A and B both have that template, then load
module A, at that time ptr == A::func, A::old_ptr = NULL, right?

Then load B, then ptr == B:func, B::old_ptr = A::func.

then unload A, then ptr == NULL; /* hey where's B gone? */

Suppose module_exit() had read:

module_exit()
{
  if (ptr == func)
    ptr = old_ptr;
}

Then after A got unloaded, you'd have: ptr = B::func, B::old_ptr ==
A:func, and the world goes *bang* when you unload B.

If you'd have exposed the thing like:

static void (*callback)(void);

int set_foo_callback(void (*func)(void))
{
  if (callback && func)
    return -EBUSY;

  callback = func;
  synchronize_world();
  return 0;
}
EXPORT_SYMBOL_GPL(set_foo_callback);

Then there'd be no confusion, as loading B while A was already loaded
would fail since set_foo_callback() would fail with -EBUSY.


Now the synchronization issue, above represented by synchronize_world();
that will have to do something that ensures all current users of the ptr
have gone, taking a reference on the module will likely result in an
pinned module, since what will drop the ref again?

Module unload does a fairly heavy stop-machine thing, which might be
sufficient for some, but a sensible solution really depends on the
problem domain, RCU could be used in various ways.

Re: Fwd: help needed with EXPORT_SYMBOL

[Randy Dunlap]

On Wed, 25 Aug 2010 14:57:58 +0530 Aijaz Baig wrote:

> By the way Jan I couldnt find bridge.c although there is an object file
> called bridge.o within /net/bridge. Nonetheless, I did check

See net/bridge/Makefile:

obj-$(CONFIG_BRIDGE) += bridge.o

bridge-y	:= br.o br_device.o br_fdb.o br_forward.o br_if.o br_input.o \
			br_ioctl.o br_notify.o br_stp.o br_stp_bpdu.o \
			br_stp_if.o br_stp_timer.o br_netlink.o

and see Documentation/kbuild/makefiles.txt.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***