All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: David Herrmann <dh.herrmann@googlemail.com>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] Input: Remove unsafe device module references
Date: Tue, 1 Nov 2011 10:58:43 -0700	[thread overview]
Message-ID: <20111101175843.GA4241@suse.de> (raw)
In-Reply-To: <20111101175210.GA15216@core.coreip.homeip.net>

On Tue, Nov 01, 2011 at 10:52:10AM -0700, Dmitry Torokhov wrote:
> On Tue, Nov 01, 2011 at 10:01:56AM -0700, Greg KH wrote:
> > On Tue, Nov 01, 2011 at 04:41:40PM +0100, David Herrmann wrote:
> > > Hi Dmitry and Greg
> > > 
> > > It doesn't make sense to take a reference to our own module. When we call
> > > module_put(THIS_MODULE) we cannot make sure that our module is still alive when
> > > this function returns. Therefore, module_put() will return to invalid memory and
> > > our input_dev_release() function is no longer available.
> > > 
> > > It would be interesting if Greg could elaborate what else we could do to replace
> > > this module-refcount as it is definitely needed here. However, "struct device"
> > > doesn't provide an owner field so there is no way for us to let the device core
> > > keep a reference to our module.
> > 
> > For a bus module, yes, this is needed, so don't remove these calls, it's
> > wrong to do so.
> 
> Strictly speaking, David is right, there is a race condition here.
> However since we do module_put() as very last operation of
> input_dev_release() it is extremely hard to trigger this race.
> 
> Until we have a better way of pinning the bus (or class) implementation
> in memory we should keep __module_get/module_put in input core.

I agree, that's fine for a bus to do, as long as you are aware of how it
is working.

greg k-h

  reply	other threads:[~2011-11-01 18:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-01 15:41 [RFC] Input: Remove unsafe device module references David Herrmann
2011-11-01 17:01 ` Greg KH
2011-11-01 17:52   ` Dmitry Torokhov
2011-11-01 17:58     ` Greg KH [this message]
2011-11-01 17:52   ` David Herrmann
2011-11-01 17:52     ` David Herrmann
2011-11-01 18:00     ` Greg KH
2011-11-01 18:09       ` David Herrmann
2011-11-01 18:18         ` Dmitry Torokhov
2011-11-02 13:45           ` David Herrmann
2011-11-02 14:43             ` Greg KH
2011-11-01 18:05     ` Dmitry Torokhov
2011-11-01 18:05       ` Dmitry Torokhov
2011-11-01 18:16       ` David Herrmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111101175843.GA4241@suse.de \
    --to=gregkh@suse.de \
    --cc=dh.herrmann@googlemail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.