Re: [PATCH] mwifiex: add __GFP_REPEAT to skb allocation call

On Tue, Mar 29, 2016 at 12:47:20PM +0800, Wei-Ning Huang wrote: > "single skb allocation failure" happens when system is under heavy > memory pressure. Add __GFP_REPEAT to skb allocation call so kernel > attempts to reclaim pages and retry the allocation. Oh, that's interesting, we're back to

Re: am335x: no multicast reception over VLAN

Hi Mugunthan, On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N wrote: > Hi Yegor > > On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote: >> I have an am335x based board using CPSW in Dual EMAC mode. Without >> VLAN IDs I can receive and send multicast packets [1]. When

Re: [PATCH net] team: team should sync the port's uc/mc addrs when add a port

On Mon, Mar 28, 2016 at 9:42 AM, Xin Long wrote: > There is an issue when we use mavtap over team: > When we replug nic links from team0, the real nics's mc list will not > include the maddr for macvtap any more. then we can't receive pkts to > macvtap device, as they are

Re: [net PATCH] gro: Allow tunnel stacking in the case of FOU/GUE

On Mon, Mar 28, 2016 at 9:15 PM, Alex Duyck wrote: > On Mon, Mar 28, 2016 at 9:01 PM, Tom Herbert wrote: >> On Mon, Mar 28, 2016 at 8:27 PM, Alexander Duyck >> wrote: >>> On Mon, Mar 28, 2016 at 8:17 PM, Tom Herbert

[PATCH] mwifiex: add __GFP_REPEAT to skb allocation call

"single skb allocation failure" happens when system is under heavy memory pressure. Add __GFP_REPEAT to skb allocation call so kernel attempts to reclaim pages and retry the allocation. Signed-off-by: Wei-Ning Huang --- drivers/net/wireless/marvell/mwifiex/sdio.c | 12

Re: [PATCH 3/4] wcn36xx: Transition driver to SMD client

On Mon, Jan 11, 2016 at 1:02 AM, Eugene Krasnikov wrote: > Better late than never! Looks good to me. > Unfortunately I ran into an issue with ordering of operations between the WiFi driver and the wcnss_ctrl driver. So an updated series is on the way, but this depends on

Re: [RFC PATCH] tcp: Add SOF_TIMESTAMPING_TX_EOR and allow MSG_EOR in tcp_sendmsg

On Sun, Mar 27, 2016 at 10:42 PM, Martin KaFai Lau wrote: > > On Fri, Mar 25, 2016 at 04:05:51PM -0700, Yuchung Cheng wrote: > > Looks like an interesting and useful patch. Since HTTP2 allows > > multiplexing data stream frames from multiple logical streams on a > > single socket, >

Re: [PATCH net] team: team should sync the port's uc/mc addrs when add a port

From: Xin Long Date: Tue, 29 Mar 2016 00:42:31 +0800 > There is an issue when we use mavtap over team: > When we replug nic links from team0, the real nics's mc list will not > include the maddr for macvtap any more. then we can't receive pkts to > macvtap device, as they

Re: [net PATCH] gro: Allow tunnel stacking in the case of FOU/GUE

On Mon, Mar 28, 2016 at 9:01 PM, Tom Herbert wrote: > On Mon, Mar 28, 2016 at 8:27 PM, Alexander Duyck > wrote: >> On Mon, Mar 28, 2016 at 8:17 PM, Tom Herbert wrote: >>> On Mon, Mar 28, 2016 at 6:54 PM, Jesse Gross

Re: [PATCH net 0/4] misc. small fixes.

From: Michael Chan Date: Mon, 28 Mar 2016 19:46:03 -0400 > Misc. small fixes for net. Series applied, thanks Michael.

Re: [net PATCH] gro: Allow tunnel stacking in the case of FOU/GUE

On Mon, Mar 28, 2016 at 8:27 PM, Alexander Duyck wrote: > On Mon, Mar 28, 2016 at 8:17 PM, Tom Herbert wrote: >> On Mon, Mar 28, 2016 at 6:54 PM, Jesse Gross wrote: >>> On Mon, Mar 28, 2016 at 6:24 PM, Tom Herbert

Re: am335x: no multicast reception over VLAN

Hi Yegor On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote: > I have an am335x based board using CPSW in Dual EMAC mode. Without > VLAN IDs I can receive and send multicast packets [1]. When I create > VLAN ID: > > ip link add link eth1 name eth1.100 type vlan id 100 > ip addr add

Re: [net PATCH] gro: Allow tunnel stacking in the case of FOU/GUE

On Mon, Mar 28, 2016 at 8:17 PM, Tom Herbert wrote: > On Mon, Mar 28, 2016 at 6:54 PM, Jesse Gross wrote: >> On Mon, Mar 28, 2016 at 6:24 PM, Tom Herbert wrote: >>> On Mon, Mar 28, 2016 at 4:58 PM, Alexander Duyck

Re: [net PATCH] gro: Allow tunnel stacking in the case of FOU/GUE

On Mon, Mar 28, 2016 at 6:54 PM, Jesse Gross wrote: > On Mon, Mar 28, 2016 at 6:24 PM, Tom Herbert wrote: >> On Mon, Mar 28, 2016 at 4:58 PM, Alexander Duyck wrote: >>> This patch should fix the issues seen with a recent fix to

Re: [net PATCH] gro: Allow tunnel stacking in the case of FOU/GUE

On Mon, Mar 28, 2016 at 4:58 PM, Alexander Duyck wrote: > This patch should fix the issues seen with a recent fix to prevent > tunnel-in-tunnel frames from being generated with GRO. The fix itself is > correct for now as long as we do not add any devices that support >

Re: [PATCH net v2 2/3] tunnels: Don't apply GRO to multiple layers of encapsulation.

On Mon, Mar 28, 2016 at 5:50 PM, Tom Herbert wrote: > On Mon, Mar 28, 2016 at 4:34 PM, Jesse Gross wrote: >> * A packet is received that is encapsulated with two layers of GRE. It >> looks like this: Eth|IP|GRE|IP|GRE|IP|TCP >> * The packet is processed

Re: [net PATCH] gro: Allow tunnel stacking in the case of FOU/GUE

On Mon, Mar 28, 2016 at 6:24 PM, Tom Herbert wrote: > On Mon, Mar 28, 2016 at 4:58 PM, Alexander Duyck wrote: >> This patch should fix the issues seen with a recent fix to prevent >> tunnel-in-tunnel frames from being generated with GRO. The fix itself

Re: [net PATCH] gro: Allow tunnel stacking in the case of FOU/GUE

On Mon, Mar 28, 2016 at 4:58 PM, Alexander Duyck wrote: > This patch should fix the issues seen with a recent fix to prevent > tunnel-in-tunnel frames from being generated with GRO. The fix itself is > correct for now as long as we do not add any devices that support >

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

On Mon, 2016-03-28 at 19:54 -0400, David Miller wrote: > From: Eric Dumazet > Date: Mon, 28 Mar 2016 13:51:46 -0700 > > > On Mon, 2016-03-28 at 13:46 -0700, Eric Dumazet wrote: > > > >> We have at least 384 bytes of padding in skb->head (this is struct > >>

Re: [net PATCH] gro: Allow tunnel stacking in the case of FOU/GUE

On Mon, Mar 28, 2016 at 4:58 PM, Alexander Duyck wrote: > This patch should fix the issues seen with a recent fix to prevent > tunnel-in-tunnel frames from being generated with GRO. The fix itself is > correct for now as long as we do not add any devices that support >

Re: [PATCH net v2 2/3] tunnels: Don't apply GRO to multiple layers of encapsulation.

On Mon, Mar 28, 2016 at 4:34 PM, Jesse Gross wrote: > On Mon, Mar 28, 2016 at 3:10 PM, Tom Herbert wrote: >> On Mon, Mar 28, 2016 at 1:34 PM, Alexander Duyck >> wrote: >>> On Mon, Mar 28, 2016 at 1:03 PM, Tom Herbert

Re: [PATCH net,stable] qmi_wwan: add "D-Link DWM-221 B1" device id

From: Bjørn Mork Date: Mon, 28 Mar 2016 22:38:16 +0200 > Thomas reports: > "Windows: ... > Linux: ... > Reported-by: Thomas Schäfer > Signed-off-by: Bjørn Mork Applied and queued up for -stable, thanks!

[net PATCH] gro: Allow tunnel stacking in the case of FOU/GUE

This patch should fix the issues seen with a recent fix to prevent tunnel-in-tunnel frames from being generated with GRO. The fix itself is correct for now as long as we do not add any devices that support NETIF_F_GSO_GRE_CSUM. When such a device is added it could have the potential to mess

[PATCH net 3/4] bnxt_en: Fix typo in bnxt_hwrm_set_pause_common().

The typo caused the wrong flow control bit to be set. Reported by: Ajit Khaparde Signed-off-by: Michael Chan --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH net 2/4] bnxt_en: Implement proper firmware message padding.

The size of every padded firmware message is specified in the first HWRM_VER_GET response message. Use this value to pad every message after that. Signed-off-by: Michael Chan --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 6 +-

[PATCH net 0/4] misc. small fixes.

Misc. small fixes for net. Michael Chan (4): bnxt_en: Initialize CP doorbell value before ring allocation bnxt_en: Implement proper firmware message padding. bnxt_en: Fix typo in bnxt_hwrm_set_pause_common(). bnxt_en: Fix ethtool -a reporting. drivers/net/ethernet/broadcom/bnxt/bnxt.c

[PATCH net 4/4] bnxt_en: Fix ethtool -a reporting.

To report flow control tx/rx settings accurately regardless of autoneg setting, we should use link_info->req_flow_ctrl. Before this patch, the reported settings were only correct when autoneg was on. Signed-off-by: Michael Chan ---

[PATCH net 1/4] bnxt_en: Initialize CP doorbell value before ring allocation

From: Prashant Sreedharan The existing code does the following: allocate completion ring initialize completion ring doorbell disable interrupts on this completion ring by writing to the doorbell We can have a race where firmware sends an asynchronous event to

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

From: Eric Dumazet Date: Mon, 28 Mar 2016 13:51:46 -0700 > On Mon, 2016-03-28 at 13:46 -0700, Eric Dumazet wrote: > >> We have at least 384 bytes of padding in skb->head (this is struct >> skb_shared_info). >> >> Whatever garbage we might read, current code is fine. >>

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

From: Jan Engelhardt Date: Mon, 28 Mar 2016 22:20:39 +0200 (CEST) > > On Monday 2016-03-28 21:29, David Miller wrote: > > @@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff *skb, > > length--; > > continue; > >

Re: [PATCH] ipv6: Fix the pmtu path for connected UDP socket

On Mon, Mar 28, 2016 at 03:39:42PM -0700, Cong Wang wrote: > On Fri, Mar 25, 2016 at 5:16 PM, Martin KaFai Lau wrote: > > On Fri, Mar 25, 2016 at 04:55:27PM -0700, Martin KaFai Lau wrote: > >> void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, __be32 mtu) > >> { > >> +

Re: [PATCH net v2 2/3] tunnels: Don't apply GRO to multiple layers of encapsulation.

On Mon, Mar 28, 2016 at 3:10 PM, Tom Herbert wrote: > On Mon, Mar 28, 2016 at 1:34 PM, Alexander Duyck > wrote: >> On Mon, Mar 28, 2016 at 1:03 PM, Tom Herbert wrote: >>> On Mon, Mar 28, 2016 at 12:31 PM, Alexander Duyck >>>

Re: [PATCH] ipv6: Fix the pmtu path for connected UDP socket

On Fri, Mar 25, 2016 at 5:16 PM, Martin KaFai Lau wrote: > On Fri, Mar 25, 2016 at 04:55:27PM -0700, Martin KaFai Lau wrote: >> void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, __be32 mtu) >> { >> + struct dst_entry *odst; >> + >> + odst = sk_dst_get(sk); >> +

Re: [RFT Patch net 1/2] ipv6: invalidate the socket cached route on pmtu events if possible

On Fri, Mar 25, 2016 at 11:11 AM, Eric Dumazet wrote: > On Fri, 2016-03-25 at 10:17 -0700, Cong Wang wrote: > >> 1) sock lock protects the whole update: the whole check, update, recheck, >> set logic, to make sure another CPU will not do the same to the same socket >> at

Re: [PATCH net v2 2/3] tunnels: Don't apply GRO to multiple layers of encapsulation.

On Mon, Mar 28, 2016 at 1:34 PM, Alexander Duyck wrote: > On Mon, Mar 28, 2016 at 1:03 PM, Tom Herbert wrote: >> On Mon, Mar 28, 2016 at 12:31 PM, Alexander Duyck >> wrote: >>> On Mon, Mar 28, 2016 at 11:47 AM, Tom

Re: RESEND: Easily reproducible kernel panic due to netdev all_adj_list refcnt handling

On 03/25/2016 11:10 PM, Andrew Collins wrote: > On 03/25/2016 02:43 PM, Matthias Schiffer wrote: >> We've tried your patch, and it changes the symptoms a bit, but doesn't fix >> the panic. I've attached kernel logs of the crash both before and after >> applying the patch. >> >> One note: I did not

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

On Mon, 2016-03-28 at 23:11 +0200, Jozsef Kadlecsik wrote: > In net/netfilter/nf_conntrack_proto_tcp.c we copy the options into a > buffer with skb_header_pointer(), so it's not a false positive there and > the KASAN report referred to that part. > Although the out of bound could be one extra

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

On Mon, 28 Mar 2016, Eric Dumazet wrote: > On Mon, 2016-03-28 at 22:20 +0200, Jan Engelhardt wrote: > > On Monday 2016-03-28 21:29, David Miller wrote: > > >>> > > @@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff > > >>> > > *skb, > > >>> > > length--; > > >>> > >

Re: [RFC net-next 2/2] udp: No longer use SLAB_DESTROY_BY_RCU

On Fri, 2016-03-25 at 17:08 -0700, Tom Herbert wrote: > On Fri, Mar 25, 2016 at 3:29 PM, Eric Dumazet wrote: > > +/* Must be called under rcu_read_lock(). > > > It might be just as easy to do the rcu_read_lock() within the > function. That way we don't need to require

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

On Mon, 2016-03-28 at 13:46 -0700, Eric Dumazet wrote: > We have at least 384 bytes of padding in skb->head (this is struct > skb_shared_info). > > Whatever garbage we might read, current code is fine. > > We have to deal with a false positive here. Very similar to the one fixed in

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

On Mon, 2016-03-28 at 22:20 +0200, Jan Engelhardt wrote: > On Monday 2016-03-28 21:29, David Miller wrote: > >>> > > @@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff > >>> > > *skb, > >>> > > length--; > >>> > > continue; > >>> > > default: >

[PATCH] ethernet: mvneta: Support netpoll

This commit adds the support for netpoll, which is used to implement netconsole. Signed-off-by: Ezequiel Garcia --- Tested on Armada 370 Mirabox and Armada XP Openblocks AX3-4 with netconsole. drivers/net/ethernet/marvell/mvneta.c | 21 + 1

[PATCH net,stable] qmi_wwan: add "D-Link DWM-221 B1" device id

Thomas reports: "Windows: 00 diagnostics 01 modem 02 at-port 03 nmea 04 nic Linux: T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2001 ProdID=7e19 Rev=02.32 S: Manufacturer=Mobile Connect S:

Re: [PATCH net v2 2/3] tunnels: Don't apply GRO to multiple layers of encapsulation.

On Mon, Mar 28, 2016 at 1:03 PM, Tom Herbert wrote: > On Mon, Mar 28, 2016 at 12:31 PM, Alexander Duyck > wrote: >> On Mon, Mar 28, 2016 at 11:47 AM, Tom Herbert wrote: >>> On Mon, Mar 28, 2016 at 10:37 AM, Alexander Duyck

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

On Monday 2016-03-28 21:29, David Miller wrote: >>> > > @@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff *skb, >>> > > length--; >>> > > continue; >>> > > default: >>> > > +if (length < 2) >>> > > +return; >>> > >

Re: [RFC net-next 2/2] udp: No longer use SLAB_DESTROY_BY_RCU

On 03/28/2016 01:01 PM, Eric Dumazet wrote: Note : file structures got RCU freeing back in 2.6.14, and I do not think named users ever complained about added cost ;) Couldn't see the tree for the forest I guess :) rick

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

On Mon, 2016-03-28 at 15:29 -0400, David Miller wrote: > From: Jozsef Kadlecsik > Date: Mon, 28 Mar 2016 18:48:51 +0200 (CEST) > > >> > > @@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff *skb, > >> > > length--; > >> > >

Re: [PATCH net v2 2/3] tunnels: Don't apply GRO to multiple layers of encapsulation.

On Mon, Mar 28, 2016 at 12:31 PM, Alexander Duyck wrote: > On Mon, Mar 28, 2016 at 11:47 AM, Tom Herbert wrote: >> On Mon, Mar 28, 2016 at 10:37 AM, Alexander Duyck >> wrote: >>> On Mon, Mar 28, 2016 at 9:31 AM, Tom

Re: [RFC net-next 2/2] udp: No longer use SLAB_DESTROY_BY_RCU

On Mon, 2016-03-28 at 12:11 -0700, Rick Jones wrote: > I was under the impression that individual DNS queries were supposed to > have not only random DNS query IDs but also originate from random UDP > source ports. https://tools.ietf.org/html/rfc5452 4.5 at least touches > on the topic but I

Re: [PATCH 0/9] Netfilter fixes for net

From: Pablo Neira Ayuso Date: Mon, 28 Mar 2016 19:57:53 +0200 > The following patchset contains Netfilter fixes for you net tree, > they are: ... > This batch comes with four patches to validate x_tables blobs coming > from userspace. CONFIG_USERNS exposes the x_tables

Re: [PATCH net v2 2/3] tunnels: Don't apply GRO to multiple layers of encapsulation.

From: Jesse Gross Date: Sun, 27 Mar 2016 21:38:34 -0700 > Generally speaking, multiple levels of encapsulation offload are not > valid. That's very much not true Jesse. Please fix the regression you introduced or I will have no choice but to revert your entire set of changes.

Re: [PATCH net v2 2/3] tunnels: Don't apply GRO to multiple layers of encapsulation.

On Mon, Mar 28, 2016 at 11:47 AM, Tom Herbert wrote: > On Mon, Mar 28, 2016 at 10:37 AM, Alexander Duyck > wrote: >> On Mon, Mar 28, 2016 at 9:31 AM, Tom Herbert wrote: >>> On Sun, Mar 27, 2016 at 9:38 PM, Jesse Gross

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

From: Jozsef Kadlecsik Date: Mon, 28 Mar 2016 18:48:51 +0200 (CEST) >> > > @@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff *skb, >> > > length--; >> > > continue; >> > > default: >> > > +if (length < 2)

Re: [RFC net-next 2/2] udp: No longer use SLAB_DESTROY_BY_RCU

On 03/28/2016 11:55 AM, Eric Dumazet wrote: On Mon, 2016-03-28 at 11:44 -0700, Rick Jones wrote: On 03/28/2016 10:00 AM, Eric Dumazet wrote: If you mean that a busy DNS resolver spends _most_ of its time doing : fd = socket() bind(fd port=0) < send and receive one frame > close(fd)

Re: [RFC net-next 2/2] udp: No longer use SLAB_DESTROY_BY_RCU

On Mon, 2016-03-28 at 11:44 -0700, Rick Jones wrote: > On 03/28/2016 10:00 AM, Eric Dumazet wrote: > > On Mon, 2016-03-28 at 09:15 -0700, Rick Jones wrote: > >> On 03/25/2016 03:29 PM, Eric Dumazet wrote: > >>> UDP sockets are not short lived in the high usage case, so the added > >>> cost of

Re: [PATCH net v2 2/3] tunnels: Don't apply GRO to multiple layers of encapsulation.

On Mon, Mar 28, 2016 at 10:37 AM, Alexander Duyck wrote: > On Mon, Mar 28, 2016 at 9:31 AM, Tom Herbert wrote: >> On Sun, Mar 27, 2016 at 9:38 PM, Jesse Gross wrote: >>> On Sat, Mar 26, 2016 at 12:41 PM, Tom Herbert

Re: [RFC net-next 2/2] udp: No longer use SLAB_DESTROY_BY_RCU

On 03/28/2016 10:00 AM, Eric Dumazet wrote: On Mon, 2016-03-28 at 09:15 -0700, Rick Jones wrote: On 03/25/2016 03:29 PM, Eric Dumazet wrote: UDP sockets are not short lived in the high usage case, so the added cost of call_rcu() should not be a concern. Even a busy DNS resolver? If you

Re: [PATCH net] team: team should sync the port's uc/mc addrs when add a port

Mon, Mar 28, 2016 at 06:42:31PM CEST, lucien@gmail.com wrote: >There is an issue when we use mavtap over team: >When we replug nic links from team0, the real nics's mc list will not >include the maddr for macvtap any more. then we can't receive pkts to >macvtap device, as they are filterred by

[PATCH 3/9] openvswitch: call only into reachable nf-nat code

From: Arnd Bergmann The openvswitch code has gained support for calling into the nf-nat-ipv4/ipv6 modules, however those can be loadable modules in a configuration in which openvswitch is built-in, leading to link errors: net/built-in.o: In function `__ovs_ct_lookup':

[PATCH 4/9] netfilter: x_tables: validate e->target_offset early

From: Florian Westphal We should check that e->target_offset is sane before mark_source_chains gets called since it will fetch the target entry for loop detection. Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso ---

[PATCH 1/9] netfilter: ipset: fix race condition in ipset save, swap and delete

From: Vishwanath Pai This fix adds a new reference counter (ref_netlink) for the struct ip_set. The other reference counter (ref) can be swapped out by ip_set_swap and we need a separate counter to keep track of references for netlink events like dump. Using the same ref counter

[PATCH 0/9] Netfilter fixes for net

Hi David, The following patchset contains Netfilter fixes for you net tree, they are: 1) There was a race condition between parallel save/swap and delete, which resulted a kernel crash due to the increase ref for save, swap, wrong ref decrease operations. Reported and fixed by Vishwanath

[PATCH 7/9] netfilter: nfnetlink_queue: honor NFQA_CFG_F_FAIL_OPEN when netlink unicast fails

When netlink unicast fails to deliver the message to userspace, we should also check if the NFQA_CFG_F_FAIL_OPEN flag is set so we reinject the packet back to the stack. I think the user expects no packet drops when this flag is set due to queueing to userspace errors, no matter if related to the

[PATCH 9/9] netfilter: ipv4: fix NULL dereference

From: Liping Zhang Commit fa50d974d104 ("ipv4: Namespaceify ip_default_ttl sysctl knob") use sock_net(skb->sk) to get the net namespace, but we can't assume that sk_buff->sk is always exist, so when it is NULL, oops will happen. Signed-off-by: Liping Zhang

[PATCH 8/9] netfilter: x_tables: enforce nul-terminated table name from getsockopt GET_ENTRIES

Make sure the table names via getsockopt GET_ENTRIES is nul-terminated in ebtables and all the x_tables variants and their respective compat code. Uncovered by KASAN. Reported-by: Baozeng Ding Signed-off-by: Pablo Neira Ayuso ---

[PATCH 2/9] openvswitch: Fix checking for new expected connections.

From: Jarno Rajahalme OVS should call into CT NAT for packets of new expected connections only when the conntrack state is persisted with the 'commit' option to the OVS CT action. The test for this condition is doubly wrong, as the CT status field is ANDed with the bit number

[PATCH 6/9] netfilter: x_tables: fix unconditional helper

From: Florian Westphal Ben Hawkes says: In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it is possible for a user-supplied ipt_entry structure to have a large next_offset field. This field is not bounds checked prior to writing a counter value at the

Re: [PATCH net v2 2/3] tunnels: Don't apply GRO to multiple layers of encapsulation.

On Mon, Mar 28, 2016 at 9:31 AM, Tom Herbert wrote: > On Sun, Mar 27, 2016 at 9:38 PM, Jesse Gross wrote: >> On Sat, Mar 26, 2016 at 12:41 PM, Tom Herbert wrote: >>> On Sat, Mar 19, 2016 at 9:32 AM, Jesse Gross

Re: [PATCH] net: macb: Only call GPIO functions if there is a valid GPIO

Hello. On 03/28/2016 03:47 PM, Charles Keepax wrote: GPIOlib will print warning messages if we call GPIO functions without a valid GPIO. Change the code to avoid doing so. Signed-off-by: Charles Keepax --- drivers/net/ethernet/cadence/macb.c | 8

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

On Mon, Mar 28, 2016 at 06:48:51PM +0200, Jozsef Kadlecsik wrote: > Hi David, Pablo, > > David, do you agree with the patch for net/ipv4/tcp_input.c? If yes, how > should I proceed? Should I send the whole patch to you or is it OK to send > to Pablo? Submit a formal patch and Cc:

Re: [RFC net-next 2/2] udp: No longer use SLAB_DESTROY_BY_RCU

On Mon, 2016-03-28 at 09:15 -0700, Rick Jones wrote: > On 03/25/2016 03:29 PM, Eric Dumazet wrote: > > UDP sockets are not short lived in the high usage case, so the added > > cost of call_rcu() should not be a concern. > > Even a busy DNS resolver? If you mean that a busy DNS resolver spends

Re: [RFC net-next 2/2] udp: No longer use SLAB_DESTROY_BY_RCU

On Mon, Mar 28, 2016 at 9:15 AM, Rick Jones wrote: > On 03/25/2016 03:29 PM, Eric Dumazet wrote: >> >> UDP sockets are not short lived in the high usage case, so the added >> cost of call_rcu() should not be a concern. > > > Even a busy DNS resolver? > Should use

Re: [PATCH net] team: team should sync the port's uc/mc addrs when add a port

On Tue, Mar 29, 2016 at 12:42:31AM +0800, Xin Long wrote: > There is an issue when we use mavtap over team: > When we replug nic links from team0, the real nics's mc list will not > include the maddr for macvtap any more. then we can't receive pkts to > macvtap device, as they are filterred by mc

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

Hi David, Pablo, David, do you agree with the patch for net/ipv4/tcp_input.c? If yes, how should I proceed? Should I send the whole patch to you or is it OK to send to Pablo? Best regards, Jozsef On Mon, 28 Mar 2016, Baozeng Ding wrote: > > > On 2016/3/28 10:35, Baozeng Ding wrote: > > >

[PATCH net] team: team should sync the port's uc/mc addrs when add a port

There is an issue when we use mavtap over team: When we replug nic links from team0, the real nics's mc list will not include the maddr for macvtap any more. then we can't receive pkts to macvtap device, as they are filterred by mc list of nic. In Bonding Driver, it syncs the uc/mc addrs in

Re: [PATCH net v2 2/3] tunnels: Don't apply GRO to multiple layers of encapsulation.

On Sun, Mar 27, 2016 at 9:38 PM, Jesse Gross wrote: > On Sat, Mar 26, 2016 at 12:41 PM, Tom Herbert wrote: >> On Sat, Mar 19, 2016 at 9:32 AM, Jesse Gross wrote: >>> When drivers express support for TSO of encapsulated packets, they >>>

Re: [RFC PATCH 7/9] GSO: Support partial segmentation offload

On Sun, Mar 27, 2016 at 10:36 PM, Jesse Gross wrote: > On Fri, Mar 18, 2016 at 4:25 PM, Alexander Duyck wrote: >> diff --git a/net/core/dev.c b/net/core/dev.c >> index edb7179bc051..666cf427898b 100644 >> --- a/net/core/dev.c >> +++ b/net/core/dev.c >> @@

Re: [RFC net-next 2/2] udp: No longer use SLAB_DESTROY_BY_RCU

On 03/25/2016 03:29 PM, Eric Dumazet wrote: UDP sockets are not short lived in the high usage case, so the added cost of call_rcu() should not be a concern. Even a busy DNS resolver? rick jones

Re: [PATCH 0/3] Control ethernet PHY LEDs via LED subsystem

Hi Stephen > There already is LED control via ethtool. > It is more important that the existing API (ethtool) still work. I'm having trouble finding this. The man page for ethtool only mentions -p --identify with respect to LEDs. I also don't see anything in include/uapi/linux/ethtool.h

[PATCH] mwifiex: ie_list is an array, so no need to check if NULL

From: Colin Ian King ap_ie->ie_list is an array of struct mwifiex_ie and can never be null, so the null check on this array is redundant and can be removed. Signed-off-by: Colin Ian King --- drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 2

Re: [PATCH 0/3] Control ethernet PHY LEDs via LED subsystem

On Wed, 23 Mar 2016 18:51:37 +0100 Vishal Thanki wrote: > Hi all, > > Based on suggestions from Andrew and Florian, I have made some changes > to expose the ethernet PHY LEDs using kernel LED subsystem. The following > ALPHA patchset introduces two new LED triggers: > >

Re: [PATCH] netlabel: fix a problem with netlbl_secattr_catmap_setrng()

From: Paul Moore Date: Mon, 28 Mar 2016 11:17:28 -0400 > On Mon, Mar 28, 2016 at 11:10 AM, Paul Moore wrote: >> From: Janak Desai >> >> We try to be clever and set large chunks of the bitmap at once, when >> possible;

Re: [PATCH net-next 1/2] net: hns: fixed the setting and getting overtime bug

From: Yisen Zhuang Date: Mon, 28 Mar 2016 18:40:56 +0800 > From: Lisheng > > The overtime setting and getting REGs in HNS V2 is defferent from HNS V1. > It needs to be distinguished between them if getting or setting the REGs. > > Signed-off-by:

Re: [PATCH net-next 2/2] net: hns: set-coalesce-usecs returns errno by dsaf.ko

From: Yisen Zhuang Date: Mon, 28 Mar 2016 18:40:57 +0800 > From: Lisheng > > It may fail to set coalesce usecs to HW, and Ethtool needs to know if it > is successful to cfg the parameter or not. So it needs return the errno by > dsaf.ko. > >

Re: [PATCH] net: macb: Only call GPIO functions if there is a valid GPIO

From: Charles Keepax Date: Mon, 28 Mar 2016 13:47:42 +0100 > GPIOlib will print warning messages if we call GPIO functions without a > valid GPIO. Change the code to avoid doing so. > > Signed-off-by: Charles Keepax

Re: [PATCH] openvswitch: Use proper buffer size in nla_memcpy

From: Haishuang Yan Date: Mon, 28 Mar 2016 18:08:59 +0800 > For the input parameter count, it's better to use the size > of destination buffer size, as nla_memcpy would take into > account the length of the source netlink attribute when > a data is copied from

Re: [B.A.T.M.A.N.] [PATCH 07/14] batman-adv: use list_for_each_entry_safe

On Friday, December 18, 2015 23:33:31 Geliang Tang wrote: > Use list_for_each_entry_safe() instead of list_for_each_safe() to > simplify the code. > > Signed-off-by: Geliang Tang > --- > net/batman-adv/icmp_socket.c | 22 +- > 1 file changed, 9

Re: [B.A.T.M.A.N.] [PATCH 1/3] batman-adv: use to_delayed_work

On Monday, December 28, 2015 23:43:37 Geliang Tang wrote: > Use to_delayed_work() instead of open-coding it. > > Signed-off-by: Geliang Tang > --- > net/batman-adv/bridge_loop_avoidance.c | 2 +- > net/batman-adv/distributed-arp-table.c | 2 +- >

Re: [PATCH net] inet: add proper locking in __inet{6}_lookup()

From: Eric Dumazet Date: Mon, 28 Mar 2016 07:23:55 -0700 > On Mon, 2016-03-28 at 07:10 -0700, Eric Dumazet wrote: >> On Mon, 2016-03-28 at 06:29 -0700, Eric Dumazet wrote: >> >> > Sure, but the caller changed quite a lot in all stable versions. >> > >> > I took the

Re: [PATCH] netlabel: fix a problem with netlbl_secattr_catmap_setrng()

On Mon, Mar 28, 2016 at 11:10 AM, Paul Moore wrote: > From: Janak Desai > > We try to be clever and set large chunks of the bitmap at once, when > possible; unfortunately we weren't very clever when we wrote the code > and messed up the

[PATCH] netlabel: fix a problem with netlbl_secattr_catmap_setrng()

From: Janak Desai We try to be clever and set large chunks of the bitmap at once, when possible; unfortunately we weren't very clever when we wrote the code and messed up the if-conditional. Fix this bug and restore proper operation. Signed-off-by: Janak Desai

Re: [PATCH 25/31] ethernet: use parity8 in sun/niu.c

On Sun, Mar 27 2016, zhaoxiu zeng wrote: > From: Zeng Zhaoxiu > > Signed-off-by: Zeng Zhaoxiu No idea why I’ve been CC’d, but code looks good to me so: Acked-by: Michal Nazarewicz > --- > drivers/net/ethernet/sun/niu.c | 10

Re: [PATCH v8 net-next] ravb: Add dma queue interrupt support

Hello. 2016-03-27 22:02 GMT+09:00 Sergei Shtylyov : > Hello. > > > On 03/22/2016 06:22 PM, Yoshihiro Kaneko wrote: > >> From: Kazuya Mizuguchi >> >> This patch supports the following interrupts. >> >> - One interrupt for

Re: [PATCH net] inet: add proper locking in __inet{6}_lookup()

On Mon, 2016-03-28 at 07:10 -0700, Eric Dumazet wrote: > On Mon, 2016-03-28 at 06:29 -0700, Eric Dumazet wrote: > > > Sure, but the caller changed quite a lot in all stable versions. > > > > I took the easiest path for stable maintainers, and was planing to > > implement a better way in

Re: [PATCH net] inet: add proper locking in __inet{6}_lookup()

On Mon, 2016-03-28 at 06:29 -0700, Eric Dumazet wrote: > Sure, but the caller changed quite a lot in all stable versions. > > I took the easiest path for stable maintainers, and was planing to > implement a better way in net-next. I misread your suggestion David, I send a V2 shortly.

RE: [PATCH net-next 1/1] qlge: Update version to 1.00.00.35

> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Friday, March 25, 2016 9:12 PM > To: Manish Chopra > Cc: netdev ; Dept-GE Linux NIC Dev gelinuxnic...@qlogic.com>; Harish Patil >

Re: [PATCH net] inet: add proper locking in __inet{6}_lookup()

On Sun, 2016-03-27 at 22:32 -0400, David Miller wrote: > From: Eric Dumazet > Date: Fri, 25 Mar 2016 15:15:15 -0700 > > > From: Eric Dumazet > > > > Blocking BH in __inet{6}_lookup() is not correct, as the lookups > > are done using RCU protection.

Re: [PATCH v2] netpoll: Fix extra refcount release in netpoll_cleanup()

On Fri, Mar 25, 2016 at 03:16:36PM -0400, David Miller wrote: > From: Bjorn Helgaas > Date: Fri, 25 Mar 2016 11:46:39 -0500 > > > You're right, there is an issue here. I reproduced a problem with a > > bond device. bond_netpoll_setup() calls __netpoll_setup() directly > >

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

On 2016/3/28 10:35, Baozeng Ding wrote: On 2016/3/28 6:25, Jozsef Kadlecsik wrote: On Mon, 28 Mar 2016, Jozsef Kadlecsik wrote: On Sun, 27 Mar 2016, Baozeng Ding wrote: The following program triggers stack-out-of-bounds in tcp_packet. The kernel version is 4.5 (on Mar 16 commit

[PATCH] net: macb: Only call GPIO functions if there is a valid GPIO

GPIOlib will print warning messages if we call GPIO functions without a valid GPIO. Change the code to avoid doing so. Signed-off-by: Charles Keepax --- drivers/net/ethernet/cadence/macb.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff

  1   2   >