<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 5/20/26 12:02 AM, Kishore Padmanabha
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CA+BST0nKjhifTBgKgn7qjb2oGEb7XFq3Ejr75u0T9Lm_c0p1EQ@mail.gmail.com"><br>
      <div class="gmail_quote gmail_quote_container">
        <div dir="ltr" class="gmail_attr">On Tue, May 19, 2026 at
          12:44 AM Denis Sergeev <<a
            href="mailto:denserg.edu@gmail.com"
            class="moz-txt-link-freetext">denserg.edu@gmail.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The
          return value of tfc_em_delete_raw() in tfc_em_delete() was<br>
          silently discarded: rc was unconditionally overwritten by the<br>
          subsequent tfc_cpm_get_cmm_inst() call without any error
          check.<br>
          <br>
          If tfc_em_delete_raw() fails, the HW EM entry is not removed
          but<br>
          the function continues to free the corresponding SW pool
          entry,<br>
          creating a HW/SW state inconsistency that can lead to stale
          flow<br>
          matches or incorrect pool slot reuse.<br>
          <br>
          Add an error check after the call and return -EINVAL on
          failure.<br>
          <br>
          Found by Linux Verification Center (<a
            href="http://linuxtesting.org" rel="noreferrer"
            target="_blank">linuxtesting.org</a>) with SVACE.<br>
          <br>
          Fixes: 80317ff6adfd ("net/bnxt/tf_core: support Thor2")<br>
          Cc: <a href="mailto:stable@dpdk.org" target="_blank"
            class="moz-txt-link-freetext">stable@dpdk.org</a><br>
          <br>
          Signed-off-by: Denis Sergeev <<a
            href="mailto:denserg.edu@gmail.com" target="_blank"
            class="moz-txt-link-freetext">denserg.edu@gmail.com</a>><br>
          ---<br>
           drivers/net/bnxt/tf_core/v3/tfc_em.c | 5 +++++<br>
           1 file changed, 5 insertions(+)<br>
          <br>
          diff --git a/drivers/net/bnxt/tf_core/v3/tfc_em.c
          b/drivers/net/bnxt/tf_core/v3/tfc_em.c<br>
          index 3fe4dbe3fe..4c126dc2f4 100644<br>
          --- a/drivers/net/bnxt/tf_core/v3/tfc_em.c<br>
          +++ b/drivers/net/bnxt/tf_core/v3/tfc_em.c<br>
          @@ -661,6 +661,11 @@ int tfc_em_delete(struct tfc *tfcp,
          struct tfc_em_delete_parms *parms)<br>
                                         &db_offset<br>
           #endif<br>
                                         );<br>
          +       if (rc != 0) {<br>
          +               PMD_DRV_LOG_LINE(ERR, "tfc_em_delete_raw()
          failed: %s",<br>
          +                                strerror(-rc));<br>
          +               return -EINVAL;<br>
          +       }<br>
          <br>
                  record_offset =
          REMOVE_POOL_FROM_OFFSET(pi.lkup_pool_sz_exp,<br>
                                                         
          record_offset);<br>
        </blockquote>
        <div>This change is not required, even if deletion of the HW
          entry fails, it should continue to delete the SW state, since
          at the end all the HW entries are invalidated. Have you been
          able to reproduce a scenario where this failure is seen. </div>
        <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">--
          <br>
          2.50.1</blockquote>
      </div>
    </blockquote>
    <p
class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Thanks
      for the review. I'll drop this patch.</p>
    <p
class="font-claude-response-body break-words whitespace-normal leading-[1.7]">The
      issue was flagged by a static analyzer that caught the discarded<br>
      return value of tfc_em_delete_raw(). Over the past week I tried to<br>
      reproduce an actual failure at runtime, but I couldn't. So it
      seems<br>
      this failure doesn't occur in real runtime.</p>
    <pre class="moz-signature" cols="72">-- 
Best regards,
Denis Sergeev</pre>
  </body>
</html>