linux-kernel - Re: [RFC] situation with csum_and_copy

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141125024018.GH7996@ZenIV.linux.org.uk>
Date:	Tue, 25 Nov 2014 02:40:18 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	David Miller <davem@...emloft.net>
Cc:	torvalds@...ux-foundation.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, target-devel@...r.kernel.org,
	nab@...ux-iscsi.org, hch@...radead.org
Subject: Re: [RFC] situation with csum_and_copy_... API

On Sat, Nov 22, 2014 at 02:24:44AM -0500, David Miller wrote:
> From: Al Viro <viro@...IV.linux.org.uk>
> Date: Sat, 22 Nov 2014 04:28:57 +0000
> 
> > 	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... maybe wait until Monday for other feedback
> then give me a pull request?

I'll probably repost the patches with updates folded in first...

FWIW, the current situation is
	* all but one ->recvmsg() instances switched to iov_iter primitives
(the exception is one of the AF_ALG instances and I know what to do with it).
Consequently, they do not drain iovecs anymore and simply advance ->msg_iter.
	* kvec-based iov_iter work just fine without set_fs(KERNEL_DS).  And
so do ->recvmsg() instances that had received such iov_iter.
	* memcpy_to_iovec() and skb_copy_datagram_iovec() are gone - no users
left.

I'm about to start on ->sendmsg() side of the things.  The interesting
question is whether tcp_send_syn_data() is doing the right thing if it
runs into EFAULT when copying iovec from userland.

As it is, it gives up on the skb it has allocated and falls back to normal
handshake.  I can duplicate that behaviour, all right, but why not simply
do skb_trim(syn_data, <actually copied>) and do fallback only if nothing
got copied at all?  Is there any problem with that?

The reason why I'm asking is that it's easier to just use copy_from_iter()
and let the damn thing advance.  Not a lot of pain to preserve the original
iov_iter (all 5 words of it) and copy it back in case of failure, but I'd
rather understood what's wrong with simpler approach...

Anyway, the current branch is in vfs.git#iov_iter-net.  Current balance is
about -0.5KLoC and that's not counting the simplifications that will become
possible in callers of kernel_sendmg/kernel_recvmsg...  I'll post the beginning
of that queue (the same 17 commits in the beginning) later tonight and wait
for review...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/