On Fri, Oct 30, 2020 at 10:15:21AM +0100, Daniel Vetter wrote: > On Fri, Oct 30, 2020 at 09:25:18AM +0100, Greg KH wrote: > > On Fri, Oct 30, 2020 at 09:00:04AM +0100, Christian König wrote: > > > Am 30.10.20 um 08:57 schrieb Deepak R Varma: > > > > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote: > > > > > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote: > > > > > > Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe() > > > > > > function in place of the debugfs_create_file() function will make the > > > > > > file operation struct "reset" aware of the file's lifetime. Additional > > > > > > details here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.archive.carbon60.com%2Flinux%2Fkernel%2F2369498&data=04%7C01%7Cchristian.koenig%40amd.com%7Cddd7a6ac8164415a639708d87ca97004%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637396414464384011%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o6GOHvMxNMuOPlC4nhDyURCHBLqfQZhYQq%2BiIMt3D3s%3D&reserved=0 > > > > > > > > > > > > Issue reported by Coccinelle script: > > > > > > scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci > > > > > > > > > > > > Signed-off-by: Deepak R Varma <mh12gx2825@xxxxxxxxx> > > > > > > --- > > > > > > Please Note: This is a Outreachy project task patch. > > > > > > > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 20 ++++++++++---------- > > > > > > 1 file changed, 10 insertions(+), 10 deletions(-) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > > > index 2d125b8b15ee..f076b1ba7319 100644 > > > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > > > @@ -1551,29 +1551,29 @@ static int amdgpu_debugfs_sclk_set(void *data, u64 val) > > > > > > return 0; > > > > > > } > > > > > > -DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL, > > > > > > - amdgpu_debugfs_ib_preempt, "%llu\n"); > > > > > > +DEFINE_DEBUGFS_ATTRIBUTE(fops_ib_preempt, NULL, > > > > > > + amdgpu_debugfs_ib_preempt, "%llu\n"); > > > > > Are you sure this is ok? Do these devices need this additional > > > > > "protection"? Do they have the problem that these macros were written > > > > > for? > > > > > > > > > > Same for the other patches you just submitted here, I think you need to > > > > > somehow "prove" that these changes are necessary, checkpatch isn't able > > > > > to determine this all the time. > > > > Hi Greg, > > > > Based on my understanding, the current function debugfs_create_file() > > > > adds an overhead of lifetime managing proxy for such fop structs. This > > > > should be applicable to these set of drivers as well. Hence I think this > > > > change will be useful. > > > > > > Well since this is only created once per device instance I don't really care > > > about this little overhead. > > > > > > But what exactly is debugfs doing or not doing here? > > > > It is trying to save drivers from having debugfs files open that point > > to memory that can go away at any time. For graphics devices, I doubt > > that is the case. > > So for anything we add/remove we have two-stage cleanup > > 1. drm_dev_unregister (or drm_connector_unregisters, those are the only > two hotunpluggable things we have) unregister all the uapi interfaces. > This deletes all the sysfs and debugfs files. > > 2. Once all the references to the underlying object disappear from the > kernel, we free up the data structure. > > Now for chardev and similar uapi, we hold full references for open files. > But for sysfs and debugfs we assume that those uapi layers will make sure > that after we deleted the files in step 1 all access through these > functions are guaranteed to have finished. If that's not the case, then we > need to rework our refcounting and also refcount the underlying drm > structure (drm_device or drm_connector) from sysfs/debugfs files. > > Now I tried to look at the patch Deepak references, and I'm not really > clear what changes. Or whether we made a wrong assumption previously about > what debugfs/sysfs guarantee when we delete the files. I read some more code and kerneldoc, and I still have no idea what this new _unsafe variant is used for. Only ones I've found seem to use debugfs_file_get/put like the normal variant, to protect against concurrently removed files due to hotunplug. Which is kinda what we've been expecting debugfs to do for us. What's a use-case for _unsafe _without_ debugfs_file_get/put? Decently confused me over here doesn't get this. -Daniel > -Daniel > > > > > thanks, > > > > greg k-h > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
