I am writing a linux kernel module,
and I can't find a way to initialise my read-write lock.
I prefer a static init.
When I try using RW_LOCK_UNLOCKED, the compiler tells me that it is not defined.
rwlock_t lock = RW_LOCK_UNLOCKED;
Use the Source, Luke:
DEFINE_RWLOCK(lock);
Related
I declared a function foo() in a header file imp.h and implemented it in imp.c. Then I generated a shared library named libimp.so and in my Pin tool I called foo().
In order to link the tool with this new library I added the following definitions to makefile.rules in its directory:
TOOL_CXXFLAGS += -I/path/to/imp.h
TOOL_LPATHS += -L/path/to/libimp.so
TOOL_LIBS += -limp
I also set LD_LIBRARY_PATH to the /path/to/libimp.so. But, at runtime, if I use foo(), the following error will be received:
dlopen failed. library "libimp.so" not found.
The library is OK when I call it from a simple test program. Any ideas?
I also set LD_LIBRARY_PATH to the /path/to/libimp.so
If the full path to libimp.so is literally /path/to/libimp.so, then the correct value for LD_LIBRARY_PATH is /path/to, and not /path/to/libimp.so.
(It isn't clear from your question whether you understand this.)
You may wish to link your pintool with -Wl,--rpath=/path/to so you don't have to set LD_LIBRARY_PATH at all.
Normally, if I use rmmod to remove a kernel module, the function specified by module_exit is run. Is there some way to rmmod without having this function invoked?
In case you're curious, the reason is that I have written and insmod'ed a module whose exit method is buggy and I'd prefer not to reboot the remote machine manually when it causes the kernel to hang.
I have looked at man rmmod, but it does not seem to have such an option.
It is not possible to avoid unloading your module when rmmod is executed because there is some cleanup activity required when your module unloads, which if not done, you 'll not be able to reload your module again by executing insmod, as it will again call module_init() where you would have functions to registered (alloc_chrdev_region() or register_chrdev()) your driver. Re-registering it without un-registering it will result in a failure to load your module.
I'm not sure if this does what you are asking, but the next time you recompile the kernel you can enable the MODULE_FORCE_UNLOAD option and try rmmod -f
https://lwn.net/Articles/15571/
The linux/shed.h contains the following forward declaration:
extern rwlock_t tasklist_lock;
But where is tasklist_lock defined?
tasklist_lock is references in sched.h, and defined in fork.c
I use "gid" as a tool to spelunk through the kernel source. I simply:
1) Install idutils
2) Run "mkid" (to generate a searchable index) from the root of my kernel source
3) run "gid MYVARIABLE | less" any time I want to look something up
"idutils" is freely available on most Linux distros, and on the Internet.
Here's the documentation:
http://www.gnu.org/software/idutils/manual/idutils.html
I want to use the LSM framework with kernel ubuntu 2.6.36.
When I compiled the kernel module, it wrote:
WARNING: "register_security " undefined!
After a lot of googlings, I found the reason is that the register_security() symbol is no longer exported in the 2.6 kernel.
So I added EXPORT_SYMBOL(register_security) in the ../security/security.c file, and recompiled the kernel.
After booting with the new kernel, I added extern int register_security(struct security_operations *ops) in my kernel module file, and compiled the module again.
However, the WARNING information still existed. If I continued to insmode the module, the dmesg told me that
Unknown symbol register_security
What should I do? How can I register a Linux Security Module?
Make sure newly loaded kernel is the one, which is compiled by you.
Check the Licence of your module (Ref: http://lists.jammed.com/linux-security-module/2004/08/0053.html)
In modern kernels register_security symbol does not exported. It means that you can't register LSM module as a module. But if you really wish to do that you can do that :) Look at the exported LSM-symbols like security_sb_copy_data. They are simple wrappers over the security_ops->some_lsm_method. So, you can use their code to determine security_ops pointer value. It needs disassembler though.
Unknown symbol register_security
Happened at the line that you unregister your LSM.
So add unregister_security() in security.c and export it:
/**
* unregister_security - allows security modules to be moved
* #ops : a pointer to the struct security_options that had been registered before.
*/
int unregister_security(struct security_operations *ops)
{
if (ops != security_ops)
{
printk (KERN_INFO "%s: trying to unregister "
"a security_opts structure that is not "
"registered, failing.\n", __FUNCTION__);
return -EINVAL;
}
security_ops = &dummy_security_ops;
return 0;
}
EXPORT_SYMBOL(unregister_security);
And recompiled the kernel.
I m using gdb on a aix shared lib running on aix 5.3?
When i try to run gdb for this file
i get a error message saying ""Architecture of file not recognized"
Don't know how to get this fixed.
Does anybody know why i get this message ""Architecture of file not recognized"?.
gdb runs fine on other executables compiled by xlc.
Is there some option that i might have used while compiling , which is not compatible with GDB.some processor specific option.
I compiled the shared lib w xlc v9.0 for aix.
Thanks.
You don't run GDB on a shared library, you run it on an executable.
If the executable loads your shared library, GDB will know about it.
void
set_gdbarch_from_file (bfd *abfd)
{
struct gdbarch_info info;
struct gdbarch *gdbarch;
gdbarch_info_init (&info);
info.abfd = abfd;
info.target_desc = target_current_description ();
gdbarch = gdbarch_find_by_info (info);
if (gdbarch == NULL)
error (_("Architecture of file not recognized."));
deprecated_current_gdbarch_select_hack (gdbarch);
}
This is the actual GDB code in question (gdb/arch-utils.c:530-544).
The information passed to the gdbarch pointer seems to be invalid. This is caused by gdb_find_by_info returning a NULL pointer and that is caused by find_arch_by_info (gdb/gdbarch.c:3656) returning a NULL pointer.
It basically means what it says: GDB could not identify the architecture of the file. This seems to be a common problem for xlc, even on recent gdb versions.
XLC and gdb are, as far i remember and understand, not very good when it comes down to compatability terms (AIX support is minimal), you might try using the Gnu C Compiler .You might look at the GDB sources for VERY specific information (that i can't really give you).
Here is a link to gcc-AIX specifics.