Can't cleanly unload driver

[Eric Fowler]

So, I finally figured this out, and for the benefit of web posterity and
the search engines, I'm gonna lay it out:
I was using *both* the register_chrdev() and the cdev_*() functions on the
same device.

I guess you can't do that. I can't, anyway. Rubini's scull code uses both,
and it looks like he uses both on the same device, although I bet he
doesn't (haven't looked closely at the code).

I switched to using register_chrdev()/unregister_chrdev() and all is happy
now.

Thanks to all who helped.



On Mon, Dec 30, 2013 at 10:57 AM, Eric Fowler <eric.fowler at gmail.com> wrote:

> 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
>



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