netdev - Re: [PATCH net-next v6 1/5] net: hdlc_fr: Simpify fr_rx by using "goto rx

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:   Sat, 31 Oct 2020 13:39:10 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc:     Xie He <xie.he.0141@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Network Development <netdev@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Krzysztof Halasa <khc@...waw.pl>
Subject: Re: [PATCH net-next v6 1/5] net: hdlc_fr: Simpify fr_rx by using
 "goto rx_drop" to drop frames

On Sat, 31 Oct 2020 15:47:28 -0400 Willem de Bruijn wrote:
> On Sat, Oct 31, 2020 at 12:02 PM Xie He <xie.he.0141@...il.com> wrote:
> > On Sat, Oct 31, 2020 at 8:18 AM Xie He <xie.he.0141@...il.com> wrote:  
> > > > Especially without that, I'm not sure this and the follow-on patch add
> > > > much value. Minor code cleanups complicate backports of fixes.  
> > >
> > > To me this is necessary, because I feel hard to do any development on
> > > un-cleaned-up code. I really don't know how to add my code without
> > > these clean-ups, and even if I managed to do that, I would not be
> > > happy with my code.  
> 
> That is the reality of working in this space, I think. I have
> frequently restructured code, fixed a bug and then worked backwards to
> create a *minimal* bugfix that applies to the current code as well as
> older stable branches.
> 
> Obviously this is more of a concern for stable fixes than for new
> code. But we have to keep in mind that every code churn will make
> future bug fixes harder to roll out to users. That is not to say that
> churn should be avoided, just that we need to balance a change's
> benefit against this cost.
> 
> > And always keeping the user interface and even the code unchanged
> > contradicts my motivation of contributing to the Linux kernel. All my
> > contributions are motivated by the hope to clean things up. I'm not an
> > actual user of any of the code I contribute. If we adhere to the
> > philosophy of not doing any clean-ups, my contributions would be
> > meaningless.  
> 
> There are cleanups and cleanups. Dead code removal and deduplication
> of open coded logic, for instance, are very valuable. As is, for
> instance, your work in making sense of hard_header_len.

Or removing the buggy uses of IFF_TX_SKB_SHARING, for that matter
(which at this point I agree we should just remove from ether_setup, 
and let people who care re-enable it).

> Returning code in branches vs an error jump label seems more of a
> personal preference, and to me does not pass the benefit/cost threshold.

I must agree.