linux-kernel - Re: Is devm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 28 Jul 2015 17:16:16 +0300
From:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Dan Williams <dan.j.williams@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Is devm_* broken ?

Hi Teejun,

On Wednesday 15 July 2015 14:03:55 Tejun Heo wrote:
> Hello,
> 
> On Wed, Jul 15, 2015 at 10:00:54AM -0700, Dan Williams wrote:
> > Sounds like a real problem.  The drivers I've used devm with have an
> > upper layer that prevents this crash, but that's not much consolation.
> > I think adding lifetime to devm allocations would be useful that way
> > ->probe() and open() can do a devres_get() while ->remove() and
> > close() can do a devres_put().  Perhaps I'm also missing something
> > obvious though...
> 
> Hmmm... so this really is a general lifetime management problem and
> also why sysfs implements revoke semantics.  As memory allocated by
> devm_kmalloc() isn't tied to any specific hardware, it seems a bit
> murky here but if you consider any other resources, this is clear - a
> driver must not access any resources once detach is complete.  These
> aren't resources which can be detached and then held while draining
> existing userland references.  They immediately conflict with the next
> driver which is gonna attach to the device.
> 
> A driver should isolate and drain on-going accesses from userland
> before finishing detaching one way or another.  No resources attached
> to the hardware side can't be held once detaching is complete.  If a
> piece of memory isn't attached to the harware side but the userland
> interface side which gets isolated and drained after detachment, that
> shouldn't be allocated via devm - it has "dev" in its name for a
> reason.

Then that's a message we should start hammering in. There's plenty of drivers 
that have happily switched to devm_kzalloc() to allocate the driver private 
data structure, and that structure can't be freed before the last reference 
from userspace gets dropped. I'd even argue that this is the main use case of 
devm_kzalloc() in drivers.

Using devm_kzalloc() in such a way has value though, and reverting drivers to 
the pre-devm memory allocation code would make error handling and cleanup code 
paths more complex again. Should we introduce a managed allocator for that 
purpose that would have a lifespan explicitly handled by drivers ?

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/