<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/lib, branch v5.4.251</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.251</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.251'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2023-07-27T06:37:41Z</updated>
<entry>
<title>debugobjects: Recheck debug_objects_enabled before reporting</title>
<updated>2023-07-27T06:37:41Z</updated>
<author>
<name>Tetsuo Handa</name>
<email>penguin-kernel@I-love.SAKURA.ne.jp</email>
</author>
<published>2023-06-07T10:19:02Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d4f1cd9b9d664121533783097c76b70be0bf8c45'/>
<id>urn:sha1:d4f1cd9b9d664121533783097c76b70be0bf8c45</id>
<content type='text'>
[ Upstream commit 8b64d420fe2450f82848178506d3e3a0bd195539 ]

syzbot is reporting false a positive ODEBUG message immediately after
ODEBUG was disabled due to OOM.

  [ 1062.309646][T22911] ODEBUG: Out of memory. ODEBUG disabled
  [ 1062.886755][ T5171] ------------[ cut here ]------------
  [ 1062.892770][ T5171] ODEBUG: assert_init not available (active state 0) object: ffffc900056afb20 object type: timer_list hint: process_timeout+0x0/0x40

  CPU 0 [ T5171]                CPU 1 [T22911]
  --------------                --------------
  debug_object_assert_init() {
    if (!debug_objects_enabled)
      return;
    db = get_bucket(addr);
                                lookup_object_or_alloc() {
                                  debug_objects_enabled = 0;
                                  return NULL;
                                }
                                debug_objects_oom() {
                                  pr_warn("Out of memory. ODEBUG disabled\n");
                                  // all buckets get emptied here, and
                                }
    lookup_object_or_alloc(addr, db, descr, false, true) {
      // this bucket is already empty.
      return ERR_PTR(-ENOENT);
    }
    // Emits false positive warning.
    debug_print_object(&amp;o, "assert_init");
  }

Recheck debug_object_enabled in debug_print_object() to avoid that.

Reported-by: syzbot &lt;syzbot+7937ba6a50bdd00fffdf@syzkaller.appspotmail.com&gt;
Suggested-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lore.kernel.org/r/492fe2ae-5141-d548-ebd5-62f5fe2e57f7@I-love.SAKURA.ne.jp
Closes: https://syzkaller.appspot.com/bug?extid=7937ba6a50bdd00fffdf
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>lib/ts_bm: reset initial match offset for every block of text</title>
<updated>2023-07-27T06:37:12Z</updated>
<author>
<name>Jeremy Sowden</name>
<email>jeremy@azazel.net</email>
</author>
<published>2023-06-19T19:06:57Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=32deadf8943065609d8d88a9a41e93abe4715bed'/>
<id>urn:sha1:32deadf8943065609d8d88a9a41e93abe4715bed</id>
<content type='text'>
[ Upstream commit 6f67fbf8192da80c4db01a1800c7fceaca9cf1f9 ]

The `shift` variable which indicates the offset in the string at which
to start matching the pattern is initialized to `bm-&gt;patlen - 1`, but it
is not reset when a new block is retrieved.  This means the implemen-
tation may start looking at later and later positions in each successive
block and miss occurrences of the pattern at the beginning.  E.g.,
consider a HTTP packet held in a non-linear skb, where the HTTP request
line occurs in the second block:

  [... 52 bytes of packet headers ...]
  GET /bmtest HTTP/1.1\r\nHost: www.example.com\r\n\r\n

and the pattern is "GET /bmtest".

Once the first block comprising the packet headers has been examined,
`shift` will be pointing to somewhere near the end of the block, and so
when the second block is examined the request line at the beginning will
be missed.

Reinitialize the variable for each new block.

Fixes: 8082e4ed0a61 ("[LIB]: Boyer-Moore extension for textsearch infrastructure strike #2")
Link: https://bugzilla.netfilter.org/show_bug.cgi?id=1390
Signed-off-by: Jeremy Sowden &lt;jeremy@azazel.net&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>test_firmware: fix a memory leak with reqs buffer</title>
<updated>2023-06-21T13:44:08Z</updated>
<author>
<name>Mirsad Goran Todorovac</name>
<email>mirsad.todorovac@alu.unizg.hr</email>
</author>
<published>2023-05-09T08:47:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=75d9e00f65cd2e0f2ce9ceeb395f821976773489'/>
<id>urn:sha1:75d9e00f65cd2e0f2ce9ceeb395f821976773489</id>
<content type='text'>
[ Upstream commit be37bed754ed90b2655382f93f9724b3c1aae847 ]

Dan Carpenter spotted that test_fw_config-&gt;reqs will be leaked if
trigger_batched_requests_store() is called two or more times.
The same appears with trigger_batched_requests_async_store().

This bug wasn't trigger by the tests, but observed by Dan's visual
inspection of the code.

The recommended workaround was to return -EBUSY if test_fw_config-&gt;reqs
is already allocated.

Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
Cc: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Russ Weight &lt;russell.h.weight@intel.com&gt;
Cc: Tianfei Zhang &lt;tianfei.zhang@intel.com&gt;
Cc: Shuah Khan &lt;shuah@kernel.org&gt;
Cc: Colin Ian King &lt;colin.i.king@gmail.com&gt;
Cc: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: linux-kselftest@vger.kernel.org
Cc: stable@vger.kernel.org # v5.4
Suggested-by: Dan Carpenter &lt;error27@gmail.com&gt;
Suggested-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Mirsad Goran Todorovac &lt;mirsad.todorovac@alu.unizg.hr&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Acked-by: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Link: https://lore.kernel.org/r/20230509084746.48259-2-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>lib: cpu_rmap: Fix potential use-after-free in irq_cpu_rmap_release()</title>
<updated>2023-06-14T08:59:56Z</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2023-06-02T18:28:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a6ca812973923229e1582efd1c8e221b4382308a'/>
<id>urn:sha1:a6ca812973923229e1582efd1c8e221b4382308a</id>
<content type='text'>
[ Upstream commit 7c5d4801ecf0564c860033d89726b99723c55146 ]

irq_cpu_rmap_release() calls cpu_rmap_put(), which may free the rmap.
So we need to clear the pointer to our glue structure in rmap before
doing that, not after.

Fixes: 4e0473f1060a ("lib: cpu_rmap: Avoid use after free on rmap-&gt;obj array entries")
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Reviewed-by: Simon Horman &lt;simon.horman@corigine.com&gt;
Link: https://lore.kernel.org/r/ZHo0vwquhOy3FaXc@decadent.org.uk
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>test_firmware: fix the memory leak of the allocated firmware buffer</title>
<updated>2023-06-09T08:29:03Z</updated>
<author>
<name>Mirsad Goran Todorovac</name>
<email>mirsad.todorovac@alu.unizg.hr</email>
</author>
<published>2023-05-09T08:47:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=94f3bc7e84af2f17dbfbc7afe93991c2a6f2f25e'/>
<id>urn:sha1:94f3bc7e84af2f17dbfbc7afe93991c2a6f2f25e</id>
<content type='text'>
commit 48e156023059e57a8fc68b498439832f7600ffff upstream.

The following kernel memory leak was noticed after running
tools/testing/selftests/firmware/fw_run_tests.sh:

[root@pc-mtodorov firmware]# cat /sys/kernel/debug/kmemleak
.
.
.
unreferenced object 0xffff955389bc3400 (size 1024):
  comm "test_firmware-0", pid 5451, jiffies 4294944822 (age 65.652s)
  hex dump (first 32 bytes):
    47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00  GH4567..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff962f5dec&gt;] slab_post_alloc_hook+0x8c/0x3c0
    [&lt;ffffffff962fcca4&gt;] __kmem_cache_alloc_node+0x184/0x240
    [&lt;ffffffff962704de&gt;] kmalloc_trace+0x2e/0xc0
    [&lt;ffffffff9665b42d&gt;] test_fw_run_batch_request+0x9d/0x180
    [&lt;ffffffff95fd813b&gt;] kthread+0x10b/0x140
    [&lt;ffffffff95e033e9&gt;] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c334b400 (size 1024):
  comm "test_firmware-1", pid 5452, jiffies 4294944822 (age 65.652s)
  hex dump (first 32 bytes):
    47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00  GH4567..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff962f5dec&gt;] slab_post_alloc_hook+0x8c/0x3c0
    [&lt;ffffffff962fcca4&gt;] __kmem_cache_alloc_node+0x184/0x240
    [&lt;ffffffff962704de&gt;] kmalloc_trace+0x2e/0xc0
    [&lt;ffffffff9665b42d&gt;] test_fw_run_batch_request+0x9d/0x180
    [&lt;ffffffff95fd813b&gt;] kthread+0x10b/0x140
    [&lt;ffffffff95e033e9&gt;] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c334f000 (size 1024):
  comm "test_firmware-2", pid 5453, jiffies 4294944822 (age 65.652s)
  hex dump (first 32 bytes):
    47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00  GH4567..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff962f5dec&gt;] slab_post_alloc_hook+0x8c/0x3c0
    [&lt;ffffffff962fcca4&gt;] __kmem_cache_alloc_node+0x184/0x240
    [&lt;ffffffff962704de&gt;] kmalloc_trace+0x2e/0xc0
    [&lt;ffffffff9665b42d&gt;] test_fw_run_batch_request+0x9d/0x180
    [&lt;ffffffff95fd813b&gt;] kthread+0x10b/0x140
    [&lt;ffffffff95e033e9&gt;] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c3348400 (size 1024):
  comm "test_firmware-3", pid 5454, jiffies 4294944822 (age 65.652s)
  hex dump (first 32 bytes):
    47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00  GH4567..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff962f5dec&gt;] slab_post_alloc_hook+0x8c/0x3c0
    [&lt;ffffffff962fcca4&gt;] __kmem_cache_alloc_node+0x184/0x240
    [&lt;ffffffff962704de&gt;] kmalloc_trace+0x2e/0xc0
    [&lt;ffffffff9665b42d&gt;] test_fw_run_batch_request+0x9d/0x180
    [&lt;ffffffff95fd813b&gt;] kthread+0x10b/0x140
    [&lt;ffffffff95e033e9&gt;] ret_from_fork+0x29/0x50
[root@pc-mtodorov firmware]#

Note that the size 1024 corresponds to the size of the test firmware
buffer. The actual number of the buffers leaked is around 70-110,
depending on the test run.

The cause of the leak is the following:

request_partial_firmware_into_buf() and request_firmware_into_buf()
provided firmware buffer isn't released on release_firmware(), we
have allocated it and we are responsible for deallocating it manually.
This is introduced in a number of context where previously only
release_firmware() was called, which was insufficient.

Reported-by: Mirsad Goran Todorovac &lt;mirsad.todorovac@alu.unizg.hr&gt;
Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Dan Carpenter &lt;error27@gmail.com&gt;
Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Luis Chamberlain &lt;mcgrof@kernel.org&gt;
Cc: Russ Weight &lt;russell.h.weight@intel.com&gt;
Cc: Tianfei zhang &lt;tianfei.zhang@intel.com&gt;
Cc: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Cc: Zhengchao Shao &lt;shaozhengchao@huawei.com&gt;
Cc: Colin Ian King &lt;colin.i.king@gmail.com&gt;
Cc: linux-kernel@vger.kernel.org
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Scott Branden &lt;sbranden@broadcom.com&gt;
Cc: Luis R. Rodriguez &lt;mcgrof@kernel.org&gt;
Cc: linux-kselftest@vger.kernel.org
Cc: stable@vger.kernel.org # v5.4
Signed-off-by: Mirsad Goran Todorovac &lt;mirsad.todorovac@alu.unizg.hr&gt;
Link: https://lore.kernel.org/r/20230509084746.48259-3-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>lib/dynamic_debug.c: use address-of operator on section symbols</title>
<updated>2023-06-09T08:29:02Z</updated>
<author>
<name>Nathan Chancellor</name>
<email>natechancellor@gmail.com</email>
</author>
<published>2020-04-07T03:10:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=843f517667845595694aec4d52fd4f6bd4c1a20f'/>
<id>urn:sha1:843f517667845595694aec4d52fd4f6bd4c1a20f</id>
<content type='text'>
commit 8306b057a85ec07482da5d4b99d5c0b47af69be1 upstream.

Clang warns:

../lib/dynamic_debug.c:1034:24: warning: array comparison always
evaluates to false [-Wtautological-compare]
        if (__start___verbose == __stop___verbose) {
                              ^
1 warning generated.

These are not true arrays, they are linker defined symbols, which are just
addresses.  Using the address of operator silences the warning and does
not change the resulting assembly with either clang/ld.lld or gcc/ld
(tested with diff + objdump -Dr).

Suggested-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Signed-off-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Acked-by: Jason Baron &lt;jbaron@akamai.com&gt;
Link: https://github.com/ClangBuiltLinux/linux/issues/894
Link: http://lkml.kernel.org/r/20200220051320.10739-1-natechancellor@gmail.com
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>treewide: Remove uninitialized_var() usage</title>
<updated>2023-06-09T08:29:01Z</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2020-06-03T20:09:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0638dcc7e75fbb766761e7b4694d0f0f141bbbd1'/>
<id>urn:sha1:0638dcc7e75fbb766761e7b4694d0f0f141bbbd1</id>
<content type='text'>
commit 3f649ab728cda8038259d8f14492fe400fbab911 upstream.

Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.

In preparation for removing[2] the[3] macro[4], remove all remaining
needless uses with the following script:

git grep '\buninitialized_var\b' | cut -d: -f1 | sort -u | \
	xargs perl -pi -e \
		's/\buninitialized_var\(([^\)]+)\)/\1/g;
		 s:\s*/\* (GCC be quiet|to make compiler happy) \*/$::g;'

drivers/video/fbdev/riva/riva_hw.c was manually tweaked to avoid
pathological white-space.

No outstanding warnings were found building allmodconfig with GCC 9.3.0
for x86_64, i386, arm64, arm, powerpc, powerpc64le, s390x, mips, sparc64,
alpha, and m68k.

[1] https://lore.kernel.org/lkml/20200603174714.192027-1-glider@google.com/
[2] https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1TGqCR5vQkCzWJ0QxK6CernOU6eedsudAixw@mail.gmail.com/
[3] https://lore.kernel.org/lkml/CA+55aFwgbgqhbp1fkxvRKEpzyR5J8n1vKT1VZdz9knmPuXhOeg@mail.gmail.com/
[4] https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com/

Reviewed-by: Leon Romanovsky &lt;leonro@mellanox.com&gt; # drivers/infiniband and mlx4/mlx5
Acked-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt; # IB
Acked-by: Kalle Valo &lt;kvalo@codeaurora.org&gt; # wireless drivers
Reviewed-by: Chao Yu &lt;yuchao0@huawei.com&gt; # erofs
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>debugobjects: Don't wake up kswapd from fill_pool()</title>
<updated>2023-05-30T11:44:09Z</updated>
<author>
<name>Tetsuo Handa</name>
<email>penguin-kernel@I-love.SAKURA.ne.jp</email>
</author>
<published>2023-05-11T13:47:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=be646802b3dc408c4dc72a3ac32c3f4a0282414d'/>
<id>urn:sha1:be646802b3dc408c4dc72a3ac32c3f4a0282414d</id>
<content type='text'>
commit eb799279fb1f9c63c520fe8c1c41cb9154252db6 upstream.

syzbot is reporting a lockdep warning in fill_pool() because the allocation
from debugobjects is using GFP_ATOMIC, which is (__GFP_HIGH | __GFP_KSWAPD_RECLAIM)
and therefore tries to wake up kswapd, which acquires kswapd_wait::lock.

Since fill_pool() might be called with arbitrary locks held, fill_pool()
should not assume that acquiring kswapd_wait::lock is safe.

Use __GFP_HIGH instead and remove __GFP_NORETRY as it is pointless for
!__GFP_DIRECT_RECLAIM allocation.

Fixes: 3ac7fe5a4aab ("infrastructure to debug (dynamic) objects")
Reported-by: syzbot &lt;syzbot+fe0c72f0ccbb93786380@syzkaller.appspotmail.com&gt;
Signed-off-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lore.kernel.org/r/6577e1fa-b6ee-f2be-2414-a2b51b1c5e30@I-love.SAKURA.ne.jp
Closes: https://syzkaller.appspot.com/bug?extid=fe0c72f0ccbb93786380
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>lib: cpu_rmap: Avoid use after free on rmap-&gt;obj array entries</title>
<updated>2023-05-30T11:44:03Z</updated>
<author>
<name>Eli Cohen</name>
<email>elic@nvidia.com</email>
</author>
<published>2023-02-08T05:51:02Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cc2d2b3dbfb0ba57bc027fb7e1121250c50e4000'/>
<id>urn:sha1:cc2d2b3dbfb0ba57bc027fb7e1121250c50e4000</id>
<content type='text'>
[ Upstream commit 4e0473f1060aa49621d40a113afde24818101d37 ]

When calling irq_set_affinity_notifier() with NULL at the notify
argument, it will cause freeing of the glue pointer in the
corresponding array entry but will leave the pointer in the array. A
subsequent call to free_irq_cpu_rmap() will try to free this entry again
leading to possible use after free.

Fix that by setting NULL to the array entry and checking that we have
non-zero at the array entry when iterating over the array in
free_irq_cpu_rmap().

The current code does not suffer from this since there are no cases
where irq_set_affinity_notifier(irq, NULL) (note the NULL passed for the
notify arg) is called, followed by a call to free_irq_cpu_rmap() so we
don't hit and issue. Subsequent patches in this series excersize this
flow, hence the required fix.

Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Eli Cohen &lt;elic@nvidia.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@nvidia.com&gt;
Reviewed-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>linux/dim: Do nothing if no time delta between samples</title>
<updated>2023-05-30T11:44:01Z</updated>
<author>
<name>Roy Novich</name>
<email>royno@nvidia.com</email>
</author>
<published>2023-05-07T13:57:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=42e1dafa65e216a59fd0ea9dce5ebb59824803d6'/>
<id>urn:sha1:42e1dafa65e216a59fd0ea9dce5ebb59824803d6</id>
<content type='text'>
[ Upstream commit 162bd18eb55adf464a0fa2b4144b8d61c75ff7c2 ]

Add return value for dim_calc_stats. This is an indication for the
caller if curr_stats was assigned by the function. Avoid using
curr_stats uninitialized over {rdma/net}_dim, when no time delta between
samples. Coverity reported this potential use of an uninitialized
variable.

Fixes: 4c4dbb4a7363 ("net/mlx5e: Move dynamic interrupt coalescing code to include/linux")
Fixes: cb3c7fd4f839 ("net/mlx5e: Support adaptive RX coalescing")
Signed-off-by: Roy Novich &lt;royno@nvidia.com&gt;
Reviewed-by: Aya Levin &lt;ayal@nvidia.com&gt;
Reviewed-by: Saeed Mahameed &lt;saeedm@nvidia.com&gt;
Signed-off-by: Tariq Toukan &lt;tariqt@nvidia.com&gt;
Reviewed-by: Leon Romanovsky &lt;leonro@nvidia.com&gt;
Reviewed-by: Michal Kubiak &lt;michal.kubiak@intel.com&gt;
Link: https://lore.kernel.org/r/20230507135743.138993-1-tariqt@nvidia.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
