All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: Tejun Heo <tj@kernel.org>, Shuah Khan <shuah.kh@samsung.com>,
	Russell King <linux@arm.linux.org.uk>,
	ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Fix devm_kzalloc, its users, or both
Date: Fri, 31 Jul 2015 10:03:01 -0700	[thread overview]
Message-ID: <20150731170301.GE5613@dtor-ws> (raw)
In-Reply-To: <alpine.DEB.2.10.1507311855250.2499@hadrien>

On Fri, Jul 31, 2015 at 06:57:17PM +0200, Julia Lawall wrote:
> 
> 
> On Fri, 31 Jul 2015, Dmitry Torokhov wrote:
> 
> > On Fri, Jul 31, 2015 at 06:34:21PM +0200, Julia Lawall wrote:
> > >
> > >
> > > On Fri, 31 Jul 2015, Laurent Pinchart wrote:
> > >
> > > > Hello,
> > > >
> > > > It recently came to my attention that the way devm_kzalloc() is used by most
> > > > drivers is broken. I've raised the topic on LKML (see
> > > > http://lkml.org/lkml/2015/7/14/741) in the hope that my findings were simply
> > > > wrong, but it turned out I was unfortunately right. As the topic spans lots of
> > > > subsystems I believe it would be a good technical topic for the Kernel Summit.
> > > >
> > > > The issue occurs when drivers use devm_kzalloc() to allocate data structures
> > > > that can be accessed through file operations on a device node. The following
> > > > sequence of events will then lead to a crash.
> > > >
> > > > 1. Get a device bound to its driver
> > > > 2. Open the corresponding device node in userspace and keep it open
> > > > 3. Unbind the device from its driver through sysfs using for instance
> > > >
> > > > echo <device-name> > /sys/bus/platform/drivers/<driver-name>/unbind
> > > >
> > > > (or for hotpluggable devices just unplug the device)
> > > >
> > > > 4. Close the device node
> > > > 5. Enjoy the fireworks
> > > >
> > > > While having a device node open prevents modules from being unloaded, it
> > > > doesn't prevent devices from being unbound from drivers. If the driver uses
> > > > devm_* helpers to allocate memory the memory will be freed when the device is
> > > > unbound from the driver, but that memory will still be used by any operation
> > > > touching an open device node.
> > >
> > > How is this different from the free happening explicitly in the remove
> > > function?
> >
> > It is not, but often devm* is "sold" as the greatest thing since sliced
> > bread and people use it by default everywhere without a second thought.
> > I see quite a few patches from newer contributors making conversion of
> > drivers to devm and quite a few of them are wrong. I also see quite
> > often suggestions to submitters encouraging using devm* which would be
> > also wrong in those particular scenarios.
> 
> I know about the problem with the interaction with interrupts, but this
> seems to be something else?  Is there a concrete example?  Or are all

I do not have concrete example, but let's say you have driver data that
you allocate with devm and use dev_set_drvdata() to attach to the
device. Then you have character device, and in open you attach your
device to the file structure and in read you do:

	dev = file->private_data;
	drvdata = dev_get_drvdata(dev);


Now that drvdata will not be there once device is unbound, but file may
still be active until userspace closes it.

> cases wrong, because freeing things in the remove function is wrong in the
> first place?

Yes... No... Maybe... ;)

Thanks.

-- 
Dmitry

  reply	other threads:[~2015-07-31 17:03 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-31 15:14 [Ksummit-discuss] [TECH TOPIC] Fix devm_kzalloc, its users, or both Laurent Pinchart
2015-07-31 15:56 ` Russell King - ARM Linux
2015-07-31 16:34 ` Julia Lawall
2015-07-31 16:51   ` Dmitry Torokhov
2015-07-31 16:57     ` Julia Lawall
2015-07-31 17:03       ` Dmitry Torokhov [this message]
2015-07-31 16:53   ` Christoph Hellwig
2015-07-31 17:02     ` James Bottomley
2015-07-31 17:05       ` Dmitry Torokhov
2015-07-31 17:13         ` James Bottomley
2015-07-31 17:33           ` Dmitry Torokhov
2015-07-31 17:36             ` James Bottomley
2015-07-31 18:28               ` Dmitry Torokhov
2015-07-31 18:40                 ` James Bottomley
2015-07-31 19:41                   ` Dmitry Torokhov
2015-08-01 10:57                     ` Mark Brown
2015-08-02 14:05                     ` Russell King - ARM Linux
2015-08-02 14:21                       ` Julia Lawall
2015-08-01 11:04     ` Laurent Pinchart
2015-08-01 11:21       ` Julia Lawall
2015-08-04 12:55         ` Dan Carpenter
2015-08-04 14:01           ` Geert Uytterhoeven
2015-08-04 17:55           ` Dmitry Torokhov
2015-08-04 18:03             ` Julia Lawall
2015-08-04 18:07               ` Dmitry Torokhov
2015-08-04 19:49             ` Russell King - ARM Linux
2015-07-31 17:04 ` Mark Brown
2015-07-31 17:27   ` Russell King - ARM Linux
2015-08-01 10:55     ` Laurent Pinchart
2015-08-01 16:30       ` Russell King - ARM Linux
2015-08-02 23:33         ` Laurent Pinchart
2015-08-01 10:47   ` Laurent Pinchart
2015-08-01 10:55     ` Julia Lawall
2015-08-01 11:01       ` Laurent Pinchart
2015-08-01 15:18         ` Tejun Heo
2015-08-02  0:48           ` Guenter Roeck
2015-08-02 14:30             ` Russell King - ARM Linux
2015-08-02 16:04               ` Guenter Roeck
2015-08-04 10:40               ` Daniel Vetter
2015-08-04 11:18                 ` Russell King - ARM Linux
2015-08-04 11:56                   ` Daniel Vetter
2015-08-04 11:59                     ` Daniel Vetter
2015-08-04 14:48                     ` Tejun Heo
2015-08-04 22:44                     ` Laurent Pinchart
2015-08-05  9:41                       ` Daniel Vetter
2015-08-04 10:49               ` Takashi Iwai
2015-08-10  7:58 ` Linus Walleij
2015-08-10 10:23   ` Russell King - ARM Linux
2015-08-11 11:35     ` Takashi Iwai
2015-08-11 15:19       ` Daniel Vetter
2015-08-21  2:19 ` Dmitry Torokhov
2015-08-21 15:07   ` Julia Lawall
2015-08-21 16:14     ` Dmitry Torokhov
2015-08-21 16:58       ` Mark Brown
2015-08-21 17:30         ` Dmitry Torokhov
2015-08-21 17:41           ` Mark Brown
2015-08-21 17:52             ` Mark Brown
2015-08-21 18:05               ` Dmitry Torokhov
2015-08-21 18:18                 ` Mark Brown
2015-10-12 18:36                   ` Theodore Ts'o
2015-10-12 18:44                     ` Mark Brown
2015-10-14 15:58                       ` Theodore Ts'o

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=20150731170301.GE5613@dtor-ws \
    --to=dmitry.torokhov@gmail.com \
    --cc=julia.lawall@lip6.fr \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux@arm.linux.org.uk \
    --cc=shuah.kh@samsung.com \
    --cc=tj@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.