[Ksummit-discuss] [TECH TOPIC] Fix devm_kzalloc, its users, or both

[Daniel Vetter]

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 <daniel.vetter at ffwll.ch> wrote:
> On Tue, Aug 4, 2015 at 1:18 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> 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