Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752859AbbG1RFM (ORCPT ); Tue, 28 Jul 2015 13:05:12 -0400 Received: from galahad.ideasonboard.com ([185.26.127.97]:54347 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752138AbbG1RFL (ORCPT ); Tue, 28 Jul 2015 13:05:11 -0400 From: Laurent Pinchart To: Tejun Heo Cc: Dan Williams , Linux Kernel Mailing List Subject: Re: Is devm_* broken ? Date: Tue, 28 Jul 2015 20:05:49 +0300 Message-ID: <3561824.rKlMSGlkdL@avalon> User-Agent: KMail/4.14.8 (Linux/4.0.5-gentoo; KDE/4.14.8; x86_64; ; ) In-Reply-To: <20150728152225.GA454@mtj.duckdns.org> References: <1503739.gVWYM3p8QD@avalon> <1643821.fnPPMYQxCt@avalon> <20150728152225.GA454@mtj.duckdns.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1162 Lines: 27 On Tuesday 28 July 2015 11:22:25 Tejun Heo wrote: > On Tue, Jul 28, 2015 at 05:16:16PM +0300, Laurent Pinchart wrote: > > 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 ? > > I don't know. Sure, we can have memory allocations which are tied to > open file; however, the distinction between that and regular devm > resources, which can't linger on no matter what, would be subtle and > confusing. IMHO, a better approach would be implmenting generic > revoke feature and sever open files on driver detach so that > everything can be shutdown then. Sounds like a topic for the kernel summit :-) I'll send a proposal. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/