Can't cleanly unload driver

[Eric Fowler]

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 <fs.rajat at gmail.com> 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 <eric.fowler at gmail.com>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, <Valdis.Kletnieks at vt.edu> 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
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>


-- 
cc:NSA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20131230/e52600e0/attachment.html