netdev - Re: [PATCH net 0/2] mptcp: some fallback fixes

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: <c5ea3f4a906c0dcd7b53b0dd70fc13eb3d2386e2.camel@redhat.com>
Date:   Mon, 12 Oct 2020 10:01:10 +0200
From:   Paolo Abeni <pabeni@...hat.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        mptcp@...ts.01.org
Subject: Re: [PATCH net 0/2] mptcp: some fallback fixes

On Sat, 2020-10-10 at 11:13 -0700, Jakub Kicinski wrote:
> On Fri,  9 Oct 2020 18:59:59 +0200 Paolo Abeni wrote:
> > pktdrill pointed-out we currently don't handle properly some
> > fallback scenario for MP_JOIN subflows
> > 
> > The first patch addresses such issue.
> > 
> > Patch 2/2 fixes a related pre-existing issue that is more
> > evident after 1/2: we could keep using for MPTCP signaling
> > closed subflows.
> 
> Applied, thanks Paolo.
> 
> You already have a few of those in the code, but:
> 
> +	if (... &&
> +	    schedule_work(&mptcp_sk(sk)->work))
> +		sock_hold(sk);
> 
> isn't this a fairly questionable construct?
> 
> You take a reference for the async work to release _after_ you
> scheduled the async work? 

Thank you for reviewing! Indeed we need to add some comments there:
IIRC that chunk already raised a question in the past.

Afaics, that is safe because the caller (a subflow) held a reference to
sk and sk can't be freed in between the scheduling and the next
sock_hold(). 

We have a pending refactor, targeting the next development cycle, that
will consolidate the workqueue scheduling into an helper. We will add
some comments there to clarify the above.

Thanks,

Paolo