Re: How to prevent a module from unloading when in used
On Wed, Jul 16, 2014 at 8:49 PM, Chetan Nanda <chetannanda@gmail.com> wrote:
On Wed, Jul 16, 2014 at 6:39 PM, John de la Garza <john@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?
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@gmail.com> wrote:
On Wed, Jul 16, 2014 at 6:39 PM, John de la Garza <john@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. thanks, greg k-h
On Wed, Jul 16, 2014 at 9:51 PM, Greg KH <greg@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@gmail.com>
wrote:
On Wed, Jul 16, 2014 at 6:39 PM, John de la Garza <john@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. Thanks Chetan Nanda thanks,
greg k-h
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@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@gmail.com> wrote: > > > > On Wed, Jul 16, 2014 at 6:39 PM, John de la Garza <john@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
On Fri, Jul 18, 2014 at 9:47 AM, Greg KH <greg@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@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@gmail.com>
wrote: > > > > On Wed, Jul 16, 2014 at 6:39 PM, John de la Garza <
john@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. Thanks, Chetan Nanda
On Fri, Jul 18, 2014 at 11:59 AM, Chetan Nanda <chetannanda@gmail.com> wrote:
On Fri, Jul 18, 2014 at 9:47 AM, Greg KH <greg@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@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@gmail.com>
wrote: > > > > On Wed, Jul 16, 2014 at 6:39 PM, John de la Garza <
john@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
On Mon, Jul 21, 2014 at 09:09:02AM +0530, Chetan Nanda wrote:
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.
You have the full git tree, it should be very easy to find, you don't need help from me. good luck, greg k-h
On Mon, Jul 21, 2014 at 9:52 AM, Greg KH <greg@kroah.com> wrote:
On Mon, Jul 21, 2014 at 09:09:02AM +0530, Chetan Nanda wrote:
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.
You have the full git tree, it should be very easy to find, you don't need help from me.
Hi Greg,
Thanks for your mail, I have found a thread with the discussion and a patch for removing the wait_for_zero_refcount from module unloading, But not able to find this patch being merged on v3.13. (have checked all patches between 3.12 and 3.13) http://www.gossamer-threads.com/lists/linux/kernel/1783584?do=post_view_thre... Thanks, Chetan Nanda
good luck,
greg k-h
On Mon, Jul 21, 2014 at 10:20:48AM +0530, Chetan Nanda wrote:
On Mon, Jul 21, 2014 at 9:52 AM, Greg KH <greg@kroah.com> wrote:
On Mon, Jul 21, 2014 at 09:09:02AM +0530, Chetan Nanda wrote:
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.
You have the full git tree, it should be very easy to find, you don't need help from me.
Hi Greg,
Thanks for your mail,
I have found a thread with the discussion and a patch for removing the wait_for_zero_refcount from module unloading, But not able to find this patch being merged on v3.13. (have checked all patches between 3.12 and 3.13) http://www.gossamer-threads.com/lists/linux/kernel/1783584?do=post_view_thre...
This email tells you the exact name of the patch to search for, and the files in which it modifies, making it even easier to search for it. How are you searching the git log that you are not seeing this patch, which ended up being in the 3.13-rc1 kernel release? Finding the git commit id is an exercise left for the reader... greg k-h
participants (2)
-
Chetan Nanda -
Greg KH