On (05/11/19 12:52), Linus Torvalds wrote:
>
> So David, arguably the kernel "struct sockaddr" is simply wrong, if it
> can't contain a "struct sockaddr_in6". No? Is extending it a huge
> problem for other users that don't need it (mainly stack, I assume..)?
The ipv6 working group came up with so
On (03/22/19 10:59), Soheil Hassas Yeganeh wrote:
>
> Add documentation to the tcp_ca_state enum, since this enum is
> exposed in uapi.
Acked-by: Sowmini Varadhan
rigger a perf-event notification based on the verdict from the filter.
The uspace component can use these perf-event notifications to either
read any state managed by the eBPF kernel module, or issue a TCP_INFO
netlink call if desired.
Patch 2 provides a simple example that shows how to use t
: Sowmini Varadhan
---
V2: inline call to sys_perf_event_open() following the style of existing
code in kselftests/bpf
tools/testing/selftests/bpf/Makefile |4 +-
tools/testing/selftests/bpf/test_tcpnotify.h | 19 ++
tools/testing/selftests/bpf/test_tcpnotify_kern.c | 95
This patch allows eBPF programs that use sock_ops to send
perf-based event notifications using bpf_perf_event_output()
Signed-off-by: Sowmini Varadhan
---
net/core/filter.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/net/core/filter.c b/net/core
perf-event notifications to either
read any state managed by the eBPF kernel module, or issue a TCP_INFO
netlink call if desired.
Patch 2 provides a simple example that shows how to use this infra
(and also provides a test case for it)
Sowmini Varadhan (2):
bpf: add perf-event notificaton su
: Sowmini Varadhan
---
tools/testing/selftests/bpf/Makefile |4 +-
tools/testing/selftests/bpf/perf-sys.h| 74
tools/testing/selftests/bpf/test_tcpnotify.h | 19 ++
tools/testing/selftests/bpf/test_tcpnotify_kern.c | 95 +++
tools/testing
This patch allows eBPF programs that use sock_ops to send
perf-based event notifications using bpf_perf_event_output()
Signed-off-by: Sowmini Varadhan
---
net/core/filter.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/net/core/filter.c b/net/core
info notification for an iperf connection if the number of
retransmits exceeds 16.
Sowmini Varadhan (3):
sock_diag: Refactor inet_sock_diag_destroy code
tcp: BPF_TCP_INFO_NOTIFY support
bpf: Added a sample for tcp_info_notify callback
include/linux/sock_diag.h | 18 +++---
i
rn status is used
by the caller to queue up a tcp_info notification for the application.
Signed-off-by: Sowmini Varadhan
---
include/net/tcp.h| 15 +--
include/uapi/linux/bpf.h |4
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/include/net/tcp.h b/inc
Simple Proof-Of-Concept test program for BPF_TCP_INFO_NOTIFY
(will move this to testing/selftests/net later)
Signed-off-by: Sowmini Varadhan
---
samples/bpf/Makefile |1 +
samples/bpf/tcp_notify_kern.c | 73 +
2 files changed, 74 insertions
We want to use the inet_sock_diag_destroy code to send notifications
for more types of TCP events than just socket_close(), so refactor
the code to allow this.
Signed-off-by: Sowmini Varadhan
---
include/linux/sock_diag.h | 18 +-
include/uapi/linux/sock_diag.h |2
Without getting into Ahern's patchset, which he obviously feels
quite passionately about..
On (10/11/18 12:28), David Miller wrote:
>
> Once you've composed the message, the whole point of filtering is lost.
it would be nice to apply the filter *before* constructing the skb,
but afaict most
On (10/11/18 09:33), Roopa Prabhu wrote:
> 3. All networking subsystems already have this type of netlink
> attribute filtering that apps rely on. This series
> just makes it consistent for route dumps. Apps use such mechanism
> already when requesting dumps.
> Like everywhere else, BPF hook can be
On (10/11/18 09:32), David Ahern wrote:
>
> Route dumps are done for the entire FIB for each address family. As we
> approach internet routing tables (700k+ routes for IPv4, currently
> around 55k for IPv6) with many VRFs dumping the entire table is grossly
> inefficient when for example only a si
On (10/11/18 08:26), Stephen Hemminger wrote:
> You can do the something like this already with BPF socket filters.
> But writing BPF for multi-part messages is hard.
Indeed. And I was just experimenting with this for ARP just last week.
So to handle the caes of "ip neigh show a.b.c.d" without wal
On (09/17/18 16:15), Alexei Starovoitov wrote:
>
> if the goal is to add firewall ability to RDS then the patch set
> is going in the wrong direction.
The goal is to add the ability to process scatterlist directly,
just like we process skb's today.
Your main objection was that you wanted a test
On (09/12/18 19:07), Alexei Starovoitov wrote:
>
> I didn't know that. The way I understand your statement that
> this new program type, new sg logic, and all the complexity
> are only applicable to RDMA capable hw and RDS.
I dont know if you have been following the RFC series at all
(and Daniel
> On 09/11/2018 09:00 PM, Alexei Starovoitov wrote:
> >please no samples.
> >Add this as proper test to tools/testing/selftests/bpf
> >that reports PASS/FAIL and can be run automatically.
> >samples/bpf is effectively dead code.
Just a second.
You do realize that RDS is doing real networking, so
On (09/10/18 17:16), Cong Wang wrote:
> >
> > On (09/10/18 16:51), Cong Wang wrote:
> > >
> > > __rds_create_bind_key(key, addr, port, scope_id);
> > > - rs = rhashtable_lookup_fast(&bind_hash_table, key, ht_parms);
> > > + rcu_read_lock();
> > > + rs = rhashtable_lookup(&
On (09/10/18 16:51), Cong Wang wrote:
>
> __rds_create_bind_key(key, addr, port, scope_id);
> - rs = rhashtable_lookup_fast(&bind_hash_table, key, ht_parms);
> + rcu_read_lock();
> + rs = rhashtable_lookup(&bind_hash_table, key, ht_parms);
> if (rs && !sock_flag(r
On (09/10/18 15:43), Santosh Shilimkar wrote:
> On 9/10/2018 3:24 PM, Cong Wang wrote:
> >When a rds sock is bound, it is inserted into the bind_hash_table
> >which is protected by RCU. But when releasing rd sock, after it
> >is removed from this hash table, it is freed immediately without
> >respe
On (09/10/18 15:24), Cong Wang wrote:
>
> When a rds sock is bound, it is inserted into the bind_hash_table
> which is protected by RCU. But when releasing rd sock, after it
> is removed from this hash table, it is freed immediately without
> respecting RCU grace period. This could cause some use-
On (09/03/18 10:02), Steffen Klassert wrote:
> I'm working on patches that builds such skb lists. The list is chained
> at the frag_list pointer of the first skb, all subsequent skbs are linked
> to the next pointer of the skb. It looks like this:
there are some risks to using the frag_list pointe
esp=aes_gcm_c-256-null.
Each patch has a technical description of the contents of the fix.
V2: added Fixes tag so that it can be backported to the stable trees.
Sowmini Varadhan (2):
xfrm: reset transport header back to network header after all input
transforms ahave been applied
xfrm
back to network header
only after the last transformation so that subsequent xfrms
can find the correct transport header.
Fixes: 7785bba299a8 ("esp: Add a software GRO codepath")
Suggested-by: Steffen Klassert
Signed-off-by: Sowmini Varadhan
---
v2: added "Fixes" tag
ne
e612a0 ("xfrm: Add an IPsec hardware offloading API")
Signed-off-by: Sowmini Varadhan
---
v2: added "Fixes" tag
net/xfrm/xfrm_input.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index b89c9c7..be3
off-by: Sowmini Varadhan
---
net/xfrm/xfrm_input.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index b89c9c7..be3520e 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -458,6 +458,7 @@ int xfrm_input(struct s
back to network header
only after the last transformation so that subsequent xfrms
can find the correct transport header.
Suggested-by: Steffen Klassert
Signed-off-by: Sowmini Varadhan
---
net/ipv4/xfrm4_input.c |1 +
net/ipv4/xfrm4_mode_transport.c |4 +---
net/ipv6/xfrm6_input.c
esp=aes_gcm_c-256-null.
Each patch has a technical description of the contents of the fix.
Sowmini Varadhan (2):
xfrm: reset transport header back to network header after all input
transforms ahave been applied
xfrm: reset crypto_done when iterating over multiple input xfrms
net/ipv4
On (08/21/18 14:05), Yue Haibing wrote:
> Remove duplicated include.
>
> Signed-off-by: Yue Haibing
Acked-by: Sowmini Varadhan
On (08/08/18 14:51), Santosh Shilimkar wrote:
> This bug doesn't make sense since two different transports are using
> same socket (Loop and rds_tcp) and running together.
> For same transport, such race can't happen with MSG_ON_SOCK flag.
> CPU1-> rds_loop_inc_free
> CPU0 -> rds_tcp_cork ...
>
T
the refcnt on the messages
in the tmp_list (potentially resulting in rds_message_purge())
after dropping the rs_recv_lock.
The same lock hierarchy violation also exists in rds_still_queued()
and should be avoided in a similar manner
Signed-off-by: Sowmini Varadhan
Reported-by: syzbot+52140d69ac6dc6b92
ot;Structurally dead code")
> Fixes: 1e2b44e78eea ("rds: Enable RDS IPv6 support")
> Signed-off-by: Gustavo A. R. Silva
Acked-by: Sowmini Varadhan
On (07/18/18 15:19), Ka-Cheong Poon wrote:
> >bind() and connect() are using the sa_family/ss_family to have
> >the application signal to the kernel about whether ipv4 or ipv6 is
> >desired. (and bind and connect are doing the right thing for
> >v4mapped, so that doesnt seem to be a problem there)
On (07/17/18 13:32), Ka-Cheong Poon wrote:
>
> The app can use either structures to make the call. When the
> app fills in the structure, it knows what it is filling in,
> either sockaddr_in or sockaddr_in6. So it knows the right size
> to use. The app can also use IPv4 mapped address in a sock
- Looks like rds_connect() is checking things in the right order (thanks)
However, rds_cancel_sent_to is still looking at the len to figure
out the family.. as we move to ipv6, it would be better if we allow
the caller to specify struct sockaddr_storage, or even a union of
sockaddr_
On (07/06/18 23:08), Ka-Cheong Poon wrote:
>
> As mentioned in a previous mail, it is unclear why the
> port number is transport specific. Most Internet services
> use the same port number running over TCP/UDP as shown
> in the IANA database. And the IANA RDS registration is
> the same. What is
On (07/06/18 22:36), Ka-Cheong Poon wrote:
> This patch series does not change existing behavior. But
> I think this is a strange RDS semantics as it differs from
> other types of socket. But this is not about IPv6 support
> and can be dealt with later.
sure,
> > Since we are choosing to tre
On (07/06/18 17:08), Ka-Cheong Poon wrote:
> >Hmm. Why do you need to include tcp header in ib transport
> >code ? If there is any common function just move to core
> >common file and use it.
>
> I think it can be removed as it is left over from earlier
> changes when the IB IPv6 listener port was
Some additional comments on this patchset (consolidated here,
please tease this apart into patch1/patch2/patch3 as appropriate)
I looked at the most of rds-core, and the rds-tcp changes.
Please make sure santosh looks at these carefully, especially.
- RDS bind key changes
- connection.
Hi David,
An IPv6 regression has been introduced in 4.17.0-rc6 by
8308f3f net/ipv6: Add support for specifying metric of connected routes
The regression is that some interfaces on my test machine come
up with link-local addrs but the fe80 prefix is missing.
After this bug, I cannot send any p
On (06/27/18 18:07), Ka-Cheong Poon wrote:
>
> There is a reason for that. It is the way folks expect
> how IPv6 addresses are being used.
have you tried "traceoute6 -s abc::2 fe80::2" on linux?
> It is not just forwarding. The simple case is that one
> picks a global address in a different li
On (06/26/18 10:53), Sowmini Varadhan wrote:
> Date: Tue, 26 Jun 2018 10:53:23 -0400
> From: Sowmini Varadhan
> To: David Miller
> Cc: netdev@vger.kernel.org, rds-de...@oss.oracle.com
> Subject: Re: [rds-devel] [PATCH net-next] rds: clean up loopback
>
> and just to a
On (06/26/18 16:48), Dmitry Vyukov wrote:
> it probably hit the race by a pure luck of the large program, but then
> never had the same luck when tried to remove any syscalls.
> So it can make sense to submit several test requests to get more testing.
How does one submit test requests by email?
On (06/26/18 23:29), David Miller wrote:
> >>
> >> Since this probably fixes syzbot reports, this can be targetted
> >> at 'net' instead?
> >
> > that thought occurred to me but I wanted to be conservative and have
> > it in net-next first, have the syzkaller-bugs team confirm the
> > the fixes a
On (06/26/18 23:29), David Miller wrote:
>
> I think there is a way to ask syzbot to test a patch in an
> email.
Dmitry/syzkaller-bugs, can you clarify?
This is for the cluster of dup reports like
https://groups.google.com/forum/#!topic/syzkaller-bugs/zBph8Vu-q2U
and (most recently)
https://w
On (06/26/18 22:23), David Miller wrote:
>
> Since this probably fixes syzbot reports, this can be targetted
> at 'net' instead?
that thought occurred to me but I wanted to be conservative and have
it in net-next first, have the syzkaller-bugs team confirm the
the fixes and then backport to earli
On (06/26/18 21:02), Ka-Cheong Poon wrote:
>
> In this case, RFC 6724 prefers link local address as source.
the keyword is "prefers".
> While using non-link local address (say ULA) is not forbidden,
> doing this can easily cause inter-operability issues (does the
> app really know that the non-
On (06/26/18 13:30), Ka-Cheong Poon wrote:
>
> My answer to this is that if a socket is not bound to a link
> local address (meaning it is bound to a non-link local address)
> and it is used to send to a link local peer, I think it should
> fail.
Hmm, I'm not sure I agree. I dont think this is fo
On (06/26/18 01:43), Ka-Cheong Poon wrote:
>
> Yes, I think if the socket is bound, it should check the scope_id
> in msg_name (if not NULL) to make sure that they match. A bound
> RDS socket can send to multiple peers. But if the bound local
> address is link local, it should only be allowed to
On (06/25/18 03:38), Ka-Cheong Poon wrote:
> @@ -1105,8 +1105,27 @@ int rds_sendmsg(struct socket *sock, struct msghdr
> *msg, size_t payload_len)
> break;
>
> case sizeof(*sin6): {
> - ret = -EPROTONOSUPPORT;
> - goto o
On (06/25/18 06:41), Sowmini Varadhan wrote:
:
> Add the changes aligned with the changes from
> commit ebeeb1ad9b8a ("rds: tcp: use rds_destroy_pending() to synchronize
> netns/module teardown and rds connection/workq management") for
> rds_loop_transport
FWIW, I am opt
the changes from
commit ebeeb1ad9b8a ("rds: tcp: use rds_destroy_pending() to synchronize
netns/module teardown and rds connection/workq management") for
rds_loop_transport
Acked-by: Santosh Shilimkar
Signed-off-by: Sowmini Varadhan
---
net/rds/connection.c | 11 +-
net/
On (06/13/18 09:52), Dmitry Vyukov wrote:
> I think this is:
>
> #syz dup: KASAN: use-after-free Read in rds_cong_queue_updates
Indeed. We'd had a discussion about getting a dump of threads
using sysrq (or similar), given the challenges around actually
getting a crash dump, is that now possible?
On (05/11/18 15:48), Yanjun Zhu wrote:
> diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c
> index e678699..2228b50 100644
> --- a/net/rds/ib_rdma.c
> +++ b/net/rds/ib_rdma.c
> @@ -539,11 +539,17 @@ void rds_ib_flush_mrs(void)
>void *rds_ib_get_mr(struct scatterlist *sg, unsigned long nents,
>
On (04/18/18 06:35), Eric Dumazet wrote:
>
> There is no change at all.
>
> This will only be used as a mechanism to send X packets of same size.
>
> So instead of X system calls , one system call.
>
> One traversal of some expensive part of the host stack.
>
> The content on the wire should b
I went through the patch set and the code looks fine- it extends existing
infra for TCP/GSO to UDP.
One thing that was not clear to me about the API: shouldn't UDP_SEGMENT
just be automatically determined in the stack from the pmtu? Whats
the motivation for the socket option for this? also AIUI t
On (04/17/18 16:23), Willem de Bruijn wrote:
>
> Assuming IPv4 with an MTU of 1500 and the maximum segment
> size of 1472, the receiver will see three datagrams with MSS of
> 1472B, 528B and 512B.
so the recvmsg will also pass up 1472, 526, 512, right?
If yes, how will the recvmsg differentiate b
On (04/17/18 16:00), Willem de Bruijn wrote:
>
> This patchset implements GSO for UDP. A process can concatenate and
> submit multiple datagrams to the same destination in one send call
> by setting socket option SOL_UDP/UDP_SEGMENT with the segment size,
> or passing an analogous cmsg at send tim
#syz dup: KASAN: use-after-free Read in rds_cong_queue_updates
There are a number of manifestations of this bug, basically
all suggest that the connect/reconnect etc workqs are somehow
being scheduled after the netns is deleted, despite the
code refactoring in Commit 3db6e0d172c (and looks like
On (03/20/18 12:37), H??kon Bugge wrote:
>
> A little nit below. And some spelling issues in existing commentary
> you can consider fixing, since you reshuffle this file considerable.
> > + if (net != &init_net && rtn->ctl_table)
> > + kfree(rtn->ctl_table);
>
> Well, this comes from
netdevice notifiers and
refactors all the code needed to dismantle rds_tcp state
into a ->exit callback for the pernet_operations used with
register_pernet_device().
Signed-off-by: Sowmini Varadhan
---
net/rds/tcp.c | 93 ++---
1 files changed,
On (03/19/18 09:29), Dmitry Vyukov wrote:
>
> This looks the same as:
>
> #syz dup: KASAN: use-after-free Read in rds_cong_queue_updates
correct, seems like the rds_destroy_pending() fixes did not seal
this race condition. I need to look at this more carefully to see
what race I missed.. no easy
On (03/18/18 00:55), Kirill Tkhai wrote:
>
> I just want to make rds not using NETDEV_UNREGISTER_FINAL. If there is
> another solution to do that, I'm not again that.
The patch below takes care of this. I've done some preliminary testing,
and I'll send it upstream after doing additional self-revi
On (03/17/18 10:15), Sowmini Varadhan wrote:
> To solve the scaling problem why not just have a well-defined
> callback to modules when devices are quiesced, instead of
> overloading the pernet_device registration in this obscure way?
I thought about this a bit, and maybe I missed your
I spent a long time staring at both v1 and v2 of your patch.
I understand the overall goal, but I am afraid to say that these
patches are complete hacks.
I was trying to understand why patchv1 blows with a null rtn in
rds_tcp_init_net, but v2 does not, and the analysis is ugly.
I'm going to
On (03/16/18 21:48), Kirill Tkhai wrote:
>
> > Thus I have to spend some time reviewing your patch,
> > and I cannot give you an answer in the next 5 minutes.
>
> No problem, 5 minutes response never required. Thanks for
> your review.
thank you. I would like to take some time this weekend
to un
On (03/16/18 21:14), Kirill Tkhai wrote:
>
> I did the second version and sent you. Have you tried it?
I tried it briefly, and it works for the handful of testcases
that I tried, but I still think its very werid to register
as both a device and a subsys, esp in the light of the
warning in net_na
I had taken some of this offline, but it occurs to me
that some of these notes should be saved to the netdev archives,
in case this question pops up again in a few years.
When I run your patch, I get a repeatable panic by doing
modprobe rds-tcp
ip netns create blue
the panic is because we ar
Found my previous question:
https://www.mail-archive.com/netdev@vger.kernel.org/msg72330.html
(see section about "Comments are specifically ivinted.."
> This is not a problem, and rds-tcp is not the only pernet_subsys registering
> a socket. It's OK to close it from .exit method. There are many
On (03/16/18 15:38), Kirill Tkhai wrote:
>
> 467fa15356acf by Sowmini Varadhan added NETDEV_UNREGISTER_FINAL dependence
> with the commentary:
>
> /* rds-tcp registers as a pernet subys, so the ->exit will only
>* get invoked after network acitivity has
use rds_destroy_pending() correctly.
Reported-by: syzbot+c68e51bb5e699d3f8...@syzkaller.appspotmail.com
Fixes: ebeeb1ad9b8a ("rds: tcp: use rds_destroy_pending() to synchronize
netns/module teardown and rds connection/workq management")
Signed-off-by: Sowmini Varadhan
---
net
On (03/14/18 14:28), Eric Dumazet wrote:
>
>
> spin_lock_bh(&rds_tcp_conn_lock);/spin_unlock_bh(&rds_tcp_conn_lock); in
> rds_tcp_conn_free()
>
> is in conflict with the spin_lock_irqsave(&rds_conn_lock, flags);
> in __rds_conn_create()
yes I was going to look into this and fix it later.
> Har
On (03/11/18 18:03), Colin King wrote:
> From: Colin Ian King
>
> Functions rds_info_from_znotifier and rds_message_zcopy_from_user are
> local to the source and do not need to be in global scope, so make them
> static.
the rds_message_zcopy_from_user warning was already flagged by kbuild-robot
On (03/11/18 17:27), Colin King wrote:
> Variable sg_off is assigned a value but it is never read, hence it is
> redundant and can be removed.
>
Acked-by: Sowmini Varadhan
On (03/08/18 18:56), kbuild test robot wrote:
>
> Fixes: d40a126b16ea ("rds: refactor zcopy code into
> rds_message_zcopy_from_user")
> Signed-off-by: Fengguang Wu
Acked-by: Sowmini Varadhan
(do I need to separately submit a non-RFC patch for this?)
On (03/07/18 09:40), Jesus Sanchez-Palencia wrote:
> Fix the SO_ZEROCOPY switch case on sock_setsockopt() avoiding the
> ret values to be overwritten by the one set on the default case.
Acked-by: Sowmini Varadhan
Move the large block of code predicated on zcopy from
rds_message_copy_from_user into a new function,
rds_message_zcopy_from_user()
Signed-off-by: Sowmini Varadhan
---
net/rds/message.c | 108 +---
1 files changed, 60 insertions(+), 48 deletions
)
Sowmini Varadhan (2):
rds: refactor zcopy code into rds_message_zcopy_from_user
rds: use list structure to track information for zerocopy completion
notification
okie_queue by
a simpler list that results in a smaller memory footprint as well
as more efficient memory_allocation time.
Signed-off-by: Sowmini Varadhan
---
net/rds/af_rds.c |6 ++--
net/rds/message.c | 77 +---
net/rds/rds.h
onfigured as a kernel module.
Acked-by: Sowmini Varadhan
On (03/01/18 20:19), Ka-Cheong Poon wrote:
> >>
> >>- new_sock->type = sock->type;
> >>- new_sock->ops = sock->ops;
> >> ret = sock->ops->accept(sock, new_sock, O_NONBLOCK, true);
> >> if (ret < 0)
> >> goto out;
> >>
> >>+ new_sock->ops = sock->ops
On Wed, Feb 28, 2018 at 11:44 PM, Ka-Cheong Poon
wrote:
> Commit 0933a578cd55 ("rds: tcp: use sock_create_lite() to create the
> accept socket") has a reference counting issue in TCP socket creation
> when accepting a new connection. The code uses sock_create_lite() to
> create a kernel socket.
PF_RDS sockets pass up cookies for zerocopy completion as ancillary
data. Update msg_zerocopy to reap this information.
Signed-off-by: Sowmini Varadhan
Acked-by: Willem de Bruijn
Acked-by: Santosh Shilimkar
---
v2: receive zerocopy completion notification as POLLIN
v3: drop ncookies arg in
In preparation for optimized reception of zerocopy completion,
revert the Rx side changes introduced by Commit dfb8434b0a94
("selftests/net: add zerocopy support for PF_RDS test case")
Signed-off-by: Sowmini Varadhan
Acked-by: Willem de Bruijn
Acked-by: Santosh Shilimkar
---
v2:
remove the sk_errror_queue related paths in
RDS.
Both of these goals are implemented in this series.
v2: removed sk_error_queue support
v3: incorporated additional code review comments (details in each patch)
Sowmini Varadhan (3):
selftests/net: revert the zerocopy Rx path for PF_RDS
rds: deliver
es support for zerocopy completion notification on
MSG_ERRQUEUE for PF_RDS sockets.
Signed-off-by: Sowmini Varadhan
Acked-by: Willem de Bruijn
Acked-by: Santosh Shilimkar
---
v2: remove sk_error_queue path; lot of cautionary checks rds_recvmsg_zcookie()
and callers to make sure we dont remo
On (02/27/18 12:40), David Miller wrote:
>
> I'm expecting a V3 respin of your zerocopy notification changes
> if that is what you're talking about, and I therefore marked
> the most recent spin as "changes requested".
sorry, I'm confused - you are waiting for V4?
I am not seeing v3 on patchwork
On (02/27/18 11:49), David Miller wrote:
> > Do I need to resend?
>
> Yes, see my other email.
do we need to resend patches not showing up in patchwork?
I recall seeing email about picking things manually from inbox
but missed this.
--Sowmini
On (02/26/18 09:07), Santosh Shilimkar wrote:
> Just in case you haven't seen yet, Dan Carpenter reported skb deref
> warning on previous version of the patch. Not sure why it wasn't sent
> on netdev.
yes I saw it, but that was for the previous version of the patch
around code that delivers notifi
In preparation for optimized reception of zerocopy completion,
revert the Rx side changes introduced by Commit dfb8434b0a94
("selftests/net: add zerocopy support for PF_RDS test case")
Signed-off-by: Sowmini Varadhan
---
v2: prepare to remove sk_error_queue based path; remove recvmsg
PF_RDS sockets pass up cookies for zerocopy completion as ancillary
data. Update msg_zerocopy to reap this information.
Signed-off-by: Sowmini Varadhan
---
v2: receive zerocopy completion notification as POLLIN
v3: drop ncookies arg in do_process_zerocopy_cookies; Reverse christmas
tree
es support for zerocopy completion notification on
MSG_ERRQUEUE for PF_RDS sockets.
Signed-off-by: Sowmini Varadhan
---
v2: remove sk_error_queue path; lot of cautionary checks rds_recvmsg_zcookie()
and callers to make sure we dont remove cookies from the queue and then
fail to pass it up to
sk_error_queue support
v3: incorporated additional code review comments (details in each patch)
Sowmini Varadhan (3):
selftests/net: revert the zerocopy Rx path for PF_RDS
rds: deliver zerocopy completion notification with data
selftests/net: reap zerocopy completions passed up as ancillary data
On (02/25/18 10:56), Willem de Bruijn wrote:
> > @@ -91,22 +85,19 @@ static void rds_rm_zerocopy_callback(struct rds_sock
> > *rs,
> > spin_unlock_irqrestore(&q->lock, flags);
> > mm_unaccount_pinned_pages(&znotif->z_mmp);
> > consume_skb(rds_skb_fro
pointed out that socket functions block
if sk_err is non-zero, thus if the RDS code does not plan/need
to use sk_error_queue path for completion notification, it
is preferable to remove the sk_errror_queue related paths in
RDS.
Both of these goals are implemented in this series.
Sowmini Varadhan (3
PF_RDS sockets pass up cookies for zerocopy completion as ancillary
data. Update msg_zerocopy to reap this information.
Signed-off-by: Sowmini Varadhan
---
v2: receive zerocopy completion notification as POLLIN
tools/testing/selftests/net/msg_zerocopy.c | 60
1
In preparation for optimized reception of zerocopy completion,
revert the Rx side changes introduced by Commit dfb8434b0a94
("selftests/net: add zerocopy support for PF_RDS test case")
Signed-off-by: Sowmini Varadhan
---
v2: prepare to remove sk_error_queue based path; remove recvmsg
es support for zerocopy completion notification on
MSG_ERRQUEUE for PF_RDS sockets.
Signed-off-by: Sowmini Varadhan
---
v2: remove sk_error_queue path; lot of cautionary checks rds_recvmsg_zcookie()
and callers to make sure we dont remove cookies from the queue and then
fail to pass it up
1 - 100 of 632 matches
Mail list logo