On Sat, Nov 22, 2014 at 02:24:44AM -0500, David Miller wrote:
> From: Al Viro
> Date: Sat, 22 Nov 2014 04:28:57 +
>
> > OK, here's the next bunch. Sorry about the delay, iov_iter.c stuff
> > took most of the day (and it's not included in this pile). Please, review.
>
> I read over this
From: Al Viro
> On Fri, Nov 21, 2014 at 08:49:56AM +, Al Viro wrote:
>
> > Overall, I think I have the whole series plotted in enough details to be
> > reasonably certain we can pull it off. Right now I'm dealing with
> > mm/iov_iter.c stuff; the amount of boilerplate source is already high e
From: Al Viro
> On Fri, Nov 21, 2014 at 05:42:55PM +, David Laight wrote:
>
> > Callers of kernel_send/recvmsg() could easily be using a wrapper
> > function that creates the 'msghdr'.
> > When the want to send the remaining part of a buffer the old iterator
> > will no longer be available - j
On Fri, Nov 21, 2014 at 8:28 PM, Al Viro wrote:
> OK, here's the next bunch.
Looks like good patches to me. Not that I actually _tested_ it, or
even have a good test-case (yeah, that "historical" ATM fix? I don't
think anybody cares ;), but it all seemed sane.
Linus
--
To u
From: Al Viro
Date: Sat, 22 Nov 2014 04:28:57 +
> OK, here's the next bunch. Sorry about the delay, iov_iter.c stuff
> took most of the day (and it's not included in this pile). Please, review.
I read over this stuff twice and this series looks fine to me.
Since this is the weekend.
OK, here's the next bunch. Sorry about the delay, iov_iter.c stuff
took most of the day (and it's not included in this pile). Please, review.
Al Viro (17):
new helper: skb_copy_and_csum_datagram_msg()
new helper: memcpy_from_msg()
switch ipxrtr_route_packet() from iovec
On Sat, Nov 22, 2014 at 03:27:18AM +, Al Viro wrote:
> @@ -566,38 +445,15 @@ static size_t copy_to_iter_bvec(void *from, size_t
> bytes, struct iov_iter *i)
[snip]
> + iterate_bvec(i, bytes, page, off, len, true,
> + memcpy_from_page((from += len) - len, page, off, len)
On Fri, Nov 21, 2014 at 08:49:56AM +, Al Viro wrote:
> Overall, I think I have the whole series plotted in enough details to be
> reasonably certain we can pull it off. Right now I'm dealing with
> mm/iov_iter.c stuff; the amount of boilerplate source is already high enough
> and with those e
On Fri, Nov 21, 2014 at 11:39 AM, Al Viro wrote:
>
> I'm not at all sure that _anything_ has valid reasons for draining iovecs.
> Maintaining a struct iov_iter and modifying it is easy and actually faster...
For new code, I agree. But the whole "draining iovec's" is a fairly
common old model.
On Fri, Nov 21, 2014 at 05:42:55PM +, David Laight wrote:
> Callers of kernel_send/recvmsg() could easily be using a wrapper
> function that creates the 'msghdr'.
> When the want to send the remaining part of a buffer the old iterator
> will no longer be available - just the original iov and t
From: Al Viro
...
> We would be better off with iov_iter passed to __sock_{send,recv}msg() (as
> a part of struct msghdr, instead of ->msg_iov/->msg_iovlen) and always
> advanced to match the amount of data actually picked from it. With iovec
> behind it remaining constant. That would work just a
From: David Miller
Date: Thu, 20 Nov 2014 18:23:39 -0500 (EST)
> From: Al Viro
> Date: Thu, 20 Nov 2014 21:47:53 +
>
>> On Wed, Nov 19, 2014 at 04:53:40PM -0500, David Miller wrote:
>>
>>> Pulled, thanks Al.
>>
>> Umm... Not in net-next.git#master...
>
> Sorry, I may have done my usual:
On Fri, 2014-11-21 at 08:49 +, Al Viro wrote:
> Another thing is tcp_sendmsg_fastopen() and tcp_send_rcvq(). The latter
> should just use copy_from_iter() instead of memcpy_from_iovec(), the former
> is dealt with by making tcp_send_syn_data() use the same copy_from_iter()
> instead of memcpy
On Thu, Nov 20, 2014 at 02:53:55PM -0800, Eric Dumazet wrote:
> > And no, your solution doesn't work. Sorry. You'll break e.g.
> > smb_send_kvec()
> > that way. ceph_tcp_sendmsg() as well, IIRC.
>
> Nowhere in tcp_sendmsg() the iov had const qualifier.
*nod*
> If it was declared as const, th
Hi Al & Co,
On Thu, 2014-11-20 at 21:47 +, Al Viro wrote:
> On Wed, Nov 19, 2014 at 04:53:40PM -0500, David Miller wrote:
>
> > Pulled, thanks Al.
>
> Umm... Not in net-next.git#master... Anyway, the next portion is in
> vfs.git#iov_iter-net right now; I'll post it on netdev once I get som
From: Al Viro
Date: Thu, 20 Nov 2014 21:47:53 +
> On Wed, Nov 19, 2014 at 04:53:40PM -0500, David Miller wrote:
>
>> Pulled, thanks Al.
>
> Umm... Not in net-next.git#master...
Sorry, I may have done my usual: pull at the office compute, fire up
build testing, go home without pushing back
On Thu, 2014-11-20 at 22:25 +, Al Viro wrote:
> Yes, it is. You are breaking several _other_ kernel_sendmsg() users.
> They are already slightly broken, but that'll make breakage much more
> common.
>
> Please, don't - the right thing to do is to have iov_iter in msghdr
> (we already have th
On Thu, Nov 20, 2014 at 01:55:42PM -0800, Eric Dumazet wrote:
> On Thu, 2014-11-20 at 21:47 +, Al Viro wrote:
>
> > As far as I can see, these retries on the send side are simply broken -
> > normally we are talking to TCP sockets there and tcp_sendmsg() does *not*
> > modify iovec in normal c
On Thu, 2014-11-20 at 21:47 +, Al Viro wrote:
> As far as I can see, these retries on the send side are simply broken -
> normally we are talking to TCP sockets there and tcp_sendmsg() does *not*
> modify iovec in normal case.
Arg... I sent this morning something doing this (against net-next
On Wed, Nov 19, 2014 at 04:53:40PM -0500, David Miller wrote:
> Pulled, thanks Al.
Umm... Not in net-next.git#master... Anyway, the next portion is in
vfs.git#iov_iter-net right now; I'll post it on netdev once I get some
sleep.
It's getting close to really interesting parts. Right now the ma
From: Al Viro
Date: Wed, 19 Nov 2014 21:30:07 +
> On Wed, Nov 19, 2014 at 04:17:44PM -0500, David Miller wrote:
>> > Seeing a "__get_user()" and just being able to glance up in the same
>> > function and seeing the "access_ok()" is just a good safety net. And
>> > means that people don't have
On Wed, Nov 19, 2014 at 04:17:44PM -0500, David Miller wrote:
> > Seeing a "__get_user()" and just being able to glance up in the same
> > function and seeing the "access_ok()" is just a good safety net. And
> > means that people don't have to waste time thinking about or looking
> > for where the
From: Linus Torvalds
Date: Wed, 19 Nov 2014 12:40:53 -0800
> On Wed, Nov 19, 2014 at 12:31 PM, David Miller wrote:
>>
>> But that is just my opinion, and yes I do acknowledge that we've had
>> serious holes in this area in the past.
>
> The serious holes have generally been exactly in the "uppe
On Wed, Nov 19, 2014 at 12:40:53PM -0800, Linus Torvalds wrote:
> On Wed, Nov 19, 2014 at 12:31 PM, David Miller wrote:
> >
> > But that is just my opinion, and yes I do acknowledge that we've had
> > serious holes in this area in the past.
>
> The serious holes have generally been exactly in the
On Wed, Nov 19, 2014 at 12:31 PM, David Miller wrote:
>
> But that is just my opinion, and yes I do acknowledge that we've had
> serious holes in this area in the past.
The serious holes have generally been exactly in the "upper layers
already check" camp, and then it turns out that some odd ioct
From: Al Viro
Date: Tue, 18 Nov 2014 21:23:07 +
> On Tue, Nov 18, 2014 at 12:49:13PM -0800, Linus Torvalds wrote:
>> "access_ok()" isn't that expensive, and removing them as unnecessary
>> is fraught with errors. We've had several cases of "oops, we used
>> __get_user() in a loop, because it
From: Al Viro
Date: Tue, 18 Nov 2014 19:40:53 +
> On Tue, Nov 18, 2014 at 08:47:45AM +, Al Viro wrote:
>
>> I do have a patch doing just that; the question is what to do with
>> csum-and-copy
>> primitives. Originally I planned to simply strip those access_ok() from
>> those
>> (both
On Tue, Nov 18, 2014 at 1:23 PM, Al Viro wrote:
>
> OK... If netdev folks can live with that for now, I've no problem with
> dropping 3/5. However, I really think we need a variant of csum-and-copy
> that would _not_ bother with access_ok() longer term. That can wait,
> though...
iirc,access_
On Tue, Nov 18, 2014 at 12:49:13PM -0800, Linus Torvalds wrote:
> On Tue, Nov 18, 2014 at 12:47 AM, Al Viro wrote:
> > The minimal implementations would be
> >
> > __wsum csum_and_copy_from_user(const void __user *src, void *dst, int len,
> >__wsum sum, int *err_ptr
On Tue, Nov 18, 2014 at 12:47 AM, Al Viro wrote:
> The minimal implementations would be
>
> __wsum csum_and_copy_from_user(const void __user *src, void *dst, int len,
>__wsum sum, int *err_ptr)
> {
> if (unlikely(copy_from_user(dst, src, len) < 0)) {
No. Th
On Tue, Nov 18, 2014 at 08:47:45AM +, Al Viro wrote:
> I do have a patch doing just that; the question is what to do with
> csum-and-copy
> primitives. Originally I planned to simply strip those access_ok() from those
> (both the explicit calls and use of copy_from_user() where we ought to u
I've spent the last weekend crawling through the copy-and-calculate-csum
primitives on all architectures. It came up during iov_iter work; below
are the results of that review and, in the end, several questions about
the short-term tactics of a change that needs to be done for iov_iter-net.
The A
32 matches
Mail list logo
