From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Tejun Heo <tj@kernel.org>, Russell King <linux@arm.linux.org.uk>,
ksummit-discuss@lists.linuxfoundation.org,
Shuah Khan <shuah.kh@samsung.com>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Fix devm_kzalloc, its users, or both
Date: Fri, 31 Jul 2015 10:02:39 -0700 [thread overview]
Message-ID: <1438362159.2179.42.camel@HansenPartnership.com> (raw)
In-Reply-To: <20150731165346.GA18984@infradead.org>
On Fri, 2015-07-31 at 09:53 -0700, Christoph Hellwig wrote:
> On Fri, Jul 31, 2015 at 06:34:21PM +0200, Julia Lawall wrote:
> > How is this different from the free happening explicitly in the remove
> > function?
>
> It's not. The real problem is that people don't understand life time
> rules and expect magic interfaces to fix it for them.
So surely the rule is that we do this in module removal. That doesn't
get called until last put on the module and that can't happen (or
shouldn't happen) while userspace is holding open one of the /sys
or /proc interfaces (usually those objects hold a reference on something
within the driver to prevent this).
There is an alternative way of handling this: that would be to detach
the file from the backing interface at _del time, so sysfs/kernfs would
take over the interface and return -ENODEV or something meaning we
could tear down the module even if there was an open interface file.
I'm not advocating this as a solution because I can already see the
problems (like how do you switch interfaces atomically) but if this
really is a serious problem, we should explore alternative solutions.
James
next prev parent reply other threads:[~2015-07-31 17:02 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-31 15:14 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
2015-07-31 16:53 ` Christoph Hellwig
2015-07-31 17:02 ` James Bottomley [this message]
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=1438362159.2179.42.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=hch@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox