MIME-Version: 1.0
References: <20230210061953.GC2825702@dread.disaster.area> <Y+oCBnz2nLtXrz7O@gondor.apana.org.au>
 <CALCETrXKkZw3ojpmTftur1_-dEi6BOo9Q0cems_jgabntNFYig@mail.gmail.com> <Y+riPviz0em9L9BQ@gondor.apana.org.au>
In-Reply-To: <Y+riPviz0em9L9BQ@gondor.apana.org.au>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Fri, 17 Feb 2023 15:13:14 -0800
Message-ID: <CALCETrXr8vRPqEjhSg7=adQcM7OfWs_+fn2xP5OQeLXAaLzHHQ@mail.gmail.com>
Subject: Re: copy on write for splice() from file to pipe?
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     Andy Lutomirski <luto@kernel.org>,
        Dave Chinner <david@fromorbit.com>,
        torvalds@linux-foundation.org, metze@samba.org, axboe@kernel.dk,
        linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org,
        io-uring@vger.kernel.org, linux-kernel@vger.kernel.org,
        viro@zeniv.linux.org.uk, samba-technical@lists.samba.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

> On Feb 13, 2023, at 5:22 PM, Herbert Xu <herbert@gondor.apana.org.au> wro=
te:
>
> =EF=BB=BFOn Mon, Feb 13, 2023 at 10:01:27AM -0800, Andy Lutomirski wrote:
>>
>> There's a difference between "kernel speaks TCP (or whatever)
>> correctly" and "kernel does what the application needs it to do".
>
> Sure I get where you are coming from.  It's just that the other
> participants in the discussion were thinking of stability for the
> sake of TCP (or TLS or some other protocol the kernel implements)
> and that simply is a non-issue.

I can certainly imagine TLS or similar protocols breaking if data
changes if the implementation is too clever and retransmission
happens.  Suppose 2000 bytes are sent via splice using in-kernel TLS,
and it goes out on the wire as two TCP segments.  The first segment is
dropped but the second is received.  The kernel resends the first
segment using different data.  This really ought to cause an integrity
check at the far end to fail.

I don't know if any existing kTLS is clever enough to regenerate
outgoing data when it needs to retransmit a segment, but it would be
an interesting optimization for serving static content over TLS.


>
> Having a better way to communicate completion to the user would be
> nice.  The only way to do it right now seems to be polling with
> SIOCOUTQ.
>
>