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 <>
To:     Willem de Bruijn <>
Cc:     Xie He <>,
        "David S. Miller" <>,
        Network Development <>,
        linux-kernel <>,
        Krzysztof Halasa <>
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 <> wrote:
> > On Sat, Oct 31, 2020 at 8:18 AM Xie He <> 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.

Powered by blists - more mailing lists