On 07-03-19, 16:18, Greg KH wrote: > 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 :( Yeah, I just expected git am to be smart enough to not report errors where git cherry-pick works fine. Thanks for applying the patches though. -- viresh
