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: <YtVZ6VI1yvbgSYDg@shell.armlinux.org.uk>
Date:   Mon, 18 Jul 2022 14:02:33 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Alvin Šipraga <alsi@...g-olufsen.dk>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Daniel Scally <djrscally@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        DENG Qingfang <dqfext@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        George McCollister <george.mccollister@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Hauke Mehrtens <hauke@...ke-m.de>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Kurt Kanzenbach <kurt@...utronix.de>,
        Landen Chao <Landen.Chao@...iatek.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-acpi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org,
        Marek Behún <kabel@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Sean Wang <sean.wang@...iatek.com>,
        UNGLinuxDriver@...rochip.com,
        Vivien Didelot <vivien.didelot@...il.com>,
        Woojung Huh <woojung.huh@...rochip.com>
Subject: Re: [PATCH net-next 0/6] net: dsa: always use phylink

On Mon, Jul 18, 2022 at 03:45:12PM +0300, Vladimir Oltean wrote:
> On Mon, Jul 18, 2022 at 09:53:23AM +0100, Russell King (Oracle) wrote:
> > On Sat, Jul 16, 2022 at 04:13:45PM +0300, Vladimir Oltean wrote:
> > > On Sat, Jul 16, 2022 at 12:43:00PM +0100, Russell King (Oracle) wrote:
> > > > In the first RFC series I sent on the 24 June, I explicitly asked the
> > > > following questions:
> > > (...)
> > > > I even stated: "Please look at the patches and make suggestions on how
> > > > we can proceed to clean up this quirk of DSA." and made no mention of
> > > > wanting something explicitly from Andrew.
> > > > 
> > > > Yet, none of those questions were answered.
> > > > 
> > > > So no, Jakub's comments are *not* misdirected at all. Go back and read
> > > > my June 24th RFC series yourself:
> > > > 
> > > > https://lore.kernel.org/all/YrWi5oBFn7vR15BH@shell.armlinux.org.uk/
> > > 
> > > I don't believe I need to justify myself any further for why I didn't
> > > leave a comment on any certain day. I left my comments when I believed
> > > it was most appropriate for me to intervene (as someone who isn't really
> > > affected in any way by the changes, except for generally maintaining
> > > what's in net/dsa/, and wanting to keep a clean framework structure).
> > > Also, to repeat myself, blaming me for leaving comments, but doing so
> > > late, is not really fair. I could have not responded at all, and I
> > > wouldn't be having this unpleasant discussion. It begs the question
> > > whether you're willing to be held accountable in the same way for the
> > > dates on which you respond on RFC patches.
> > > 
> > > > I've *tried* my best to be kind and collaborative, but I've been
> > > > ignored. Now I'm hacked off. This could have been avoided by responding
> > > > to my explicit questions sooner, rather than at the -rc6/-rc7 stage of
> > > > the show.
> > > 
> > > I think you should continue to try your best to be kind and collaborative,
> > > you weren't provoked or intentionally ignored in any way, and it isn't
> > > doing these patches any good.
> > 
> > And yet again, I don't have answers to many of those questions... which
> > just shows how broken this process is, and how utterly pointless it is
> > 0to ask any questions in this area.
> > 
> > My conclusion: you don't care one bit to even answer questions until
> > there's a chance that patches that you disagree with might be merged,
> > and oh my god, you've got to respond to stop that happening because you
> > might disagree with something. You can't do the collaborative thing and
> > respond when someone asks explicit questions about how things should be
> > done.
> > 
> > I'm not going to let this go. I'm really pissed off by this and you
> > are the focus of my frustration.
> 
> The hypothesis that you put forward is that I'm sabotaging you by not
> responding to RFCs, then leaving comments when you submit the patches
> proper, just so that they're delayed because I don't agree with them;
> and that the process is broken because it allows me to do just that and
> get away with it (for fun, I assume?).
> 
> So first off, you sent the first RFC towards 2 people in To:, and 19
> people in Cc:. I was one of the people in Cc. You didn't ask *me* any
> explicit question. In fact, when you did, I responded within 5 hours:
> https://lore.kernel.org/linux-arm-kernel/20220707154303.236xaeape7isracw@skbuf/
> 
> Then, why did I not respond earlier to questions I had an opinion on?

In the second RFC, I stated:

"Some of the questions from the original RFC remain though, so I've
included that text below. I'm guessing as they remain unanswered that
no one has any opinions on them?"

Clearly, I was soliciting answers from _everyone_ who received this,
not just the two people in the To: header.

> Based on prior experience, anything I reply to you has a chance of
> inflaming you for reasons that are outside of my control, and the
> discussion derails and eventually ends with you saying that I'm being
> difficult and you're quitting for the day, week, month, kernel release
> cycle or what not. I'm not saying that's my fault or your fault in
> general, it's just a statistical observation based on past interactions,
> and it looks like this one is no different.
> 
> With regard to this topic, there was ample opportunity for the patch set
> to come to a resolve without my intervention, and I decided that the
> best way to maximize the chances of this discussion not going sideways
> is to not say anything at all, especially when I don't need to.
> Gradually, the opportunity for the patch set to resolve itself without
> my intervention diminished, and I started offering my feedback to the code.
> 
> It's perhaps necessary of me to not let this phrase of yours unaddressed,
> because it is subtly part of your argument that I'm just trying to delay
> your patches as part of a sabotage plot:
> 
> | The only thing that delayed them was your eventual comments about
> | re-working how it was being done.
> 
> Let's not forget that I did *not* request you to rework the implementation
> to use software nodes. I simply went with the code you originally proposed,
> explained why it is unnaturally structured in my view, asked you why you
> did not consider an alternative structure if you're not willing to make
> phylink absorb the logic, then you said you'd be happy to rework using
> software nodes.
> https://lore.kernel.org/netdev/20220707193753.2j67ni3or3bfkt6k@skbuf/

This is _not_ the issue I'm raising. I am complaining about the
"default_interface" issue that you've only piped up about, despite
(a) an explicit question having been asked about that approach, (b) it
appearing in not just one, not two, not three but four RFC series sent,
and only finally being raised when a non-RFC series was sent.

This whole debarcle could have been avoided with providing feedback at
an earlier stage, when I explicitly requested it _several_ times.

I will not be doing any further work on this - this can wait a few
kernel cycles, because quite honestly, I'm not going to try to submit
this for next cycle.

And I quite expect a repeat of this shit, with me struggling to get
comments on patches, being mostly ignored and then for comments to come
at the last minute when there's no reasonable time left in the cycle to
action them.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ