On Fri, Mar 31, 2023 at 10:14:11AM +0300, Péter Ujfalusi wrote:
Hi Dan,
On 31/03/2023 09:58, Dan Carpenter wrote:
Hello Guennadi Liakhovetski,
This is a semi-automatic email about new static checker warnings.
The patch e3720f92e023: "ASoC: SOF: avoid a NULL dereference with unsupported widgets" from Mar 29, 2023, leads to the following Smatch complaint:
sound/soc/sof/ipc4-topology.c:2353 sof_ipc4_route_setup() error: we previously assumed 'sink_fw_module' could be null (see line 2351)
sound/soc/sof/ipc4-topology.c:2353 sof_ipc4_route_setup() error: we previously assumed 'src_fw_module' could be null (see line 2351)
sound/soc/sof/ipc4-topology.c 2350 2351 if (!src_fw_module || !sink_fw_module) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ One of these is NULL.
2352 /* The NULL module will print as "(efault)" */ 2353 dev_err(sdev->dev, "source %s or sink %s widget weren't set up properly\n", 2354 src_fw_module->man4_module_entry.name, 2355 sink_fw_module->man4_module_entry.name); ^^^^^^^^^^^^^^ Both are dereferenced. The comment is very puzzling.
if src_fw_module is NULL then the print will be: source (efault) or sink sink.module.name widget weren't set up properly
Guennadi is relying on some black magic in the printk system to handle the printing instead of open coding.
I've done compiler related work and explored some weird aspect of the C language and I am so fascinated by this. I would have thought it crashes before the function is called. I cannot even imagine how black magic like this would work.
Is there anyway I can test this?
regards, dan carpenter