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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230813105804.2r4zdr6dyqe5dsrf@skbuf>
Date: Sun, 13 Aug 2023 13:58:04 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Alfred Lee <l00g33k@...il.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, andrew@...n.ch,
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, sgarzare@...hat.com, AVKrasnov@...rdevices.ru
Subject: Re: [PATCH v2 net] net: dsa: mv88e6xxx: Wait for EEPROM done before
 HW reset

Hi Alfred,

On Fri, Aug 11, 2023 at 04:28:32PM -0700, Alfred Lee wrote:
> If the switch is reset during active EEPROM transactions, as in
> just after an SoC reset after power up, the I2C bus transaction
> may be cut short leaving the EEPROM internal I2C state machine
> in the wrong state.  When the switch is reset again, the bad
> state machine state may result in data being read from the wrong
> memory location causing the switch to enter unexpect mode
> rendering it inoperational.
> 
> Fixes: 8abbffd27ced ("net: dsa: mv88e6xxx: Wait for EEPROM done after HW reset")
> Signed-off-by: Alfred Lee <l00g33k@...il.com>
> ---

I don't think you understand the meaning of the Fixes: tag. It is
supposed to point to the first commit where the issue being fixed
started being visible. But git show 8abbffd27ced shows:

commit 8abbffd27cedd0f89f69e5ee2ff6841ea01511eb
Author: Arseniy Krasnov <AVKrasnov@...rdevices.ru>
Date:   Tue Jan 10 10:18:32 2023 +0000

    test/vsock: vsock_perf utility

    This adds utility to check vsock rx/tx performance.

    Usage as sender:
    ./vsock_perf --sender <cid> --port <port> --bytes <bytes to send>
    Usage as receiver:
    ./vsock_perf --port <port> --rcvlowat <SO_RCVLOWAT>

    Signed-off-by: Arseniy Krasnov <AVKrasnov@...rdevices.ru>
    Reviewed-by: Stefano Garzarella <sgarzare@...hat.com>
    Signed-off-by: Paolo Abeni <pabeni@...hat.com>

So:
1 - that has nothing to do with mv88e6xxx, so it cannot have introduced
    the issue here
2 - there is a mismatch between the blamed commit sha1sum and the blamed
    commit message. In fact, the blamed commit message is _your_ commit
    message, which is not correct.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ