netdev - RE: [PATCH 0/2] ravb and sh_eth: Fix descriptor counters' conditions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <TY2PR01MB36925FE05E8E3A53970EE2C1D8EB9@TY2PR01MB3692.jpnprd01.prod.outlook.com>
Date:   Thu, 29 Jul 2021 04:59:37 +0000
From:   Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>
To:     "sergei.shtylyov@...il.com" <sergei.shtylyov@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>
Subject: RE: [PATCH 0/2] ravb and sh_eth: Fix descriptor counters' conditions

Hi all,

> From: Yoshihiro Shimoda, Sent: Tuesday, July 27, 2021 5:22 PM
> 
> When we change the type of {cur,dirty}_tx from u32 to u8, we can
> reproduce this issue easily.

I'm afraid but I would like to recall this patch series because
the original code didn't have any issue around these counters
so that the patch series should not be applied.

For just a record, I tried to write why I misunderstood these counters are incorrect below:
- I got a report locally about an issue happen when the system sends/receives data in long time transfer
- So, I doubted these counters' overflow.
- To reproduce the issue quickly, I changed the type from u32 to u8.
- And then, the following condition will not work correctly (as I mentioned on the patch).

       for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; priv->dirty_tx[q]++) { --- [1]

- Also, I found if we used "> 0U" instead of "0", the issue disappeared.

       for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0U; priv->dirty_tx[q]++) { --- [2]
                                                   ~~
- However, today I got a report from our team member locally. The object code of
  the get_num_desc() is just "from - subtract".

- If we use u32 as the original code, I realized the object codes between [1] and [2]
  are the same.
- Also, I realized just priv->cur_tx[q] - priv->dirty_tx[q] is no problem.
- So, I would like to recall this patch series.

Best regards,
Yoshihiro Shimoda