Re: [TECH TOPIC] Why is devm_kzalloc() harmful and what can we do about it

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