[PATCH 0/2] md: Replace snprintf with scnprintf

[Stefan Bader]

On 18.10.22 17:13, Tim Gardner wrote:
> BugLink: https://bugs.launchpad.net/bugs/1993315
> 
> SRU Justification
> 
> While this patch was originally requested by the Microsoft Azure team, it seems
> appropriate for the generic kernel as well.

In my joyful morning mood I am tempted to NACK this for formal reasons. Why does 
the cover email not contain any indication where it should go to? Why do the 
patches invent yet another way to define where they apply to?

Andrea, Cory,

that would be a question which you could ask. Ideally (and I thought that was 
what is documented) this should have looked like:

[SRU K/J/F][PATCH 0/1] ...
- [SRU K][PATCH 1/1] ...
- [SRU J/F][PATCH 1/1] ...

If that was not for the primary kernel (or if one wants to be explicit) it 
should be more like the handle format, so "K:linux" or "J/F:linux". There is 
already use of source names without series mixed with series which is a bit of a 
pain to read.

Note that this is "Re" and not "NACK".

-Stefan

> 
> [Impact]
> Current code produces a warning as shown below when total characters
> in the constituent block device names plus the slashes exceeds 200.
> snprintf() returns the number of characters generated from the given
> input, which could cause the expression “200 – len” to wrap around
> to a large positive number. Fix this by using scnprintf() instead,
> which returns the actual number of characters written into the buffer.
> 
> [ 1513.267938] ------------[ cut here ]------------
> [ 1513.267943] WARNING: CPU: 15 PID: 37247 at <snip>/lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510
> [ 1513.267944] Modules linked in: <snip>
> [ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure #90~18.04.1-Ubuntu
> [ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022
> [ 1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510
> <-snip->
> [ 1513.267982] Call Trace:
> [ 1513.267986] snprintf+0x45/0x70
> [ 1513.267990] ? disk_name+0x71/0xa0
> [ 1513.267993] dump_zones+0x114/0x240 [raid0]
> [ 1513.267996] ? _cond_resched+0x19/0x40
> [ 1513.267998] raid0_run+0x19e/0x270 [raid0]
> [ 1513.268000] md_run+0x5e0/0xc50
> [ 1513.268003] ? security_capable+0x3f/0x60
> [ 1513.268005] do_md_run+0x19/0x110
> [ 1513.268006] md_ioctl+0x195e/0x1f90
> [ 1513.268007] blkdev_ioctl+0x91f/0x9f0
> [ 1513.268010] block_ioctl+0x3d/0x50
> [ 1513.268012] do_vfs_ioctl+0xa9/0x640
> [ 1513.268014] ? __fput+0x162/0x260
> [ 1513.268016] ksys_ioctl+0x75/0x80
> [ 1513.268017] __x64_sys_ioctl+0x1a/0x20
> [ 1513.268019] do_syscall_64+0x5e/0x200
> [ 1513.268021] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> 
> [Fix]
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=1727fd5015d8f93474148f94e34cda5aa6ad4a43
> 
> [Where things could go wrong]
> 
> This seems unlikely to cause a regression. At worst the output could be garbled when
> dumping zones.
> 
> [Other Info]
> 
> SF: #00346036
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20221019/52b33072/attachment.sig>