Erik Mouw <mouw <at> nl.linux.org> writes: > > > > > > > > >I will examine the LD_PRELOAD idea, seems like it could work. > > >Regarding the kernel module idea by replacing an existing function, > > >doing some stuff and then restoring the original system call - is > > >this a normal way of approaching it? Would it be considered ok? > > > > No. It is dirty and unsafe in SMP systems. If you want to do that use > > kprobes. > > It's only unsafe on uniprocessor systems. Load module A, which hooks > into sys_read(). It stores the location of the original sys_read to > restore it at unload. Load module B, which also hooks into sys_read() > and stores the location of the previos sys_read (which is actually > module A's implementation of sys_read()). Now unload module A. Next > process that will call sys_read() will cause a kernel Oops. > Module A doesn't make changes to sys_read() rather it only needs to get the data regarding it (the file size that was opened, etc) and always returns the original sys_read() anyway. So the whole process should be transparent, even to module B, so I don't see the problem regarding the kernel oops even in that case. If it still applies, please explain why. Ok so hooking is a bad idea and anyway isn't supported in 2.6 and regarding kprobes, some distros don't shift with it's kernel config turned on. How about resulting back to the LD_PRELOAD idea that was suggested at first? Thanks, Liran. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
