How to prevent a module from unloading when in used

[Chetan Nanda]

On Fri, Jul 18, 2014 at 11:59 AM, Chetan Nanda <chetannanda at gmail.com>
wrote:

>
>
>
> On Fri, Jul 18, 2014 at 9:47 AM, Greg KH <greg at kroah.com> wrote:
>
>> On Fri, Jul 18, 2014 at 09:43:48AM +0530, Chetan Nanda wrote:
>> >
>> >
>> >
>> > On Wed, Jul 16, 2014 at 9:51 PM, Greg KH <greg at kroah.com> wrote:
>> >
>> >     On Wed, Jul 16, 2014 at 08:57:38PM +0530, Chetan Nanda wrote:
>> >     >
>> >     >
>> >     >
>> >     > On Wed, Jul 16, 2014 at 8:49 PM, Chetan Nanda <
>> chetannanda at gmail.com>
>> >     wrote:
>> >     >
>> >     >
>> >     >
>> >     >     On Wed, Jul 16, 2014 at 6:39 PM, John de la Garza <
>> john at jjdev.com>
>> >     wrote:
>> >     >
>> >     >         On Wed, Jul 16, 2014 at 04:00:18PM +0530, Chetan Nanda
>> wrote:
>> >     >         > A depends on B, so B is automatically loaded when A is
>> loaded.
>> >     >         > B module is also directly being used by the user side
>> code via
>> >     misc
>> >     >         > interface.
>> >     >         >.
>> >     >         > Now when I am unloading module A, via "modprobe -r A"
>> it is
>> >     also
>> >     >         unloading
>> >     >         > the module B which is being used by the application and
>> >     resulting in
>> >     >         the
>> >     >         > kernel crash.
>> >     >
>> >     >         You said that A depends on B, right?  Why do you have A
>> dependng
>> >     on B?
>> >     >         If it A needs to have B then it makes sense that you can
>> not
>> >     remove A
>> >     >         while
>> >     >         B is in use.  If A doesn't need B, why not remove the
>> dependency.
>> >     >
>> >     >
>> >     > A is calling few APIs defined by B.
>> >     >
>> >     > But why when user space application is already using  module B.
>> (it has
>> >     already
>> >     > open its device fd) kernel allows to remove it.
>> >     >
>> >     > I tried with doing try_module_get() in the module's open
>> function, it
>> >     prevent
>> >     > module B unloading but cause thread doing modprobe -r to hang
>> >     > Is there any other way to mark module as busy when being used by
>> user
>> >     > application?
>> >
>> >     Never use try_module_get(), that is racy.
>> >
>> >     What is the user/kernel interface you are using, and why doesn't it
>> >     automatically increase the module count when userspace opens the
>> >     interface?  It should all be done in a way that your module doesn't
>> need
>> >     to do anything special.
>> >
>> >
>> > Hi Greg,
>> >
>> > Thanks for your mail.
>> >
>> > Module is using misc driver interface to export its functionality to
>> > userspace,
>> >
>> > Need to debug further why module count is not getting incremented
>> automatically
>> > when module is open by userspace application via open system call.
>>
>> Are you properly setting the .owner field of your file operations
>> structure to be THIS_MODULE?  If not, try fixing that up.  If you are,
>> try posting your code for review.
>>
>> greg k-h
>>
>
> Hi Greg,
>
> Thanks for the hint, indeed that was the issue, .owner field was not set
> in file operation structure.
> After setting that, 'modprobe -r A' is hanging. As the module B in use and
> can't be removed.
>
> I am using busybox on embedded Linux, I think this could be a modprobe
> utility issue.
> Ideally modprobe should not try to remove the module in used.
>
> I try to debug the hang when unloading of driver. I am using kernel v3.10
and it hangs in 'wait_for_zero_refcount'.
I checked that this function has been removed in kernel 3.13.
But I am not able to find the patch for this change.

Is there an easy way to find the patch which cause removal of wait from
module unloading in v3.13.



> Thanks,
> Chetan Nanda
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140721/fc29fd72/attachment.html