linux-kernel - splice between non-pipe (tcp socket) fds

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-next>] [day] [month] [year] [list]

Message-ID: <b8f627e0909212323mbeb0fd1yba25aafb58ef686b@mail.gmail.com>
Date:	Tue, 22 Sep 2009 12:23:11 +0600
From:	Марк Коренберг <socketpair@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: splice between non-pipe (tcp socket) fds

I want splice() to work with two tcp sockets().I think to implement
this. Two questions:

1. Is any work in this direction?
2. Why this functionality does not implemented now? any difficulties?

I think API should consist of 2 main functions:
1. detach available buffers from fd1 (and save info in some struct)
2. attach buffers to fd2 (from this struct)
this functions should be called under some lock to guarantee
atomicity. if something happen, return buffers back to original file.

I mean, that, for example, skb_splice_bits should not splice into
pipe..... it should splice skb into list of kernel buffers independent
from the "type" of fd (socket, file, and so on...)

At now, I think that the most quick way to acheive my results,  is to
create intermediate temporary pipe inside kernel and splice from
non-pipe fd to pipe, and than from pipe to second non-pipe fd.

Is this method appropriate, as you think ?
--
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/