On (03/27/17 03:06), Zhu Yanjun wrote:
> Date: Mon, 27 Mar 2017 03:06:26 -0400
> From: Zhu Yanjun
> To: yanjun@oracle.com, santosh.shilim...@oracle.com,
> netdev@vger.kernel.org, linux-r...@vger.kernel.org,
> rds-de...@oss.oracle.com, junxiao...@oracle.com, joe@oracle.com
> Subject: [PAT
On (03/27/17 16:05), Yanjun Zhu wrote:
> Sorry. I just made simple test. It seems that it worked well. Would you like
> to show me some test about this patch?
>
Your patch is a non-trivial bug. Dont do this.
Please read the comments above the "goto rst_nsk" in that function.
Also note the commen
, rds_connection_worker
should check that cp_index > 0.
Signed-off-by: Sowmini Varadhan
---
net/rds/threads.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/rds/threads.c b/net/rds/threads.c
index e36e333..3e447d0 100644
--- a/net/rds/threads.c
+++ b/net/rds/thread
error: rds_conn_shutdown() should continue the
shutdown, and there is no need to log noisy messages about this event.
Signed-off-by: Sowmini Varadhan
---
net/rds/connection.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/net/rds/connection.c b/net/rds
A couple of minor bugfixes that showed up during testing
Sowmini Varadhan (2):
rds: tcp: allow progress of rds_conn_shutdown if the rds_connection
is marked ERROR by an intervening FIN
rds: tcp: canonical connection order for all paths with index > 0
net/rds/connection.c |
On (04/15/17 21:40), Andrew Lunn wrote:
>
> In my case, lan3 is up and idle, there are no packets flying around to
> be captured. So i would expect pcap_next_ex() to exit once a second,
> with a return value of 0. But it is not, it blocks and stays blocked.
:
> Looking at the libpcap source, th
On (04/18/17 11:14), Mike Maloney wrote:
> Change 'psock_fanout' to use SOCK_RAW so that the CBPF program used with
> SO_ATTACH_FILTER can examine the entire frame. Create a new CBPF
> program for use with PACKET_FANOUT_DATA which ignores the header, as it
> cannot see the ethernet header.
Fix lo
On (04/18/17 11:56), Mike Maloney wrote:
> I am not 100% sure what you are asking for, as the instructions you
> can feed to bpf_asm are already commented to the right of the program.
oh, right, I missed that you had commented the BPF_STMT macros
with the equivalent bpf_asm inovcation.
Looks goo
gned-off-by: Sowmini Varadhan
---
include/linux/netdevice.h | 11 ++-
net/packet/af_packet.c| 27 +--
2 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 3868c32..9d49898 100644
--- a/in
On (01/25/17 15:06), Paul Durrant wrote:
>
> Making netfront cope with a fully non-linear skb looks like it would
> be quite intrusive and probably not worth it so I opted for just doing
> the ETH_HLEN pull-tail if necessary. Can you check it works for you?
I tested it, and it works fine, but n
On (01/26/17 15:21), Willem de Bruijn wrote:
> > If the application has provided fewer than hard_header_len bytes,
> > dev_validate_header() will zero out the skb->data as needed. This is
> > acceptable for SOCK_DGRAM/PF_PACKET sockets but in all other cases,
>
> This was added not for datagram so
On (01/26/17 19:08), Willem de Bruijn wrote:
>
> Thanks for the context. ax25_addr_parse doesn't adjust length, it only
> verifies that the contents of the variable length header matches
> protocol spec. I don't think that it or the .validate callback have to
> be modified to return length.
Yes,
On (01/27/17 09:37), Willem de Bruijn wrote:
> The immediate problem you were facing is that dev_validate_header
> accepts values smaller than hard_header_len even for protocols with
> fixed header lengths.
Yes!
> This is a consequence of that CAP_SYS_RAWIO branch. Without it,
> dev_validate_head
On (01/27/17 10:28), Willem de Bruijn wrote:
> > Would it make sense to only do the CAP_SYS_RAWIO branch if the
> > driver declares itself to have variable length L2 headers, via, e.g.,
> > some priv flag?
>
> At the time, the comments were not specific to AX25. Again, we should
> probably put tha
On (01/27/17 14:29), Willem de Bruijn wrote:
>
> As your patch state, the contract is that any packet delivered to a
> driver has the entire L2 in its linear section. Drivers are not required
> to be robust against shorter packets, so there is no reason to test
> those.
>
> One option is to limit
On (01/27/17 15:51), Willem de Bruijn wrote:
:
> - limit capable() check to drivers with with .validate callback
(aka second option below)
:
> - let privileged applications shoot themselves in the foot (change nothing).
> The second will break variable length header protocols unless
> yo
On (01/27/17 19:19), Willem de Bruijn wrote:
> > other than ax25, are there variable length header protocols out there
> > without ->validate, and which need the CAP_RAW_SYSIO branch?
>
> I don't know. An exhaustive search of protocols (by header_ops) may be
> needed to say for sure.
>
> If there
On (01/27/17 13:33), John Fastabend wrote:
>
> This is an experimental implementation of rx zero copy for af_packet.
> Its a bit rough and likely has errors but the plan is to clean it up
> over the next few months.
>
> And seeing I said I would post it in another thread a few days back
> here it
On (02/28/17 15:22), Dmitry Vyukov wrote:
>
> Hello,
>
> I've got the following report while running syzkaller fuzzer on
> linux-next/8d01c069486aca75b8f6018a759215b0ed0c91f0. So far it
> happened only once. net was somehow deleted from underneath
> inet_create. I've noticed that rds uses sock_cr
On (02/28/17 16:49), Dmitry Vyukov wrote:
>
> Grepping "socket" there, it was doing lots of things with sockets. Are
> we looking for some particular socket type? If there are few programs
> that create sockets of that type, then we can narrow down the set:
Yes, we are looking for PF_RDS/AF_RDS -
On (02/28/17 17:32), Dmitry Vyukov wrote:
> Not reproducible so far.
>
> rds is compiled into kernel (no modules):
> CONFIG_RDS=y
> CONFIG_RDS_TCP=y
I see. So if it never gets unloaded, the rds_connections "should"
be around forever.. let me inspect code and see if I spot some
race-window..
>
On (02/28/17 17:51), Dmitry Vyukov wrote:
> Searching other crashes for "net/rds" I found 2 more crashes that may
> be related. They suggest that the delayed works are not properly
> stopped when the socket is destroyed. That would explain how
> rds_connect_worker accesses freed net, right?
yes, I
On (02/28/17 18:45), Dmitry Vyukov wrote:
>
> Yes, I can now apply custom patches to the bots. However, it fired
> only 3 times, so it will give weak signal. But at least it will test
> that the patch does not cause other bad things.
Ok, let me do my bit of homework on this one and get back to yo
Just posted an RFC patch, that I'm also testing here..
hopefully we'll se the pr_info light up, and know that the problematic
situation actually happened (I'll remove the pr_info if/when this
gets submitted as a non-RFC patch).. thanks for helping with testing
this..
--Sowmini
On (03/01/17 00:14), Dmitry Vyukov wrote:
>
> But the other 2 use-after-frees happened on cp->cp_send_w. Shouldn't
> we cancel it as well? And cp_recv_w?
yes, good point, I missed that. let me see if I can refactor the code
to release the netns as the last thing before free..
Actually, I'm not sure if I can assert that these are all manifestations
of the same bug- was a netns-delete involved in this one as well?
I see:
> BUG: KASAN: use-after-free in memcmp+0xe3/0x160 lib/string.c:768 at
:
> memcmp+0xe3/0x160 lib/string.c:768
:
> rds_find_bound+0x4fe/0x8a0
This is a test patch being supplied for a trial run on syzkaller.
Explicitly cancel the workq before releasing resources that
will allow netns deletion, so that the connect request does
not trip up on a use-after free of the netns afterward.
Signed-off-by: Sowmini Varadhan
Reported-by: Dmitry
the others?
Reported-by: Dmitry Vyukov
Signed-off-by: Sowmini Varadhan
---
net/rds/connection.c |1 +
net/rds/rds.h|6 +++---
net/rds/tcp.c|4 ++--
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/net/rds/connection.c b/net/rds/connection.c
index 0e04dcc..1fa7
On (03/02/17 11:07), Dmitry Vyukov wrote:
>
> The other 2 does not look like net-related, but you also mailed patch
> "Cancel any pending connection attempts before taking down
> connection", which looks like it should fix the other 2, right?
no, that patch was still broken.. because, as you poin
+0x1e7/0x370 [rds_tcp]
tcp_read_sock+0x96/0x1c0
rds_tcp_recv_path+0x65/0x80 [rds_tcp]
:
Signed-off-by: Sowmini Varadhan
---
net/rds/tcp.c | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/net/rds/tcp.c b/net/rds/tcp.c
index 65c8e3b..fbf807a
: Dmitry Vyukov
Signed-off-by: Sowmini Varadhan
---
net/rds/connection.c |1 +
net/rds/rds.h|6 +++---
net/rds/tcp.c|4 ++--
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/net/rds/connection.c b/net/rds/connection.c
index 0e04dcc..1fa75ab 100644
--- a/net/rds
address a:b:c:d:e:f blue0 type macvlan
ip link set blue0 netns blue
ip netns exec blue ip addr add 12.0.0.18/24 dev blue0
ip netns exec blue ifconfig blue0 up
sleep 3;
done
Sowmini Varadhan (3):
rds: tcp: Take explicit refcounts on struct net
rds: tcp
h acceptor workq
sock_release(listen socket)
Signed-off-by: Sowmini Varadhan
---
net/rds/tcp.c| 15 ++-
net/rds/tcp.h|2 +-
net/rds/tcp_listen.c |9 +++--
3 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/net/rds/tcp.c b/net/rds/tcp.c
index
On (03/14/17 09:14), Dmitry Vyukov wrote:
> Another one now involving rds_tcp_listen_stop
:
> kworker/u4:1/19 is trying to acquire lock:
> (sk_lock-AF_INET){+.+.+.}, at: [] lock_sock
> include/net/sock.h:1460 [inline]
> (sk_lock-AF_INET){+.+.+.}, at: []
> rds_tcp_listen_stop+0x5c/0x150 net/rds
On (03/15/17 10:08), Dmitry Vyukov wrote:
> After I've applied the patch these reports stopped to happen, and I
> have not seem any other reports that look relevant.
> However, it there was one, but it looks like a different issue and it
> was probably masked by massive amounts of original deadlock
Commit 7f953ab2ba46 ("af_packet: TX_RING support for TPACKET_V3")
now makes it possible to use TX_RING with TPACKET_V3, so make the
the relevant information available via 'ss -e -a --packet'
Signed-off-by: Sowmini Varadhan
---
net/packet/diag.c |3 +--
1 files changed
On (01/11/17 14:48), Jonathan T. Leighton wrote:
>
> I would say that an IPv6 socket binds to an IPv4-mapped IPv6
> address, but yes - using it to connect to an IPv6 address would be
> an application bug. It also think that having connect() spend 2
> minutes sending packets containing an illegal s
On (01/11/17 12:43), Eric Dumazet wrote:
>
> On Wed, 2017-01-11 at 14:59 -0500, Sowmini Varadhan wrote:
>
> > I think the RFC states somewhere that you should never ever
> > send out a v4 mapped address on the wire.
>
> Can you point the exact RFC ?
>
> ht
/IPv4 packets that meet the ip_len and test-character
requirements. Include the bpf_asm src as a comment, in case this
needs to be enhanced in the future
Signed-off-by: Sowmini Varadhan
---
tools/testing/selftests/net/psock_lib.h | 39 +-
1 files changed, 32
As I was playing around with pf_packet, I accidentally wrote
a buggy application program that bzero'ed the msghdr, then set
up the msg_name, msg_namelen correctly, and then did a sendmsg
on the pf_packet/SOCK_RAW fd.
This causes packet_snd to set up an skb with a lot of issues,
e.g., skb->len = 0,
On (01/19/17 09:36), Paul Durrant wrote:
>
> Hi Sowmini,
>
> Sounds like a straightforward bug to me... netfront should be able
> to handle an empty skb and clearly, if it's relying on skb_headlen()
> being non-zero, that's not the case.
>
> Paul
I see. Seems like there are 2 things broken
On (01/19/17 11:31), Paul Durrant wrote:
> Sowmini,
>
> Yeah, it would be useful to verify any change fixes the particular
> issue you're seeing so please share the program. For the non-empty
> non-linear case I'd hope that catching this and doing a pull of some
> sensible amount of header (which
On (01/19/17 11:37), David Miller wrote:
>
> I thought we had code which made sure that at least a minimal
> link layer header was present in the SKB?
>
> Specifically I'm talking about the dev_validate_header() check.
> That is supposed to protect us from these kinds of situations.
ah, but I ru
On (01/19/17 13:47), Sowmini Varadhan wrote:
> > Specifically I'm talking about the dev_validate_header() check.
> > That is supposed to protect us from these kinds of situations.
>
> ah, but I run my pf_packet application as root, so I have
> capable(CAP_SYS_RAW
On (01/20/17 14:30), David Miller wrote:
>
> CAP_SYS_RAWIO or not, the contract we have with the device is that
> there will be at least enough bytes to cover a link layer header.
I see. If that's the case (for all the kernel-driver interfaces),
then the xen_netfront driver is probably not requi
.
This patch enables TPACKET_V2 compatible Tx features in TPACKET_V3
so that _v3 supports at least as many features as _v2.
Signed-off-by: Sowmini Varadhan
---
Documentation/networking/packet_mmap.txt |6 --
net/packet/af_packet.c | 23 +++
2 files
On (12/30/16 16:33), Willem de Bruijn wrote:
>
> Once we define the interface as equivalent to v2, we cannot redefine it to
> support v3-only features later.
What v3 only features do we think we want to support?
Tpacket_v3 went in
commit f6fb8f100b807378fda19e83e5ac6828b638603a
:
Date:
On (12/30/16 18:39), Willem de Bruijn wrote:
>
> Variable length slots seems like the only one from that list that
> makes sense on Tx.
>
> It is already possible to prepare multiple buffers before triggering
> transmit, so the block-based signal moderation is not very relevant.
FWIW, here is ou
On (12/30/16 23:59), Willem de Bruijn wrote:
> > Actually I'm not averse to looking at extensions (or at least,
> > place-holders) to allow variable sized slots- do you have any
> > suggestions?
>
> It is probably enough to just enforce that tp_next_offset is always
> sane. Either that it points t
are
supported on TX_RING for TPACKET_V3.
- patch 2 in this series adds a test case and sample code for
(TPACKET_V3, PACKET_TX_RING) in testing/selftests
Sowmini Varadhan (2):
af_packet: TX_RING support for TPACKET_V3
tools: test case for TPACKET_V3/TX_RING support
Documentation/networking
only support fixed size Tx frames for TPACKET_V3,
and requires that tp_next_offset must be zero.
Signed-off-by: Sowmini Varadhan
---
v2: sanity checks on tp_next_offset and corresponding Doc updates
as suggested by Willem de Bruijn
Documentation/networking/packet_mmap.txt |9
Add a test case and sample code for (TPACKET_V3, PACKET_TX_RING)
Signed-off-by: Sowmini Varadhan
---
v2: Added test case.
tools/testing/selftests/net/psock_tpacket.c | 110 ++-
1 files changed, 109 insertions(+), 1 deletions(-)
diff --git a/tools/testing/selftests/net
On (01/02/17 17:31), Willem de Bruijn wrote:
>
> Thanks for adding this.
>
> walk_v3_tx is almost identical to walk_v1_v2_tx. That function can
> just be extended to add a v3 case where it already multiplexes between
> v1 and v2.
I looked at that, but the sticky point is that v1/v2 sets up the
r
On (01/02/17 17:57), Willem de Bruijn wrote:
> One more point. We should validate the tpacket_req3 input and fail if
> unsupported options are passed. Specifically, fail if any of
> {tp_retire_blk_tov, tp_sizeof_priv, tp_feature_req_word} is non-zero.
>
> Otherwise looks good to me.
Ok, I'll send
Add a test case and sample code for (TPACKET_V3, PACKET_TX_RING)
Signed-off-by: Sowmini Varadhan
---
v2: Added test case.
v3: refactored code to have a single walk_tx() function that handles all three
TPACKET versions.
tools/testing/selftests/net/psock_tpacket.c | 91
: additional sanity checks for setsockopt
input for TX_RING/TPACKET_V3. Refactored psock_tpacket.c
test code to avoid code duplication from V2.
Sowmini Varadhan (2):
af_packet: TX_RING support for TPACKET_V3
tools: test case for TPACKET_V3/TX_RING support
Documentation/networking
only support fixed size Tx frames for TPACKET_V3,
and requires that tp_next_offset must be zero.
Signed-off-by: Sowmini Varadhan
---
v2: sanity checks on tp_next_offset and corresponding Doc updates
as suggested by Willem de Bruijn
v3: additional sanity checking of input in packet_set_ring
passed up
with the tpacket rx frame and making sure that packets counted
toward the test are those received on lo.
Sowmini Varadhan (2):
tools: tighten conditions checked in sock_setfilter
tools: psock_tpacket: verify that packet was received on lo before
counting it
tools/tes
packets by examining the sll_ifindex sent
up in each frame and ensuring that this is the same as the ifindex
that was used in bind_ring()
Signed-off-by: Sowmini Varadhan
---
tools/testing/selftests/net/psock_tpacket.c | 25 -
1 files changed, 20 insertions(+), 5 deletions
ore readable.
Signed-off-by: Sowmini Varadhan
---
tools/testing/selftests/net/psock_lib.h | 28 +---
1 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/tools/testing/selftests/net/psock_lib.h
b/tools/testing/selftests/net/psock_lib.h
index 24bc7ec..e
On (01/04/17 09:30), Willem de Bruijn wrote:
>
> The common and simpler solution to this problem is to open the socket
> with protocol 0 to reject all packets, add the BPF filter and only then bind
> with sll_ifindex set to lo. That way no false positives can arrive.
Yes, I thought of that too (a
On (01/04/17 10:03), Willem de Bruijn wrote:
>
> This approach is less restrictive. It still allows incorrect packets
> to be enqueued in the time between the socket call and attaching the
> bpf filter. Also, if packets are restricted to a single packet, using
> bind with sll_ifindex is simpler.
On (01/04/17 11:07), Willem de Bruijn wrote:
>
> Please do. Then the patch is just a one-line change to
> the third argument of the socket call. Thanks!
ok but it's going to be more than a one-line change. Today you
have
sock = pfsocket(version);
memset(&ring, 0, sizeof(ring));
On (01/04/17 11:24), Willem de Bruijn wrote:
>
> Oh, good point. It may require some more refactoring. Feel free to
> leave it for me if you prefer.
actually it may not be so bad, let me do it, since I already have
a reliable way of reproducing this..
--Sowmini
packets that will be passed up are
those received on loopback that pass the attached filter.
Signed-off-by: Sowmini Varadhan
---
v2: patch reworked based on comments from Willem de Bruijn
tools/testing/selftests/net/psock_tpacket.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff
This commit hardens the conditions checked by the filter so
that only UDP/IPv4 packets with the matching length and test-character
will be permitted by the filter. The filter has been cleaned up
to explicitly use the BPF macros to make it more readable.
Signed-off-by: Sowmini Varadhan
Acked-by:
inding the socket to ETH_P_ALL and lo.
Changes from v2: patch 2 reworked based on review comments.
Sowmini Varadhan (2):
tools: tighten conditions checked in sock_setfilter
tools: psock_tpacket: block Rx until socket filter has been added and
socket has been bound to loopback.
too
packets that will be passed up are
those received on loopback that pass the attached filter.
Signed-off-by: Sowmini Varadhan
---
v2: patch reworked based on comments from Willem de Bruijn
tools/testing/selftests/net/psock_tpacket.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff
This commit hardens the conditions checked by the filter so
that only UDP/IPv4 packets with the matching length and test-character
will be permitted by the filter. The filter has been cleaned up
to explicitly use the BPF macros to make it more readable.
Signed-off-by: Sowmini Varadhan
Acked-by:
inding the socket to ETH_P_ALL and lo.
v2: patch 2 reworked based on review comments.
v3: Shuah Khan nit.
Sowmini Varadhan (2):
tools: psock_lib: tighten conditions checked in sock_setfilter
tools: psock_tpacket: block Rx until socket filter has been added and
socket has been bound t
On (01/04/17 23:16), Daniel Borkmann wrote:
>
> Just reading up on the thread, sorry to jump in late. Can't you just
> use the generated code from bpf_asm (tools/net/) and add the asm program
> as a comment above? Something like we do in net/core/ptp_classifier.c +13.
I was actually using the exa
On (01/04/17 23:26), Daniel Borkmann wrote:
>
> >>As it stands it makes it a bit harder to parse / less readable with macros
> >>actually. Rest seems fine, thanks.
Usually macros are there (a) as an abstraction so you
dont have to hard-code things, and, (b) to make things
more readable. (maybe
On (01/04/17 15:37), Shuah Khan wrote:
> Looks like you have to do v4 anyway, please make sure your comment
> block is one of the acceptable formats based on coding style:
I'm not sure about that. I can just keep patch 2.
thanks,
--Sowmini
On (01/04/17 15:37), Shuah Khan wrote:
> > + /* the filter below checks for all of the following conditions that
> > +* are based on the contents of create_payload()
> > +* ether type 0x800 and
> > +* ip proto udp and
> > +* ip len == ip_len and
> > +* udp[38] == 'a' o
unreachable here, but since 7f953ab2ba46 ("af_packet:
> TX_RING support for TPACKET_V3") it's not anymore. Fix it by filling
> the timestamp back into the ring slot.
Acked-by: Sowmini Varadhan
--Sowmini
On (01/04/17 16:26), Shuah Khan wrote:
>
> Could you please split this patch into two. Hardening part in one and
> the cleanup in a separate patch. This way I can get the hardening fix
> into 4.10 in my next Kselftest update. Cleanup patch can go in later.
>
> thanks,
> -- Shuah
I'm a little con
packets that will be passed up are
those received on loopback that pass the attached filter.
Signed-off-by: Sowmini Varadhan
---
v2: patch reworked based on comments from Willem de Bruijn
v4: dropped patch 1/2: leave it soft;
Send patch 2/2 to the owner of tools/testing/selftests/net/ listed in
On (02/07/17 15:57), Willem de Bruijn wrote:
>
> From: Willem de Bruijn
>
> The stack must not pass packets to device drivers that are shorter
> than the minimum link layer header length.
Acked-by: Sowmini Varadhan
On (02/07/17 15:57), Willem de Bruijn wrote:
> @@ -2816,8 +2816,9 @@ static int packet_snd(struct socket *sock, struct
> msghdr *msg, size_t len)
> err = -ENOBUFS;
> hlen = LL_RESERVED_SPACE(dev);
> tlen = dev->needed_tailroom;
> - skb = packet_alloc_skb(sk, hlen + tlen, hlen
On (02/07/17 14:12), Shannon Nelson wrote:
> +
> + /* we don't expect any other bits */
> + BUG_ON(port->rx_event & ~(LDC_EVENT_DATA_READY |
> + LDC_EVENT_RESET |
> + LDC_EVENT_UP));
> +
> + /* RESET takes precedent over any ot
On (02/08/17 08:28), Shannon Nelson wrote:
> The existing code does this as well - if it first finds a RESET, it handles
> it then hits the return 0. Next if it finds the UP, it does the goto back
> to the ldc_ctrl: to process, and hits the same return 0. Only if neither of
> these bits have been
On (02/08/17 08:37), Willem de Bruijn wrote:
> Date: Wed, 8 Feb 2017 08:37:19 -0800
> From: Willem de Bruijn
> To: Sowmini Varadhan
> Cc: Network Development , David Miller
> , Eric Dumazet , Dmitry
> Vyukov , Willem de Bruijn
> Subject: Re: [PATCH net 2/2] packet: roun
On (02/09/17 14:14), Dmitry Vyukov wrote:
>
> Call Trace:
:
> packet_rcv_has_room+0x25/0xb0 net/packet/af_packet.c:1308
> fanout_demux_rollover+0x3bb/0x6b0 net/packet/af_packet.c:1388
> packet_rcv_fanout+0x674/0x800 net/packet/af_packet.c:1490
> dev_queue_xmit_nit+0x73a/0xa90 net/core/dev.c
On (02/09/17 19:19), Eric Dumazet wrote:
>
> More likely the bug is in fanout_add(), with a buggy sequence in error
> case, and not correct locking.
>
> kfree(po->rollover);
> po->rollover = NULL;
>
> Two cpus entering fanout_add() (using the same af_packet socket,
> syzkaller courtesy...) might
On (02/10/17 10:00), Cong Wang wrote:
> My understanding about the race here is packet_release() doesn't
> wait for flying packets correctly, which leads to a flying packet still
> refers to the struct sock which is being released.
>
> This could happen because struct packet_fanout is refcn'ted, i
On (02/10/17 10:02), Eric Dumazet wrote:
> At least, Anoob patch is making a step into the right direction ;)
> https://patchwork.ozlabs.org/patch/726532/
I've not been able to reproduce Dmitry's panic (though I did not try
very hard either) but there's a call to fanout_release from packet_release
On (02/20/17 10:19), David Miller wrote:
>
> The correct fix it to use "__u8", "__u64", etc.
So the rest of rds.h uses uint8_t, uint32_t etc
Perhaps (I'm not sure of the origins) this was because
of the shared OpenIB.org BSD license etc using __u8 in
one place and uint8_t in another would seem i
I have a question about linux support for IPsec PFP (as defined in
rfc 4301). I am assuming this exists, and is accessible from uspace,
in which case I need some hints on how to set it up.
Assuming I have a server listening at port 5001 that I want to
secure via ipsec. Suppose I want to make sure
On (05/02/17 09:58), Paul Wouters wrote:
>I think you want to use Opportunistic IPsec, eg see
>https://libreswan.org/wiki/HOWTO:_Opportunistic_IPsec
I dont think that what I want is opportunistic ipsec..
taking an extreme example, I can set up the ipsec tunnels with
esp-null for *.5001
On (05/04/17 19:42), Oleg wrote:
>
> Hi, all.
>
> It seems struct ip and struct iphdr are similar: struct ip, despite of
> it name, doesn't contain anything but ip header.
>
> So, my noob question, what is the difference between them?
>
> Thanks.
BSD vs linux?
struct ip is a BSD-ism, intend
On (05/05/17 10:45), Steven Whitehouse wrote:
>
> I do wonder if the man page for recvmsg is wrong, or at least a bit
> confusing. SOCK_SEQPACKET is stream based not message based - it just
> happens to have EOR markers in the stream. There is no reason that the whole
> message needs to be returne
-condition
that has always existed, but is now more easily encountered with mprds.
Patch 2 is code refactoring. Patches 4 and 5 are Documentation updates.
Sowmini Varadhan (5):
RDS: TCP: avoid bad page reference in rds_tcp_listen_data_ready
RDS: TCP: Reduce code duplication in rds_tcp_reset_callbacks
: Sowmini Varadhan
---
net/rds/bind.c|6
net/rds/connection.c | 17 +--
net/rds/message.c |1 +
net/rds/rds.h | 25 +++-
net/rds/recv.c| 75 +
net/rds/send.c| 71
Some code duplication in rds_tcp_reset_callbacks() can be avoided
by having the function call rds_tcp_restore_callbacks() and
rds_tcp_set_callbacks().
Acked-by: Santosh Shilimkar
Signed-off-by: Sowmini Varadhan
---
net/rds/tcp.c | 22 --
1 files changed, 4 insertions
Document the design of mprds, covering a brief description
of the motivation, data-structures and modifications to the
RDS control plane.
Acked-by: Santosh Shilimkar
Signed-off-by: Sowmini Varadhan
---
Documentation/networking/rds.txt | 55 ++
1 files
page fault on ready
In the above sequence, we end up with a panic on a bad page reference
when trying to execute (*ready)(). Instead we need to call
sock_def_readable() safely, which is what this patch achieves.
Acked-by: Santosh Shilimkar
Signed-off-by: Sowmini Varadhan
---
net/rds/tcp.c
Update the documentation to describe the changes added by
commit 8ba38460f363 ("net/rds Add getsockopt support for SO_RDS_TRANSPORT")
Acked-by: Santosh Shilimkar
Signed-off-by: Sowmini Varadhan
---
Documentation/networking/rds.txt | 17 -
1 files changed, 16 insert
Commit 9f12df906cd8 ("ixgbe: Store VXLAN port number in network order")
incorrectly checks for hdr.ipv4->protocol != IPPROTO_UDP
in ixgbe_atr(). This check should be for "==" instead.
Signed-off-by: Sowmini Varadhan
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |2
Two bug fixes:
- ixgbe_atr() should check for protocol == udp in the
skb->encapsulation case (instead of !=)
- ixgbe_atr() should make sure the non-paged data has the
needed network/transport header for computing l4_proto.
Sowmini Varadhan (2):
ixgbe: ixgbe_atr() should access udp_hdr(
are
already available in the non-paged header dat. The assumption
is that the caller has set this up if l4_proto based Tx
steering is desired.
Signed-off-by: Sowmini Varadhan
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 18 ++
1 files changed, 18 insertions(+), 0
401 - 500 of 632 matches
Mail list logo
