All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	Christoph Hellwig <hch@infradead.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	ksummit@lists.linux.dev, Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [TECH TOPIC] Why is devm_kzalloc() harmful and what can we do about it
Date: Thu, 23 Jun 2022 14:24:22 +0300	[thread overview]
Message-ID: <20220623112422.GE11460@kadam> (raw)
In-Reply-To: <YrRHZlcwqPChB/Yt@pendragon.ideasonboard.com>

On Thu, Jun 23, 2022 at 01:58:46PM +0300, Laurent Pinchart wrote:
> The devres family of functions tie the lifetime of the resources they
> allocate to the lifetime of a struct device bind to a driver. This is
> the right thing to do for many resources, for instance MMIO or
> interrupts need to be released when the device is unbound from its
> driver at the latest, and the corresponding devm_* helpers ensure this.
> However, drivers that expose resources to userspace have, in many cases,
> to ensure that those resources can be safely accessed after the device
> is unbound from its driver. A particular example is character device
> nodes, which userspace can keep open and close after the device has been
> unbound from the driver. If the memory region that stores the struct
> cdev instance is allocated by devm_kzalloc(), it will be freed before
> the file release handler gets to run.
> 

This is a good general description of the problem, but it's not specific
enough for me to write a checker rule.  What I basically need is a patch
I guess, and then I could try write a checker rule for that exact code.

If your RFC patch were merged then the problem would be solved?

regards,
dan carpenter


  reply	other threads:[~2022-06-23 11:24 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-18 20:33 [TECH TOPIC] Rust Miguel Ojeda
2022-06-18 20:42 ` Laurent Pinchart
2022-06-18 20:42   ` [Ksummit-discuss] " Laurent Pinchart
2022-06-18 20:44   ` Laurent Pinchart
2022-06-18 20:44     ` [Ksummit-discuss] " Laurent Pinchart
2022-06-18 20:49   ` Miguel Ojeda
2022-06-19  6:13   ` Christoph Hellwig
2022-06-19  6:13     ` [Ksummit-discuss] " Christoph Hellwig
2022-06-19 10:04     ` Laurent Pinchart
2022-06-19 10:04       ` [Ksummit-discuss] " Laurent Pinchart
2022-06-19 12:56       ` James Bottomley
2022-06-19 12:56         ` [Ksummit-discuss] " James Bottomley
2022-06-19 13:19         ` Jens Axboe
2022-06-19 13:19           ` [Ksummit-discuss] " Jens Axboe
2022-06-19 13:53           ` Laurent Pinchart
2022-06-19 13:53             ` [Ksummit-discuss] " Laurent Pinchart
2022-06-19 14:27             ` James Bottomley
2022-06-19 14:27               ` [Ksummit-discuss] " James Bottomley
2022-06-19 14:45               ` [MAINTAINER SUMMIT] Are we becoming too fearful? [was Re: [TECH TOPIC] Rust] James Bottomley
2022-06-19 14:45                 ` [Ksummit-discuss] " James Bottomley
2022-06-22  9:59                 ` Linus Walleij
2022-06-22 10:57                   ` Laurent Pinchart
2022-06-22 12:01                     ` Linus Walleij
2022-06-22 12:09                       ` Laurent Pinchart
2022-06-22 23:13                 ` NeilBrown
2022-06-23 11:37                   ` James Bottomley
2022-06-25 12:03                 ` [Ksummit-discuss] " Mauro Carvalho Chehab
2022-06-25 11:45               ` [Ksummit-discuss] [TECH TOPIC] Rust Mauro Carvalho Chehab
2022-06-25 14:15                 ` James Bottomley
2022-06-25 16:18                   ` Mauro Carvalho Chehab
2022-06-25 22:29                 ` Linus Walleij
2022-06-26  2:52                   ` Theodore Ts'o
2022-06-26  3:18                     ` Al Viro
2022-06-19 13:49         ` Laurent Pinchart
2022-06-19 13:49           ` [Ksummit-discuss] " Laurent Pinchart
2022-06-19 19:08           ` Geert Uytterhoeven
2022-06-19 19:08             ` [Ksummit-discuss] " Geert Uytterhoeven
2022-06-19 20:57             ` Matthew Wilcox
2022-06-20 13:53             ` Linus Walleij
2022-06-20 14:08             ` James Bottomley
2022-06-21 15:11           ` Dan Carpenter
2022-06-23 10:58             ` [TECH TOPIC] Why is devm_kzalloc() harmful and what can we do about it Laurent Pinchart
2022-06-23 11:24               ` Dan Carpenter [this message]
2022-06-23 11:31                 ` Laurent Pinchart
2022-06-21  9:49 ` [TECH TOPIC] Rust David Woodhouse

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=20220623112422.GE11460@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=daniel@ffwll.ch \
    --cc=hch@infradead.org \
    --cc=ksummit@lists.linux.dev \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=miguel.ojeda.sandonis@gmail.com \
    /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.