drivers/cpufreq/scmi-cpufreq.c | 10 ++++++++-- drivers/cpufreq/scpi-cpufreq.c | 13 ++++++++++--- 2 files changed, 18 insertions(+), 5 deletions(-)
This series fixes potential NULL pointer dereferences in scmi_cpufreq_get_rate() and scpi_cpufreq_get_rate() when cpufreq_cpu_get_raw() returns NULL. Henry Martin (2): cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate() cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate() drivers/cpufreq/scmi-cpufreq.c | 10 ++++++++-- drivers/cpufreq/scpi-cpufreq.c | 13 ++++++++++--- 2 files changed, 18 insertions(+), 5 deletions(-) -- 2.34.1
On 08-04-25, 23:03, Henry Martin wrote: > This series fixes potential NULL pointer dereferences in scmi_cpufreq_get_rate() > and scpi_cpufreq_get_rate() when cpufreq_cpu_get_raw() returns NULL. > > Henry Martin (2): > cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate() > cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate() > > drivers/cpufreq/scmi-cpufreq.c | 10 ++++++++-- > drivers/cpufreq/scpi-cpufreq.c | 13 ++++++++++--- > 2 files changed, 18 insertions(+), 5 deletions(-) Applied. Thanks. -- viresh
On Tue, Apr 08, 2025 at 11:03:52PM +0800, Henry Martin wrote: > This series fixes potential NULL pointer dereferences in scmi_cpufreq_get_rate() > and scpi_cpufreq_get_rate() when cpufreq_cpu_get_raw() returns NULL. > Acked-by: Sudeep Holla <sudeep.holla@arm.com> I think unlikely is needed even in this patch[1] and thats what Viresh meant when he mention all similar changes under one series and consistent change. Also I just happened to notice similar patches posted while ago[2][3]. Not sure how to handle the situation though. -- Regards, Sudeep [1] https://lore.kernel.org/all/20250405061927.75485-1-bsdhenrymartin@gmail.com/ [2] https://lore.kernel.org/all/20241230093159.258813-1-hanchunchao@inspur.com [3] https://lore.kernel.org/all/20241230090137.243825-1-hanchunchao@inspur.com
> I think unlikely is needed even in this patch[1] and thats what Viresh > meant when he mention all similar changes under one series and consistent > change. Thanks for reviewing. I'll send v2 of patch[1] soon. Sudeep Holla <sudeep.holla@arm.com> 于2025年4月9日周三 19:30写道： > > On Tue, Apr 08, 2025 at 11:03:52PM +0800, Henry Martin wrote: > > This series fixes potential NULL pointer dereferences in scmi_cpufreq_get_rate() > > and scpi_cpufreq_get_rate() when cpufreq_cpu_get_raw() returns NULL. > > > > Acked-by: Sudeep Holla <sudeep.holla@arm.com> > > I think unlikely is needed even in this patch[1] and thats what Viresh > meant when he mention all similar changes under one series and consistent > change. > > Also I just happened to notice similar patches posted while ago[2][3]. > Not sure how to handle the situation though. > > -- > Regards, > Sudeep > > [1] https://lore.kernel.org/all/20250405061927.75485-1-bsdhenrymartin@gmail.com/ > [2] https://lore.kernel.org/all/20241230093159.258813-1-hanchunchao@inspur.com > [3] https://lore.kernel.org/all/20241230090137.243825-1-hanchunchao@inspur.com
> This series fixes potential NULL pointer dereferences in scmi_cpufreq_get_rate() > and scpi_cpufreq_get_rate() when cpufreq_cpu_get_raw() returns NULL. > > Henry Martin (2): > cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate() > cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate() Can any other summary phrase variants become more desirable accordingly? Regards, Markus
On Tue, Apr 08, 2025 at 09:23:35PM +0200, Markus Elfring wrote: > > This series fixes potential NULL pointer dereferences in scmi_cpufreq_get_rate() > > and scpi_cpufreq_get_rate() when cpufreq_cpu_get_raw() returns NULL. > > > > Henry Martin (2): > > cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate() > > cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate() > > Can any other summary phrase variants become more desirable accordingly? > This is meaningless, sorry can't parse. Ignoring it as others in the community are doing already. -- Regards, Sudeep
>> Can any other summary phrase variants become more desirable accordingly? > > This is meaningless, sorry can't parse. Ignoring it as others in the > community are doing already. Do you care if the term “null pointer dereference” would be used in consistent ways? Regards, Markus
On Wed, Apr 09, 2025 at 01:48:33PM +0200, Markus Elfring wrote: > >> Can any other summary phrase variants become more desirable accordingly? I agree with Sudeep, the above sentence is completely incomprehensible to me > > > > This is meaningless, sorry can't parse. Ignoring it as others in the > > community are doing already. > Do you care if the term “null pointer dereference” would be used in consistent ways? > ...this is more comprehensible, but again I cannot grasp what's yor advice specifically on this commit message. Thanks, Cristian
>>>> Can any other summary phrase variants become more desirable accordingly? > > I agree with Sudeep, the above sentence is completely incomprehensible > to me Can any suggestions gain acceptance also for better summary phrases? >>> This is meaningless, sorry can't parse. Ignoring it as others in the >>> community are doing already. >> Do you care if the term “null pointer dereference” would be used in consistent ways? > > ...this is more comprehensible, Thanks for another bit of constructive information. > but again I cannot grasp what's yor advice > specifically on this commit message. May the usage of abbreviations be reconsidered once more also for such messages (in presented update steps)? Regards, Markus
On Wed, Apr 09, 2025 at 02:25:52PM +0200, Markus Elfring wrote: > >>>> Can any other summary phrase variants become more desirable accordingly? > > > > I agree with Sudeep, the above sentence is completely incomprehensible > > to me > > Can any suggestions gain acceptance also for better summary phrases? > > > > >>> This is meaningless, sorry can't parse. Ignoring it as others in the > >>> community are doing already. > >> Do you care if the term “null pointer dereference” would be used in consistent ways? > > > > ...this is more comprehensible, > > Thanks for another bit of constructive information. > > > > but again I cannot grasp what's yor advice > > specifically on this commit message. > May the usage of abbreviations be reconsidered once more also for such messages > (in presented update steps)? > Still can't understand you. Sorry for that. Alternatively, you can do what I sometimes do: just write the whole commit log as you would expect and see if that helps. I am sure that helps, so please do that. -- Regards, Sudeep
>> May the usage of abbreviations be reconsidered once more also for such messages >> (in presented update steps)? > > Still can't understand you. Sorry for that. … Will any communication challenges need further clarifications also according to wordings like the following? * null-ptr-deref * null pointer dereference Regards, Markus
© 2016 - 2025 Red Hat, Inc.