RE: [PATCH 5.10 1/1] rpmsg: qcom: glink: replace strncpy() with strscpy_pad()

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

 



From: Greg Kroah-Hartman
> Sent: 07 October 2022 17:40
> 
> On Fri, Oct 07, 2022 at 04:29:31PM +0300, Andrew Chernyakov wrote:
> > From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
> >
> > commit 766279a8f85df32345dbda03b102ca1ee3d5ddea upstream.
> >
> > The use of strncpy() is considered deprecated for NUL-terminated
> > strings[1]. Replace strncpy() with strscpy_pad(), to keep existing
> > pad-behavior of strncpy, similarly to commit 08de420a8014 ("rpmsg:
> > glink: Replace strncpy() with strscpy_pad()").  This fixes W=1 warning:
> >
> >   In function ‘qcom_glink_rx_close’,
> >     inlined from ‘qcom_glink_work’ at ../drivers/rpmsg/qcom_glink_native.c:1638:4:
> >   drivers/rpmsg/qcom_glink_native.c:1549:17: warning: ‘strncpy’ specified bound 32 equals
> destination size [-Wstringop-truncation]
> >    1549 |                 strncpy(chinfo.name, channel->name, sizeof(chinfo.name));
> >
> > [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
> >
> > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
> > Reviewed-by: Stephen Boyd <sboyd@xxxxxxxxxx>
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx>
> > Link: https://lore.kernel.org/r/20220519073330.7187-1-krzysztof.kozlowski@xxxxxxxxxx
> > Signed-off-by: Andrew Chernyakov <acherniakov@xxxxxxxxxxxxx>
> > ---
> >  drivers/rpmsg/qcom_glink_native.c | 2 +-
> >  drivers/rpmsg/qcom_smd.c          | 4 ++--
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> Why just this specific kernel branch?  We can't add patches to an older
> tree and have someone upgrade to a newer one and hit the same issue.
> 
> So please provide backports for all active versions.  In this case that
> would be 5.15.y and 5.19.y.

If it is only fixing a compile warning is it even stable material?
The generic commit message doesn't say whether the old code was
actually right or wrong.

At least one of these 'replace strncpy()' changes was definitely
broken (the copy needed to be equivalent to memcpy()).

So applying ANY of them to stable unless they actually fix
a real bug seems dubious.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux