Actually, I was working with a homegrown makefile. I made the change you recommended and am still having the problem.
I am thinking now about something else as being the problem. Is this code legitimate? //// file scope struct cdev my_cdev; ///inside init function cdev_init(&my_cdev, ....); cdev_add(&my_cdev, ....); ///exit fxn cdev_del(&my_cdev); In other words, the memory for the cdev struct comes from static memory for the driver, not a call to cdev_alloc() or kmalloc(). On Mon, Dec 30, 2013 at 10:18 AM, Rajat Sharma <[email protected]> wrote: > Hi Eric, > > I have seen some errors with module reference counting with a nicely > written code, but culprit for my case was a missing compilation flag > -DMODULE which gives definition of THIS_MODULE, otherwise it is null e.g. > for modules which are compiled in kernel, so they are never unloaded. > Unless you have some customization done to Makefiles, this definition > should be included, but its anyways good to double check and rule out this > possibility. > > -Rajat > > > On Mon, Dec 30, 2013 at 9:48 AM, Eric Fowler <[email protected]>wrote: > >> Still working on this. Here is some dmesg spew: >> >> [ 514.245846] foobar: module verification failed: signature and/or >> required key missing - tainting kernel >> [ 514.245937] kobject: 'foobar' (f7f060c8): kobject_add_internal: >> parent: 'module', set: 'module' >> [ 514.245951] kobject: 'holders' (f5ff3d40): kobject_add_internal: >> parent: 'foobar', set: '<NULL>' >> [ 514.245981] kobject: 'notes' (f2d25f80): kobject_add_internal: parent: >> 'foobar', set: '<NULL>' >> [ 514.245987] kobject: 'foobar' (f7f060c8): kobject_uevent_env >> [ 514.245998] kobject: 'foobar' (f7f060c8): fill_kobj_path: path = >> '/module/foobar' >> >> So it looks like kernel validation is failing. I have printk's in my init >> fxn that are never turning up in /var/log/messages, until, weirdly, AFTER I >> remove the device: >> >> <insmod device> >> Dec 30 09:43:03 localhost kernel: [ 514.245846] foobar: module >> verification failed: signature and/or required key missing - tainting kernel >> Dec 30 09:43:16 localhost fprintd[1085]: ** Message: No devices in use, >> exit >> >> <rmmod device> >> Dec 30 09:45:53 localhost kernel: [ 514.249323] foobar: got device >> number 248, minor is 0 <<<<----THIS IS IN init() fxn >> Dec 30 09:45:53 localhost kernel: [ 684.102912] unregister_chrdev(248) >> called for foobar<7>[ 684.102927] kobject: '(null)' (f7f06220): >> kobject_cleanup, parent (null) >> >> <insmod> >> insmod: ERROR: could not insert module ./foobar.ko: Device or resource >> busy >> >> >> >> >> >> >> >> >> On Fri, Dec 27, 2013 at 9:13 PM, <[email protected]> wrote: >> >>> On Fri, 27 Dec 2013 19:33:50 -0800, Eric Fowler said: >>> >>> > I suspect I am doing something wrong in the code with >>> > register/unregister_chrdev(), but I have been over that code a million >>> > times. It looks fine. >>> > >>> > Now: >>> > insmod the device, OK >>> > rmmod the device, OK >>> > Check /proc/devices , device # is present >>> > insmod the device again, fails with ERROR: could not insert module >>> > ./foobar.ko: Device or resource busy >>> >>> It does smell like an unregister issue. You may want to try adding >>> printk() calls to print out the return code from register and unregister. >>> I'm willing to bet that (a) the unegister is failing because somebody >>> still has a reference on the device, and (b) the second register call >>> fails >>> because the device already exists, causing your module_init() to bail >>> out. >>> >>> The fun is that you may not have taken a reference on the device directly >>> yourself - you may have called some other get_foo() that ends up taking >>> an >>> implicit reference under the covers, causing issues when you fail to call >>> put_foo() at the right place... >>> >> >> >> >> -- >> cc:NSA >> >> _______________________________________________ >> Kernelnewbies mailing list >> [email protected] >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> > -- cc:NSA
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
