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] [day] [month] [year] [list]
Message-ID: <20230113115408.741150b8@kernel.org>
Date:   Fri, 13 Jan 2023 11:54:08 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Bjørn Mork <bjorn@...k.no>
Cc:     Greg KH <greg@...ah.com>, Andre Przywara <andre.przywara@....com>,
        Paolo Abeni <pabeni@...hat.com>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, linux-usb@...r.kernel.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] r8152; preserve device list format

On Fri, 13 Jan 2023 11:16:47 +0100 Bjørn Mork wrote:
> There is no point backporting to anything older than v5.15 since the
> patch depend on significant driver changes between v5.10 and v5.15.  The
> good news is that those changes also modified the macro in question so
> any device ID patch for v5.10 or older will have to be fixed up in any
> case.  So we don't lose anything by ignoring the older longterm kernels
> here.
> 
> IIUC the special netdev stable rules are gone.  But if this is going to
> stable, then I believe it still has to go to "net" first.
> 
> David/Jakub - Would you please pick
> 
>   ec51fbd1b8a2 ("r8152: add USB device driver for config selection")
>   69649ef84053 ("cdc_ether: no need to blacklist any r8152 devices")
> 
> from net-next to net?  With a "CC: stable" preferably.  Or do you prefer
> some other solution?

Well.. we already shipped the patch from this thread as is to Linus.
Greg will be able to take be53771c87f4 into stable directly, with 
no dependencies.

And now the refactoring won't cherry-pick cleanly :(
Maybe let's leave it be?

I'll keep in mind that Greg is okay with taking this sort of
refactoring in in the future. I made an unnecessary commotion here.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ