netdev - Re: [PATCH net-next v2 0/7] ibmvnic: Use more consistent locking

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:   Wed, 13 Jan 2021 10:57:35 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Sukadev Bhattiprolu <sukadev@...ux.ibm.com>
Cc:     netdev@...r.kernel.org, Dany Madden <drt@...ux.ibm.com>,
        Lijun Pan <ljp@...ux.ibm.com>,
        Rick Lindsley <ricklind@...ux.ibm.com>
Subject: Re: [PATCH net-next v2 0/7] ibmvnic: Use more consistent locking

On Tue, 12 Jan 2021 20:42:47 -0800 Sukadev Bhattiprolu wrote:
> Jakub Kicinski [kuba@...nel.org] wrote:
> > On Tue, 12 Jan 2021 10:14:34 -0800 Sukadev Bhattiprolu wrote:  
> > > Use more consistent locking when reading/writing the adapter->state
> > > field. This patch set fixes a race condition during ibmvnic_open()
> > > where the adapter could be left in the PROBED state if a reset occurs
> > > at the wrong time. This can cause networking to not come up during
> > > boot and potentially require manual intervention in bringing up
> > > applications that depend on the network.  
> > 
> > Apologies for not having enough time to suggest details, but let me
> > state this again - the patches which fix bugs need to go into net with
> > Fixes tags, the refactoring needs to go to net-next without Fixes tags.
> > If there are dependencies, patches go to net first, then within a week
> > or so the reset can be posted for net-next, after net -> net-next merge.  
> 
> Well, the patch set fixes a set of bugs - main one is a locking bug fixed
> in patch 6. Other bugs are more minor or corner cases. Fixing the locking
> bug requires some refactoring/simplifying/reordering checks so lock can be
> properly acquired.
> 
> Because of the size/cleanup, should we treat it as "next" material? i.e
> should I just drop the Fixes tag and resend to net-next?
> 
> Or can we ignore the size of patchset and treat it all as bug fixes?

No, focus on doing this right rather than trying to justify why your
patches deserve special treatment.

Throw this entire series out and start over with the goal of fixing 
the bugs with minimal patches.