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]
Date:   Mon, 13 Feb 2023 20:58:06 +0100
From:   Martin Kaiser <martin@...ser.cx>
To:     Dan Carpenter <error27@...il.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Larry Finger <Larry.Finger@...inger.net>,
        Phillip Potter <phil@...lpotter.co.uk>,
        Michael Straube <straube.linux@...il.com>,
        Pavel Skripkin <paskripkin@...il.com>,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Revert "staging: r8188eu: simplify rtw_get_ff_hwaddr"

Thus wrote Dan Carpenter (error27@...il.com):

> On Sat, Feb 11, 2023 at 07:32:05PM +0100, Martin Kaiser wrote:
> > This reverts commit fd48124e09825797bdc8ff0120f2401030c618ee.

> > The cleanup in this commit removes the qsel to addr mappings in
> > rtw_get_ff_hwaddr. The underlying assumption is that rtw_write_port
> > uses its addr parameter only for the high_queue check.

> > This is obviously incorrect as rtw_write_port calls
> > ffaddr2pipehdl(pdvobj, addr);
> > where addr is mapped to a usb bulk endpoint.

> > Unfortunately, testing did not show any problems. The Edimax V2 on which I
> > tested has two bulk out endpoints. I guess that with the incorrect patch,
> > addr could only be 0 (no high queue) or 6 (high queue), both of which were
> > mapped to the first bulk out endpoint. Data transfers did still work...

> > Signed-off-by: Martin Kaiser <martin@...ser.cx>
> > ---

> > Hello Greg,

> > sorry for introducing a regression in commit fd48124e0982 ("staging:
> > r8188eu: simplify rtw_get_ff_hwaddr").

> > Could you take this revert before the 6.3 pull request?

> > Thanks,
> > Martin


> I feel like the ancient `git revert` script is not at all in line with
> current standards and sets people up for failure.  This one at least
> has a commit message.  But
> 1) The subject doesn't have a correct patch prefix.
> 2) "commit fd48124e09825797bdc8ff0120f2401030c618ee" is not human
>    readable or how we describe commits these days with a 12 char hash.
> 3) There is no fixes tag.

Thanks, I fixed these points in v2.

Best regards,
Martin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ