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