Re: [PATCH 4/6+] cpufreq: Use struct kobj_attribute instead of struct global_attr

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

 



On Thu, Mar 07, 2019 at 07:38:07PM +0530, Viresh Kumar wrote:
> On 07-03-19, 13:21, Greg KH wrote:
> > On Thu, Mar 07, 2019 at 04:52:52PM +0530, Viresh Kumar wrote:
> > > commit 625c85a62cb7d3c79f6e16de3cfa972033658250 upstream.
> > > 
> > > The cpufreq_global_kobject is created using kobject_create_and_add()
> > > helper, which assigns the kobj_type as dynamic_kobj_ktype and show/store
> > > routines are set to kobj_attr_show() and kobj_attr_store().
> > > 
> > > These routines pass struct kobj_attribute as an argument to the
> > > show/store callbacks. But all the cpufreq files created using the
> > > cpufreq_global_kobject expect the argument to be of type struct
> > > attribute. Things work fine currently as no one accesses the "attr"
> > > argument. We may not see issues even if the argument is used, as struct
> > > kobj_attribute has struct attribute as its first element and so they
> > > will both get same address.
> > > 
> > > But this is logically incorrect and we should rather use struct
> > > kobj_attribute instead of struct global_attr in the cpufreq core and
> > > drivers and the show/store callbacks should take struct kobj_attribute
> > > as argument instead.
> > > 
> > > This bug is caught using CFI CLANG builds in android kernel which
> > > catches mismatch in function prototypes for such callbacks.
> > > 
> > > Cc: 4.6+ <stable@xxxxxxxxxxxxxxx> # 4.6+
> > > Reported-by: Donghee Han <dh.han@xxxxxxxxxxx>
> > > Reported-by: Sangkyu Kim <skwith.kim@xxxxxxxxxxx>
> > > Signed-off-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> > > 
> > > ---
> > > This needs to be applied from v4.6 to v4.9 (including both).
> > 
> > Does not apply to the 4.9.y stable queue :(
> > 
> > Are you sure you backported this correctly?  No need to care about 4.6.
> 
> Same as 4.4, attached is the patch which I just now applied on
> 4.9.161. Git cherry-pick was able to figure it out just fine.

I can not use git cherry-pick when you give me a patch to apply :(




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux