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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 31 Oct 2020 15:47:28 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Xie He <xie.he.0141@...il.com>
Cc:     Willem de Bruijn <willemdebruijn.kernel@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        "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, 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.

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.

FWIW, there is lots of code that I would jump at the opportunity to
restructure. Starting with skb_segment, probably.

Obviously, all this is just one opinion on the topic.

Powered by blists - more mailing lists