[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87o7ks2is9.wl-tiwai@suse.de>
Date: Tue, 04 Jul 2023 10:16:38 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: oe-kbuild@...ts.linux.dev,
Takashi Sakamoto <o-takashi@...amocchi.jp>, lkp@...el.com,
oe-kbuild-all@...ts.linux.dev, linux-kernel@...r.kernel.org,
Takashi Iwai <tiwai@...e.de>
Subject: Re: sound/firewire/amdtp-stream.c:1099 process_rx_packets() error: uninitialized symbol 'curr_cycle_time'.
On Mon, 03 Jul 2023 15:00:01 +0200,
Dan Carpenter wrote:
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: b25f62ccb490680a8cee755ac4528909395e0711
> commit: fef4e61b0b765b6d22badcd5b6575b159e7d510a ALSA: firewire-lib: extend tracepoints event including CYCLE_TIME of 1394 OHCI
> config: i386-randconfig-m021-20230701 (https://download.01.org/0day-ci/archive/20230701/202307011324.jFJ96dTo-lkp@intel.com/config)
> compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
> reproduce: (https://download.01.org/0day-ci/archive/20230701/202307011324.jFJ96dTo-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@...el.com>
> | Reported-by: Dan Carpenter <dan.carpenter@...aro.org>
> | Closes: https://lore.kernel.org/r/202307011324.jFJ96dTo-lkp@intel.com/
>
> New smatch warnings:
> sound/firewire/amdtp-stream.c:1099 process_rx_packets() error: uninitialized symbol 'curr_cycle_time'.
>
> Old smatch warnings:
> sound/firewire/amdtp-stream.c:944 generate_tx_packet_descs() error: uninitialized symbol 'curr_cycle_time'.
(snip)
> The curr_cycle_time variable is only going to be used if trace_amdtp_packet_enabled()
> is true. We would consider it a false positive if build_it_pkt_header()
> is inlined but a bug if it's not. (Technically passing uninitialized
> data is undefined behavior but if a function is inlined then it's not
> "passing" anything).
Yes, this is a false-positive, so no much worry needed. But it's hard
for compiler / checker to know it, and I guess that simply
initializing the variable would be the easiest workaround, after all.
thanks,
Takashi
Powered by blists - more mailing lists