linux-kernel - Re: [PATCH 2/2] net: usb: ax88179_178a: avoid two consecutive device resets

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: <20231116141816.21950-1-jtornosm@redhat.com>
Date:   Thu, 16 Nov 2023 15:18:15 +0100
From:   Jose Ignacio Tornos Martinez <jtornosm@...hat.com>
To:     pabeni@...hat.com
Cc:     davem@...emloft.net, edumazet@...gle.com, jtornosm@...hat.com,
        kuba@...nel.org, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org, netdev@...r.kernel.org,
        weihao.bj@...system.com
Subject: Re: [PATCH 2/2] net: usb: ax88179_178a: avoid two consecutive device resets

On Thu, Nov 16, 2023 at 10:42 AM Paolo Abeni <pabeni@...hat.com> wrote:
> We need a suitable Fixes tag even here ;)
Ok, I will add it in my next version.

> > ---
> >  drivers/net/usb/ax88179_178a.c | 13 -------------
> >  1 file changed, 13 deletions(-)
> >
> > diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
> > index 4ea0e155bb0d..864c6fc2db33 100644
> > --- a/drivers/net/usb/ax88179_178a.c
> > +++ b/drivers/net/usb/ax88179_178a.c
> > @@ -1678,7 +1678,6 @@ static const struct driver_info ax88179_info = {
> >       .unbind = ax88179_unbind,
> >       .status = ax88179_status,
> >       .link_reset = ax88179_link_reset,
> > -     .reset = ax88179_reset,
> >       .stop = ax88179_stop,
> >       .flags = FLAG_ETHER | FLAG_FRAMING_AX,
> >       .rx_fixup = ax88179_rx_fixup,
>
> This looks potentially dangerous, as the device will not get a reset in
> down/up cycles; *possibly* dropping the reset call from ax88179_bind()
> would be safer.
Ok, I had the doubt about which reset would be the best, because it seemed 
to me that reset would be better as soon as possible.
I will try what you say to avoid down/up cycles.

> In both cases touching so many H/W variant with testing available on a
> single one sounds dangerous. Is the unneeded 2nd reset causing any
> specific issue?
Actually, this double reboot somewhat masked the first problem, because the
probability of getting a successful initialization, if there is a previous
problem seems to be higher. So, it is not strictly needed but I think it is 
better to avoid a second unnecessary reset.
Ok, if I modify the call from ax88179_bind() I will be respecting the reset
operation of all devices.

Thanks

Best regards
José Ignacio