From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A23F58EF for ; Tue, 4 Aug 2015 14:48:36 +0000 (UTC) Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com [209.85.160.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 071761C8 for ; Tue, 4 Aug 2015 14:48:35 +0000 (UTC) Received: by ykeo23 with SMTP id o23so9582330yke.3 for ; Tue, 04 Aug 2015 07:48:35 -0700 (PDT) Sender: Tejun Heo Date: Tue, 4 Aug 2015 10:48:33 -0400 From: Tejun Heo To: Daniel Vetter Message-ID: <20150804144833.GA17598@mtj.duckdns.org> References: <2111196.TG1k3f53YQ@avalon> <1832413.9MBGoll9RW@avalon> <8475257.M7ZLAf3KQe@avalon> <20150801151839.GA9480@mtj.duckdns.org> <55BD68DE.5060903@roeck-us.net> <20150802143025.GF7557@n2100.arm.linux.org.uk> <20150804111804.GO7557@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Shuah Khan , Russell King - ARM Linux , "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [TECH TOPIC] Fix devm_kzalloc, its users, or both List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hello, On Tue, Aug 04, 2015 at 01:56:38PM +0200, Daniel Vetter wrote: > On Tue, Aug 4, 2015 at 1:18 PM, Russell King - ARM Linux > wrote: > > A solution to that would be to drop something like a read-write lock into > > almost all f_op methods, which sounds expensive to me in the general case. > > srcu is what I considered since it would be least intrusive and shifts > the overall all to the write. The problem of course is that if you do percpu_ref is likely a better fit. > that then there will be deadlock gallore - suddenly anything called > from f->ops can stall code called from ->remove. And looking at how > regularly we have lockdep splat in the driver unload code just in i915 > that will be really painful. It's the other side of the same coin. At least it's a lot easier to detect with a lot more deterministic failure mode than derefing freed memory or accessing gone hardware. Thanks. -- tejun