netdev - Re: do a single memdup_user in sctp

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] [day] [month] [year] [list]

Message-ID: <20200525211847.GD2491@localhost.localdomain>
Date:   Mon, 25 May 2020 18:18:47 -0300
From:   Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:     'Christoph Hellwig' <hch@....de>
Cc:     David Laight <David.Laight@...lab.com>,
        Vlad Yasevich <vyasevich@...il.com>,
        Neil Horman <nhorman@...driver.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: do a single memdup_user in sctp_setsockopt

On Sat, May 23, 2020 at 09:19:29AM +0200, 'Christoph Hellwig' wrote:
> On Fri, May 22, 2020 at 11:36:23AM -0300, Marcelo Ricardo Leitner wrote:
...
> > What if you two work on a joint patchset for this? The proposals are
> > quite close. The differences around the setsockopt handling are
> > minimal already. It is basically variable naming, indentation and one
> > or another small change like:
> 
> I don't really want to waste too much time on this, as what I really
> need is to get the kernel_setsockopt removal series in ASAP.  I'm happy
> to respin this once or twice with clear maintainer guidance (like the
> memzero_explicit), but I have no idea what you even meant with your
> other example or naming.  Tell me what exact changes you want, and
> I can do a quick spin, but I don't really want a huge open ended
> discussion on how to paint the bikeshed..

What I meant is that the 2 proposals were very close already, with
only minimal differences. As David had posted his set first and you
didn't add a RFC tag nor stated that you were just sharing the
patches, I understood it was an alternative approach to David's, which
is not optimal here. This topic is far from being that polemic, that
could benefit from having 2 competing approaches. So first I wanted a
joint approach, and then build on it.

For now lets see how David's new patchset will look like. It was
almost there already.

> 
> Alternatively I'll also happily only do a partial conversion for what
> I need for the kernel_setsockopt removal and let you and Dave decided
> what you guys prefer for the rest.