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 27FA483D for ; Tue, 4 Aug 2015 11:59:04 +0000 (UTC) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8E3C889 for ; Tue, 4 Aug 2015 11:59:03 +0000 (UTC) Received: by obnw1 with SMTP id w1so5065880obn.3 for ; Tue, 04 Aug 2015 04:59:03 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: 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> Date: Tue, 4 Aug 2015 13:59:02 +0200 Message-ID: From: Daniel Vetter To: Russell King - ARM Linux Content-Type: text/plain; charset=UTF-8 Cc: Tejun Heo , Shuah Khan , "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: , Oh and it's not just file->ops, it's also vma->ops, dma_buf->ops, fence->ops and anything else that could be shared with other parts of the kernel. But I think file->ops is a good first candidate since it's the most widespread thing, so should uncover a lot of the common troubles. And a lot of the bugs will be fixed by just taking care of file->ops. -Daniel On Tue, Aug 4, 2015 at 1:56 PM, 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 > 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. > > But I don't see anything else that would work and which would be > semantically different from a reader/writer lock. There's an > additional problem that we need to guarantee that everyone completes > f->ops in finite time, which is a problem if you have blockings > ioctls. And that's a deadlock lockdep won't catch (in general at > least). For i915 that won't be a problem since because of the gpu > reset all our waiting is done interruptibly and all ioctls can be > restarted (userspace has to do it, it's part of the drm abi contract). > But even for drivers who can't do that and might deadlock I think a > deadlock in ->remove is better than randomly oopsing somewhere later > on because some f->ops is accessing freed memory. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch