[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220207153450.07102d45@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Mon, 7 Feb 2022 15:34:50 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: davem@...emloft.net, netdev@...r.kernel.org, borisp@...dia.com,
john.fastabend@...il.com, daniel@...earbox.net,
vfedorenko@...ek.ru, kernel-team@...com, axboe@...nel.dk
Subject: Re: [PATCH net-next] tls: cap the output scatter list to something
reasonable
On Mon, 7 Feb 2022 21:20:04 +0000 Al Viro wrote:
> > > > Alternatively we could parametrize iov_iter_npages() to take
> > > > the size as arg instead of using i->count, or do something
> > > > else..
> > >
> > > Er... Would simply passing 16384/PAGE_SIZE instead of MAX_INT
> > > work for your purposes?
> >
> > The last arg is maxpages, I want maxbytes, no?
>
> What's the point of pass maxpages as argument to that, seeing that
> you ignore the value you've got? I'm just trying to understand what
> semantics do you really intend for that thing.
>
> Another thing: looking at that bunch now, for pipe-backed ones
> that won't work. It's a bug, strictly speaking, even though
> the actual primitives that grab those pages *will* honour the
> truncation/reexpand.
>
> Frankly, I wonder if we would be better off with making
> iov_iter_npages() a wrapper for that one, passing SIZE_MAX as
> maxbytes. How does the following (completely untested) look for you?
That looks cleaner to me as well! Will you submit officially or should
I take care of the conversion? My v1 has already made its way to
net-next.
Powered by blists - more mailing lists