Re: [PATCH 3/3] drm/debugfs: remove dev->debugfs_list and debugfs_mutex

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 17.02.23 um 20:42 schrieb Daniel Vetter:
On Fri, Feb 17, 2023 at 04:55:27PM +0100, Christian König wrote:
Am 17.02.23 um 13:37 schrieb Jani Nikula:
On Fri, 17 Feb 2023, Christian König <ckoenig.leichtzumerken@xxxxxxxxx> wrote:
If i915 have such structural problems then I strongly suggest to solve
them inside i915 and not make common code out of that.
All other things aside, that's just a completely unnecessary and
unhelpful remark.
Sorry, but why?

We have gone through the same problems on radeon and it was massively
painful, what I try here is to prevent others from using this bad design as
well. And yes I think devm_ and drmm_ is a bit questionable in that regard
as well.

The goal is not to make it as simple as possible to write a driver, but
rather as defensive as possible. In other words automatically releasing
memory when an object is destroyed might be helpful, but it isn't
automatically a good idea.

What can easily happen for example is that you run into use after free
situations on object reference decommissions, e.g. parent is freed before
child for example.
I know that radeon/amd are going different paths on this, but I think it's
also very clear that you're not really representing the consensus here.
For smaller drivers especially there really isn't anyone arguing against
devm/drmm.

Which I completely agree on. It's just that we shouldn't promote it as "Hey this magically makes everything work in your very complex use case".

It can be a good tool to have such stuff which makes sense in a lot of use case, but everybody using it should always keep its downsides in mind as well.

Similar for uapi interfaces that just do the right thing and prevent
races. You're the very first one who argued this is a good thing to have.
kernfs/kobj/sysfs people spend endless amounts of engineer on trying to
build something that's impossible to get wrong, or at least get as close
to that as feasible.

Yeah, for kernfs/kobj/sysfs it does make complete sense because those files are actually sometimes waited on by userspace tools to appear.

I just find it extremely questionable for debugfs.

Regards,
Christian.

I mean the entire rust endeavour flies under that flag too.
-Daniel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux