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: <MWHPR11MB1693FA23D320DC2DE585C696EF149@MWHPR11MB1693.namprd11.prod.outlook.com>
Date:   Thu, 1 Dec 2022 15:56:47 +0000
From:   <Jerry.Ray@...rochip.com>
To:     <olteanv@...il.com>
CC:     <kuba@...nel.org>, <andrew@...n.ch>, <f.fainelli@...il.com>,
        <davem@...emloft.net>, <edumazet@...gle.com>, <pabeni@...hat.com>,
        <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net-next v3] dsa: lan9303: Add 3 ethtool stats

>> Won't be able to get to stats64 this cycle.  Looking to migrate to phylink
>> first.  This is a pretty old driver.
>>
>> Understand you don't know me - yet.
>
>It would be good if you first prepared a bug fix patch for the existing
>kernel stack memory leakage, and submit that to the net.git tree.
>The net.git is merged back into net-next.git every ~Thursday, and
>generally speaking, either you wait for bug fixes to land back into
>net-next before you submit new net-next material in the same areas,
>or the netdev and linux-next maintainers will have to resolve the merge
>conflict between trees manually. Not a huge deal, but it is kind of a
>nuisance for backports (to not be able to linearize a series of cherry
>picks) and all in all, it's best to organize your work such that you
>don't conflict with yourself.
>

I'm unaware of a kernel stack memory leak.  Can you point me to a thread?

As for splitting bug fix patches, ...
A comment was made against my patch and I looked to make things consistent
with the existing code.  I failed to see the distinction of addressing the
issue with the patch and addressing the same issue with existing code.
Thanks for explaining the reasoning behind why separating the patches
matters.  I'll try to keep that in mind for future submissions.

Regards,
Jerry.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ