Messages in this thread |  | | Subject | Re: [PATCH v2] mm: cma: support sysfs | From | John Hubbard <> | Date | Mon, 8 Feb 2021 22:27:24 -0800 |
| |
On 2/8/21 10:13 PM, Greg KH wrote: > On Mon, Feb 08, 2021 at 05:57:17PM -0800, John Hubbard wrote: >> On 2/8/21 3:36 PM, Minchan Kim wrote: >> ... >>>>> char name[CMA_MAX_NAME]; >>>>> +#ifdef CONFIG_CMA_SYSFS >>>>> + struct cma_stat *stat; >>>> >>>> This should not be a pointer. By making it a pointer, you've added a bunch of pointless >>>> extra code to the implementation. >>> >>> Originally, I went with the object lifetime with struct cma as you >>> suggested to make code simple. However, Greg KH wanted to have >>> release for kobj_type since it is consistent with other kboject >>> handling. >> >> Are you talking about the kobj in your new struct cma_stat? That seems >> like circular logic if so. I'm guessing Greg just wanted kobj methods >> to be used *if* you are dealing with kobjects. That's a narrower point. >> >> I can't imagine that he would have insisted on having additional >> allocations just so that kobj freeing methods could be used. :) > > Um, yes, I was :) > > You can not add a kobject to a structure and then somehow think you can > just ignore the reference counting issues involved. If a kobject is > part of a structure then the kobject is responsible for controling the > lifespan of the memory, nothing else can be. > > So by making the kobject dynamic, you properly handle that memory > lifespan of the object, instead of having to worry about the lifespan of > the larger object (which the original patch was not doing.) > > Does that make sense? > That part makes sense, yes, thanks. The part that I'm trying to straighten out is, why was kobject even added to the struct cma_stat in the first place? Why not just leave .stat as a static member variable, without a kobject in it, and done?
thanks, -- John Hubbard NVIDIA
|  |