| Message ID | 20250408150354.104532-1-bsdhenrymartin@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | cpufreq: scmi/scpi: Fix NULL pointer dereference in get_rate() | expand |
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.
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.
>> 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
> 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
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.
>> 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
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.