All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <jdelvare@suse.de>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Wolfram Sang <wsa@the-dreams.de>,
	Jonathan Corbet <corbet@lwn.net>, Corey Minyard <minyard@acm.org>,
	Guenter Roeck <linux@roeck-us.net>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Andrew Duggan <aduggan@synaptics.com>,
	Christopher Heiny <cheiny@synaptics.com>,
	linux-i2c@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-input@vger.kernel.org
Subject: Re: [PATCH v8 2/4] i2c-smbus: add SMBus Host Notify support
Date: Mon, 18 Jul 2016 22:47:43 +0200	[thread overview]
Message-ID: <20160718224743.01b4a330@endymion> (raw)
In-Reply-To: <20160718163519.GT4663@mail.corp.redhat.com>

On Mon, 18 Jul 2016 18:35:19 +0200, Benjamin Tissoires wrote:
> On Jul 18 2016 or thereabouts, Jean Delvare wrote:
> > But what happens on i2c_adapter removal? What prevents the following
> > sequence from happening?
> > 
> > 1* A Host Notify event happens.
> > 2* The event is handled and queued by i2c_handle_smbus_host_notify().
> > 3* Someone tears down the underlying i2c_adapter (for example "rmmod
> >    i2c-i801".)
> > 4* The workqueue is processed, accessing memory which has already been
> >    freed.
> > 
> > Of course it would be back luck, but that's pretty much the definition
> > of a race condition ;-)
> 
> Yes, you are right :(
> Sorry for not doing things properly :/

No worry. Bugs happen everywhere, we find them and fix them. That's
part of the process. If we only submit patches which we are 100%
certain are perfect, we never submit anything. I know something about
that...

> > To be on the safe side, don't we need a teardown function in i2c-smbus,
> > that could be called before i2c_del_adapter, which would remove the
> > host notify handle and flush the workqueue?
> 
> I was thinking at adding a devm action on the release of the struct
> smbus_host_notify, but it's actually a bad idea because some other
> resources (children moslty) might already be released when the devres
> action will be called.
> 
> I think it might be easier to add a i2c_remove_host_notify() (or such)
> which would make sure we call the cancel_work_sync() function. It would
> be the responsibility of the caller to call it once
> i2c_setup_smbus_host_notify() has been called. I'd say it has the
> advantage of not adding any hidden data in the adapter to the cost of a
> small pain in the adapter driver.

That's what I had in mind as well, but I'm open to any option which
solves the problem really.

-- 
Jean Delvare
SUSE L3 Support

  reply	other threads:[~2016-07-18 20:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-09 14:53 [PATCH v8 0/4] i2c-smbus: add support for HOST NOTIFY Benjamin Tissoires
2016-06-09 14:53 ` [PATCH v8 1/4] i2c: add a protocol parameter to the alert callback Benjamin Tissoires
2016-06-17 11:26   ` Wolfram Sang
2016-06-09 14:53 ` [PATCH v8 2/4] i2c-smbus: add SMBus Host Notify support Benjamin Tissoires
2016-06-17 11:26   ` Wolfram Sang
2016-07-18  9:37   ` Jean Delvare
2016-07-18 15:59     ` Benjamin Tissoires
2016-07-18 16:47       ` Jean Delvare
2016-07-18 14:31   ` Jean Delvare
2016-07-18 16:35     ` Benjamin Tissoires
2016-07-18 20:47       ` Jean Delvare [this message]
2016-06-09 14:53 ` [PATCH v8 3/4] i2c: i801: add support of Host Notify Benjamin Tissoires
2016-06-15  8:12   ` Benjamin Tissoires
2016-06-16  6:09     ` Wolfram Sang
2016-06-16 12:55       ` Benjamin Tissoires
2016-06-16 14:31         ` Wolfram Sang
2016-06-23 20:55       ` Dmitry Torokhov
2016-06-23 21:46         ` Wolfram Sang
2016-06-23 22:57           ` Dmitry Torokhov
2016-06-09 14:53 ` [PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support Benjamin Tissoires
2016-06-23 23:06   ` Dmitry Torokhov
2016-06-24  7:19     ` Benjamin Tissoires
2016-06-24 23:35       ` Dmitry Torokhov
2016-06-27 15:03         ` Benjamin Tissoires

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=20160718224743.01b4a330@endymion \
    --to=jdelvare@suse.de \
    --cc=aduggan@synaptics.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=cheiny@synaptics.com \
    --cc=corbet@lwn.net \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=minyard@acm.org \
    --cc=wsa@the-dreams.de \
    /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.