[PATCH] TIPC: Fix infinite loop in netlink handler

From: Florian Westphal [EMAIL PROTECTED] The tipc netlink config handler uses the nlmsg_pid from the request header as destination for its reply. If the application initialized nlmsg_pid to 0, the reply is looped back to the kernel, causing hangup. Fix: use nlmsg_pid of the skb that triggered

Re: [PATCH] TIPC: Fix infinite loop in netlink handler

Stephens, Allan [EMAIL PROTECTED] wrote: [removed tipc-discussion list from CC] Patrick McHardy wrote: Florian Westphal wrote: - genlmsg_unicast(rep_buf, req_nlh-nlmsg_pid); + genlmsg_unicast(rep_buf, NETLINK_CB(skb).pid); This is the second time we're seeing

[PATCH][Resend] TIPC: Fix infinite loop in netlink handler

From: Florian Westphal [EMAIL PROTECTED] The tipc netlink config handler uses the nlmsg_pid from the request header as destination for its reply. If the application initialized nlmsg_pid to 0, the reply is looped back to the kernel, causing hangup. Fix: use nlmsg_pid of the skb that triggered

[patch] net/tipc: sprintf/strcpy conversion

From: Florian Westphal [EMAIL PROTECTED] convert sprintf(a,b) to strcpy(a,b). Make tipc_bclink_name[] const. Signed-off-by: Florian Westphal [EMAIL PROTECTED] --- compile tested; diffed against davem/net-2.6. --- a/net/tipc/bcast.c +++ b/net/tipc/bcast.c @@ -119,7 +119,7 @@ static struct

[patch] net/tipc: kmalloc/kzalloc conversion

From: Florian Westphal [EMAIL PROTECTED] convert kmalloc/memset to kzalloc. Signed-off-by: Florian Westphal [EMAIL PROTECTED] --- compile tested only. index 1bb7570..730c5c4 100644 --- a/net/tipc/bcast.c +++ b/net/tipc/bcast.c @@ -774,8 +774,8 @@ int tipc_bclink_set_queue_limits(u32 lim

[PATCH] TIPC: fix tipc_link_create error handling

if printbuf allocation or tipc_node_attach_link() fails, invalid references to the link are left in the associated node and bearer structures. Fix by doing printbuf allocation early and adding the new link to b_ptr-links after tipc_node_attach_link() succeeded. Signed-off-by: Florian Westphal

[PATCH] TIPC: fix tipc_link_create error handling

() succeeded. Signed-off-by: Florian Westphal [EMAIL PROTECTED] --- link.c | 28 +++- 1 file changed, 15 insertions(+), 13 deletions(-) also move k_init_timer(), as suggested by Allan. diff --git a/net/tipc/link.c b/net/tipc/link.c index 5adfdfd..1d674e0 100644 --- a/net/tipc

[PATCH] TIPC: make function tipc_nameseq_subscribe static

make needlessly global function tipc_nameseq_subscribe static. Signed-off-by: Florian Westphal [EMAIL PROTECTED] --- diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c index d8473ee..ac7dfdd 100644 --- a/net/tipc/name_table.c +++ b/net/tipc/name_table.c @@ -501,7 +501,7 @@ end_node

[PATCH] TIPC: fix two minor sparse warnings

fix two warnings generated by sparse: link.c:2386 symbol 'msgcount' shadows an earlier one node.c:244 symbol 'addr_string' shadows an earlier one Signed-off-by: Florian Westphal [EMAIL PROTECTED] --- net/tipc/link.c |2 +- net/tipc/node.c |2 -- 2 files changed, 1 insertions(+), 3

[PATCH] DM9000: fix interface hang under load

-by: Florian Westphal [EMAIL PROTECTED] --- Actually the comments ('Disable all interrupts, iow(db, DM9000_IMR, IMR_PAR) etc) give the impression that the interrupt handler cannot run during dm9000_start_xmit(), however this isn't correct (perhaps the chipset has some weird timing issues

[PATCH] [TIPC]: Supress minor sparse warnings.

imbalance in 'sock_unlock' - unexpected unlock CC: Allan Stephens [EMAIL PROTECTED] CC: Jon Paul Maloy [EMAIL PROTECTED] Signed-off-by: Florian Westphal [EMAIL PROTECTED] --- net/tipc/cluster.c |2 +- net/tipc/link.c|2 +- net/tipc/ref.c |2 +- net/tipc/socket.c |2 ++ net

[PATCH] [TIPC]: declare proto_ops structures as 'const'.

CC: Allan Stephens [EMAIL PROTECTED] CC: Jon Paul Maloy [EMAIL PROTECTED] Signed-off-by: Florian Westphal [EMAIL PROTECTED] --- net/tipc/socket.c | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/net/tipc/socket.c b/net/tipc/socket.c index 24ddfd2..2290903

Re: [RFC 2/3] tc: deprecate TC_ACT_QUEUED

Jamal Hadi Salim j...@mojatatu.com wrote: 2) the ACT_QUEUED vs STOLEN was supposed to have semantics of something that was stolen (eg redirection should definetely have been returning STOLEN not QUEUED); something that queues for later re-injection (with any/all metadata) was intended to use

[PATCH] net: sched: act_connmark: don't zap skb-nfct

This action is meant to be passive, i.e. we should not alter skb-nfct: If nfct is present just leave it alone. Compile tested only. Cc: Jamal Hadi Salim j...@mojatatu.com Signed-off-by: Florian Westphal f...@strlen.de --- shouldn't matter much in practice since this would be used in the ingress

Re: [PATCH net-next 1/7] net: Add skb_get_hash_perturb

Tom Herbert t...@herbertland.com wrote: This is used to get the skb-hash and then perturb it for a local use. Signed-off-by: Tom Herbert t...@herbertland.com --- include/linux/skbuff.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/include/linux/skbuff.h

Re: [PATCH -next] net: sched: remove TC_MUNGED bits

Jamal Hadi Salim j...@mojatatu.com wrote: On 04/30/15 17:16, Alexei Starovoitov wrote: On Thu, Apr 30, 2015 at 12:12:00PM +0200, Florian Westphal wrote: Not used. pedit sets TC_MUNGED when packet content was altered, but all the core does is unset MUNGED again and then set OK2MUNGE

[PATCH V2 -next 0/5] don't exceed original maximum fragment size when refragmenting

Hello, We would like to propose this patchset again. Only minor details changed since the last version, we incorporated the suggestion from Jesse to always store the size of the largest fragment received, regardless of the DF bit. Thus we never generate bigger fragments as originally received

Re: [PATCH -next] net: sched: use counter to break reclassify loops

Jamal Hadi Salim j...@mojatatu.com wrote: On 05/12/15 09:00, Florian Westphal wrote: Jamal Hadi Salim j...@mojatatu.com wrote: Florian, In general i am in support of removing this - since the use case never materialized as being useful. However, this is not the same logic

Re: [PATCH -next 2/3] net: sched: remove AT INGRESS/EGRESS

Alexei Starovoitov alexei.starovoi...@gmail.com wrote: diff --git a/net/core/dev.c b/net/core/dev.c index 0e7afef..802b9b9 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -3071,9 +3071,6 @@ static int __dev_queue_xmit(struct sk_buff *skb, void *accel_priv) txq =

[PATCH -next] net: sched: pkt_cls: remove unused macros from uapi

alexei.starovoi...@gmail.com Signed-off-by: Florian Westphal f...@strlen.de --- iproute2 still compiles with the exported pkt_cls.h header. diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h index 39fb53d..4f0d1bc 100644 --- a/include/uapi/linux/pkt_cls.h +++ b/include/uapi

[PATCH -next] ipv6: reject locally assigned nexthop addresses

will pick eth0 as outdev due to the prefix route that is added before DAD work is started. Add explicit test that checks if nexthop gateway is a local address. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1167969 Signed-off-by: Florian Westphal f...@strlen.de --- diff --git a/net/ipv6/route.c b/net

[PATCH nf-next] net: ip_fragment: remove BRIDGE_NETFILTER mtu special handling

. Signed-off-by: Florian Westphal f...@strlen.de --- include/linux/netfilter_bridge.h | 7 --- net/bridge/br_netfilter.c| 7 +++ net/ipv4/ip_output.c | 4 3 files changed, 7 insertions(+), 11 deletions(-) diff --git a/include/linux/netfilter_bridge.h b/include/linux

Re: linux-next: build warnings after merge of the net-next tree

Stephen Rothwell s...@canb.auug.org.au wrote: After merging the net-next tree, today's linux-next build (i386 defconfig) produced these warnings: In file included from include/net/netfilter/nf_conntrack_tuple.h:13:0, from include/linux/netfilter/nf_conntrack_dccp.h:28,

[PATCH -next] net: ipv4: un-inline ip_finish_output2

textdata bss dec hex filename old: 16527 44 0 1657140bb net/ipv4/ip_output.o new: 14935 44 0 149793a83 net/ipv4/ip_output.o Suggested-by: Eric Dumazet eric.duma...@gmail.com Signed-off-by: Florian Westphal f...@strlen.de --- diff --git a/net

Re: [PATCH net-next] x_table: align per cpu xt_counter

. Sorry, I was away. Looks great. Acked-by: Florian Westphal f...@strlen.de -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net/bridge: Add missing in6_dev_put in br_validate_ipv6

Julien Grall julien.gr...@citrix.com wrote: The commit efb6de9b4ba0092b2c55f6a52d16294a8a698edd netfilter: bridge: forward IPv6 fragmented packets introduced a new function br_validate_ipv6 which take a reference on the inet6 device. Although, the reference is not released at the end. This

Re: [PATCH] net/bridge: Add missing in6_dev_put in br_validate_ipv6

Julien Grall julien.gr...@citrix.com wrote: On 03/07/15 21:42, Florian Westphal wrote: I think it makes more sense to use __in6_dev_get() instead which doesn't take a reference. __in6_dev_get requires to hold rcu_read_lock or RTNL. My knowledge on this code is very limited. Are we sure

Re: Unable to unregister netdevice after netfilter: bridge: forward IPv6 fragmented packets

Julien Grall julien.gr...@citrix.com wrote: Hi, I tried to run the latest Linux tree (4a10a91756ef381bced7b88cfb9232f660b92d93) as DOM0 Xen. After destroying a guest using network, I got the following lines in the DOM0 kernel log: unregister_netdevice: waiting for vif1.0 to become free.

[PATCH v3 -next] ip: reject too-big defragmented DF-skb when forwarding

...@stressinduktion.org Signed-off-by: Florian Westphal f...@strlen.de --- No changes since v2; I moved the patch out of set defrag set since its independent. net/ipv4/ip_forward.c | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/net/ipv4/ip_forward.c b/net

[PATCH v3 -next] ipv6: don't increase size when refragmenting forwarded ipv6 skbs

sure ip6_fragment always caps MTU at largest packet size seen when defragmented skb is forwarded. Acked-by: Hannes Frederic Sowa han...@stressinduktion.org Signed-off-by: Florian Westphal f...@strlen.de --- changes since v2: update commit message: no problem unless skb frag list is munged

[PATCH -next, V3 0/2] net: force refragmentation for DF reassembed skbs

output path tests: if (skb-len mtu) ip_fragment() This breaks connectivity in one corner case: If the skb was reassembled, but has the DF bit set and .. .. its reassembled size is = outdev mtu .. .. we will forward a DF packet larger than what the sender transmitted on wire. If a

[PATCH -next 2/2] ip_fragment: don't forward defragmented DF packet

bit on each fragment in this case. Joint work with Hannes Frederic Sowa. Reported-by: Jesse Gross je...@nicira.com Signed-off-by: Florian Westphal f...@strlen.de --- include/net/inet_frag.h | 2 +- include/net/ip.h| 1 + net/ipv4/ip_fragment.c | 31 ++- net

[PATCH -next 1/2] net: ipv4: avoid repeated calls to ip_skb_dst_mtu helper

ip_skb_dst_mtu is small inline helper, but its called in several places. before: 17061 44 0 1710542d1 net/ipv4/ip_output.o after: 16805 44 0 1684941d1 net/ipv4/ip_output.o Signed-off-by: Florian Westphal f...@strlen.de --- net/ipv4/ip_output.c | 19

Re: [PATCH -next, V3 0/2] net: force refragmentation for DF reassembed skbs

David Miller da...@davemloft.net wrote: [ cc'd Maxime Bizon ] From: Florian Westphal f...@strlen.de Date: Fri, 22 May 2015 16:32:49 +0200 IP (ttl 64, id 12345, offset 0, flags [+, DF], proto UDP (17), length 1204) 192.168.7.1.42 10.23.42.2.42: UDP, length 1400 IP (ttl 64, id 12345

Re: [PATCH -next, V3 0/2] net: force refragmentation for DF reassembed skbs

Maxime Bizon mbi...@freebox.fr wrote: On Fri, 2015-05-22 at 21:26 +0200, Florian Westphal wrote: But it does happen, see e.g. following bug report: http://marc.info/?l=linux-netdevm=139870308431986w=2 Maxime, do you recall what type of traffic generates the DF-fragments you reported

Re: [PATCH] net: Updates to netif_index_is_vrf

David Ahern d...@cumulusnetworks.com wrote: As Eric noted netif_index_is_vrf is not called with rcu_read_lock held, so use dev_get_by_index instead of dev_get_by_index_rcu. If VRF is not enabled or oif is 0 skip the device lookup. Signed-off-by: David Ahern d...@cumulusnetworks.com Why

Re: [PATCH] rhashtable-test: extend to test concurrency

Phil Sutter p...@nwl.cc wrote: After having tested insertion, lookup, table walk and removal, spawn a number of threads running operations on the same rhashtable. Each of them will: [..] + if (down_interruptible(startup_sem)) + pr_err( thread[%d]: down_interruptible

Re: [net-next PATCH 1/3] net: make default tx_queue_len configurable

Phil Sutter p...@nwl.cc wrote: Signed-off-by: Phil Sutter p...@nwl.cc --- net/Kconfig| 12 net/ethernet/eth.c | 2 +- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/net/Kconfig b/net/Kconfig index 7021c1b..21c164f 100644 --- a/net/Kconfig +++

Re: [net-next PATCH 2/3] net: sched: set tx_queue_len to default when changing noqueue device's qdisc

Phil Sutter p...@nwl.cc wrote: Virtual interfaces don't necessarily need a qdisc attached to them. This is signalled by setting dev-tx_queue_len to zero upon initialisation. The problems begin when a user still adds a qdisc, as then the special value is used as a regular one causing massive

Re: [PATCH net-next 8/9] openvswitch: Allow matching on conntrack label

Joe Stringer joestrin...@nicira.com wrote: Allow matching and setting the conntrack label field. As with ct_mark, this is populated by executing the ct() action, and is a writable field. The set_field() action may be used to modify the label, which will take effect on the most recent conntrack

Re: [PATCH RFC net-next] net: Assert napi_gro_cb size against skb-cb[]

Florian Fainelli f.faine...@gmail.com wrote: On 64-bits hosts, napi_gro_cb is 48 bytes, which is exactly the size of skb-cb[], while on 32-bits hosts it is 36 bytes, but if it were to grow, we would not be catching a size inflation as we should. --- net/core/dev.c | 2 ++ 1 file changed, 2

Re: [PATCHv2 net-next 4/9] netfilter: connlabels: Export setting connlabel length

Joe Stringer joestrin...@nicira.com wrote: Add functions to change connlabel length into nf_conntrack_labels.c so they may be reused by other modules like OVS and nftables without needing to jump through xt_match_check() hoops. Looks good, thanks Joe. Acked-by: Florian Westphal f...@strlen.de

[PATCH net] ipv6: don't reject link-local nexthop on other interface

. Joint work with Hannes Frederic Sowa. Fixes: 48ed7b26faa7 (ipv6: reject locally assigned nexthop addresses) Signed-off-by: Hannes Frederic Sowa han...@stressinduktion.org Signed-off-by: Florian Westphal f...@strlen.de --- net/ipv6/route.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions

Re: reproducable panic eviction work queue

Frank Schreuder fschreu...@transip.nl wrote: [ inet frag evictor crash ] We believe we found the bug. This patch should fix it. We cannot share list for buckets and evictor, the flag member is subject to race conditions so flags INET_FRAG_EVICTED test is not reliable. It would be great if

Re: reproducable panic eviction work queue

Nikolay Aleksandrov niko...@cumulusnetworks.com wrote: On 07/22/2015 10:17 AM, Frank Schreuder wrote: I got some additional information from syslog: Jul 22 09:49:33 dommy0 kernel: [ 675.987890] NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [kworker/3:1:42] Jul 22 09:49:42

[PATCH net 4/4] inet: frags: remove INET_FRAG_EVICTED and use list_evictor for the test

: 1. The evictor added the entry to its evictor list while the timer was waiting for the chainlock or 2. The timer unchained the entry and the evictor won't see it In both cases we should be able to see list_evictor correctly due to the sync on the chainlock. Joint work with Florian Westphal

[PATCH net 0/4] inet: ip defrag bug fixes

occured within half an hour in their setup). Florian Westphal (3): inet: frag: don't re-use chainlist for evictor inet: frag: change *_frag_mem_limit functions to take netns_frags as argument inet: frag: don't wait for timer deletion when evicting Nikolay Aleksandrov (1

[PATCH net 3/4] inet: frag: don't wait for timer deletion when evicting

the frag memory accounting to wait for outstanding timers, so that when we free the percpu counter we can be sure no running timer will trip over it. Reported-and-tested-by: Frank Schreuder fschreu...@transip.nl Signed-off-by: Florian Westphal f...@strlen.de --- net/ipv4/inet_fragment.c | 29

[PATCH net 2/4] inet: frag: change *_frag_mem_limit functions to take netns_frags as argument

Followup patch will call it after inet_frag_queue was freed, so q-net doesn't work anymore (but netf = q-net; free(q); mem_limit(netf) would). Tested-by: Frank Schreuder fschreu...@transip.nl Signed-off-by: Florian Westphal f...@strlen.de --- include/net/inet_frag.h | 8

[PATCH net 1/4] inet: frag: don't re-use chainlist for evictor

Schuijt jo...@transip.nl Tested-by: Frank Schreuder fschreu...@transip.nl Signed-off-by: Nikolay Alexandrov niko...@cumulusnetworks.com Signed-off-by: Florian Westphal f...@strlen.de --- include/net/inet_frag.h | 2 ++ net/ipv4/inet_fragment.c | 8 +++- 2 files changed, 5 insertions(+), 5

[PATCH -next] net: fib: use fib result when zero-length prefix aliases exist

is used. Reported-by: Hagen Paul Pfeifer ha...@jauu.net Cc: Alexander Duyck alexander.h.du...@redhat.com Signed-off-by: Florian Westphal f...@strlen.de --- net/ipv4/fib_semantics.c | 71 1 file changed, 36 insertions(+), 35 deletions(-) diff --git a/net

Re: mmap()ed AF_NETLINK: lockdep and sleep-in-atomic warnings

Thomas Graf tg...@suug.ch wrote: On 07/13/15 at 10:11pm, Cong Wang wrote: Caused by: commit 21e4902aea80ef35afc00ee8d2abdea4f519b7f7 Author: Thomas Graf tg...@suug.ch Date: Fri Jan 2 23:00:22 2015 +0100 netlink: Lockless lookup with RCU grace period in socket release

Re: [PATCH] brouted packet identified as PACKET_OTHERHOST blocked by higher protocol

Yigal Reiss (yreiss) yre...@cisco.com wrote: The problem I'm trying to solve is that when packets being sent from one bridged interface to the other are brouted they get dropped by the IP layer. The reason is that the packet being raised has pkt_type of type PACKET_OTHERHOST. No, thats not

Re: [PATCH] brouted packet identified as PACKET_OTHERHOST blocked by higher protocol

Yigal Reiss (yreiss) yre...@cisco.com wrote: Florian Westphal [mailto:f...@strlen.de] wrote: Maybe, but if you broute everything you might as well just remove the bridge... I want to be selective. My setup is a home router. So I can have ebtables rules for which traffic to (b)route

Re: [PATCH] brouted packet identified as PACKET_OTHERHOST blocked by higher protocol

Yigal Reiss (yreiss) yre...@cisco.com wrote: No, thats not the problem you're trying to solve. If you want to move OTHERHOST skbs, don't (b)route them? Whats the real issue that you're trying to solve? I want to (b)route them because I want to be able to inspect the packets in

[PATCH v2 -next] net: fib: use fib result when zero-length prefix aliases exist

is used. Reported-by: Hagen Paul Pfeifer ha...@jauu.net Cc: Alexander Duyck alexander.h.du...@redhat.com Signed-off-by: Florian Westphal f...@strlen.de --- Changes since v1: Address comments from Alex Duyck: - use if (fib_nud_is_unreach( .. rather than temporary boolean retval - rename last_

Re: [PATCH v2 -next] net: fib: use fib result when zero-length prefix aliases exist

Julian Anastasov j...@ssi.bg wrote: [ Dave, please toss my patch, its either v3 or something else entirely ] In fact, TOS should be matched just like in fib_table_lookup but it is not. This changes fib_select_default to not change the FIB chosen result EXCEPT if this nexthop

Re: [PATCH v2 -next] net: fib: use fib result when zero-length prefix aliases exist

Julian Anastasov j...@ssi.bg wrote: ip neigh add $IP dev $DEV nud none ip neigh list nud none It is present and not used yet. Even ip route get can not trigger neigh resolving, state will remain same. Only traffic can trigger resolving. Right. round-robin only among reachables?

Re: [PATCH v2 -next] net: fib: use fib result when zero-length prefix aliases exist

Julian Anastasov j...@ssi.bg wrote: On Mon, 20 Jul 2015, Florian Westphal wrote: The VM has two interfaces, eth0, 192.168.7.10 eth1, 192.168.8.10 ip route del default ip route add tos 0x0 via 192.168.7.1 ip route add tos 0x10 via 192.168.8.2 7.1 is reachable via eth0 (7.10/24

Re: reproducable panic eviction work queue

Frank Schreuder fschreu...@transip.nl wrote: On 7/18/2015 05:32 PM, Nikolay Aleksandrov wrote: On 07/18/2015 05:28 PM, Johan Schuijt wrote: Thx for your looking into this! Thank you for the report, I will try to reproduce this locally Could you please post the full crash log ? Of

[PATCH net] netlink: don't hold mutex in rcu callback when releasing mmapd ring

-by: Thomas Graf tg...@suug.ch Signed-off-by: Florian Westphal f...@strlen.de --- net/netlink/af_netlink.c | 79 1 file changed, 47 insertions(+), 32 deletions(-) diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c index 9a0ae71..d8e2e39

Re: iproute2: Behavioural Bug?

Akshat Kakkar akshat.1...@gmail.com wrote: [ CC Cong ] When I am trying to delete a single tc filter (i.e. specifying its handle), it is deleting all the filters with the same priority/preference. i.e. it is ignoring the handle specified. But, When I am doing similar activity in hashtable

Re: [RFC PATCH 5/5] openvswitch: Interface with NAT.

Thomas Graf <tg...@suug.ch> wrote: > On 10/21/15 at 11:34am, Florian Westphal wrote: > > Jarno Rajahalme <jrajaha...@nicira.com> wrote: > > > #define OVS_CS_F_REPLY_DIR 0x08 /* Flow is in the reply > > > direction. */ > > > #define OV

Re: [PATCH nf-next 0/4] netfilter: rework netfilter ipv6 defrag

Pablo Neira Ayuso wrote: > > I can then wait for that change to pop up in nf-next and just resend > > this series (which will then undo that change). > > I'd rather get things fixes for the existing code. This would also > allow simple passing back to -stable, then we can

Re: [PATCHv2 net 1/3] openvswitch: Fix double-free on ip_defrag() errors

Joe Stringer wrote: > err: > + if (err) > + kfree_skb(skb); > skb_push(skb, nh_ofs); That looks... wrong :-} -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo

Re: linux 3.4.43 : kernel crash at __nf_conntrack_confirm

Ani Sinha wrote: > >> > commit c6825c0976fa7893692e0e43b09740b419b23c09 > >> > Author: Andrey Vagin > >> > Date: Wed Jan 29 19:34:14 2014 +0100 > >> > netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get > >> > > >> > and a followup patch : >

Re: kernel BUG in ipmr_queue_xmit()

Eric Dumazet wrote: > > Signed-off-by: Ani Sinha > > --- > > net/ipv4/ipmr.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c > > index 866ee89..48df3cc 100644 > > --- a/net/ipv4/ipmr.c > > +++

Re: kernel BUG in ipmr_queue_xmit()

Hannes Frederic Sowa wrote: > > > > @@ -936,7 +936,9 @@ static void ipmr_cache_resolve(struct net *net, > > > > struct mr_table *mrt, > > > > > > > > rtnl_unicast(skb, net, NETLINK_CB(skb).portid); > > > > } else { > > > > +

Re: [netfilter-core] [PATCH] net: netfilter: fix GCC uninitialized warning

Pablo Neira Ayuso wrote: > On Fri, Nov 06, 2015 at 09:48:14PM +0300, Dmitry Safonov wrote: > > With x86_64_defconfig: > > GCC thinks that in nfulnl_recv_config flags parameter is not inited but > > it was under the same condition (nfula[NFULA_CFG_FLAGS] == true). > > Suppress

Re: linux 3.4.43 : kernel crash at __nf_conntrack_confirm

Ani Sinha wrote: > Indeed. So it seems to me that we have run into one another such case. > In patch c6825c0976fa7893692, I see we have added an additional check (along > with comparing tuple and zone) to verify that if the conntrack is confirmed. > > + return

Re: [PATCH] allow dctcp alpha to drop to zero

enting by 1 > as it would when alpha=16. However, it requires one less conditional to > implement since it doesn't have to guard against subtracting 1 from 0U. A > decay of 15 is not unreasonable since an equal or greater amount occurs at > alpha >= 240. > > Signed-off-by:

Re: linux 3.4.43 : kernel crash at __nf_conntrack_confirm

Ani Sinha <a...@arista.com> wrote: > On Sun, Oct 18, 2015 at 2:40 PM, Florian Westphal <f...@strlen.de> wrote: > > Ani Sinha <a...@arista.com> wrote: > >> Indeed. So it seems to me that we have run into one another such case. > >> In patch c6825c097

Re: [PATCH nf-next 0/4] netfilter: rework netfilter ipv6 defrag

Joe Stringer <joestrin...@nicira.com> wrote: > On 17 October 2015 at 13:14, Florian Westphal <f...@strlen.de> wrote: > > [ CC netdev since patch #2 isn't nf-specific. Dave, if you want > > I can resubmit that one after the next nf-pull request; let me kno

Re: [PATCH nf-next 4/4] netfilter: ipv6: avoid nf_iterate recursion

Joe Stringer <joestrin...@nicira.com> wrote: > On 17 October 2015 at 13:14, Florian Westphal <f...@strlen.de> wrote: > > @@ -606,19 +599,22 @@ struct sk_buff *nf_ct_frag6_gather(struct net *net, > > struct sk_buff *skb, u32 use > >

Re: [PATCH nf-next 3/4] netfilter: ipv6: in-place replacement of last skb

Joe Stringer wrote: > This hunk looks very similar to the logic in ip_frag_reasm(). Did you > consider refactoring to share it? Could be done but I did not plan to do that. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to

Re: [PATCH nf-next 0/4] netfilter: rework netfilter ipv6 defrag

Joe Stringer wrote: > > Good point. No, I don't. Any suggestions? > > I can try to just re-target -nf tree (sans patch #2). Pablo? > > The smallest change seems to be adding the nf_ct_frag6_consume_orig() > call to OVS, plus the morph logic from patch 3. Alternatively

Re: [RFC PATCH 5/5] openvswitch: Interface with NAT.

Jarno Rajahalme wrote: > Extend OVS conntrack interface to cover NAT. New nested > OVS_CT_ATTR_NAT may be used to include NAT with a CT action. A bare > OVS_CT_ATTR_NAT only mangles existing connections. If > OVS_NAT_ATTR_SRC or OVS_NAT_ATTR_DST is included within the

Re: linux 3.4.43 : kernel crash at __nf_conntrack_confirm

Ani Sinha wrote: > Coming back to this crash, I see something interesting in the > conntrack code in linux 3.4.109 (a supported kernel version). I see > that the hash table manipulations are protected by a spinlock. Also > lookups/reads are protected by RCU. However allocation

[PATCH nf-next 3/4] netfilter: ipv6: in-place replacement of last skb

callers to process skb as intended by openvswitch: we either return NULL (skb queued for reassembly), or turn the provided skb into a reassembled one. A followup patch will change nf_defrag to avoid the NF_HOOK recursion which is now no longer needed. Signed-off-by: Florian Westphal <f...@strlen

[PATCH nf-next 1/4] netfilter: ipv6: remove extra clone/free operations

the newly assemled skb. Cc: Jiri Pirko <j...@resnulli.us> Signed-off-by: Florian Westphal <f...@strlen.de> --- include/net/netfilter/ipv6/nf_defrag_ipv6.h | 1 - net/ipv6/netfilter/nf_conntrack_reasm.c | 71 - net/ipv6/netfilter/nf_defrag_ipv6_hoo

[PATCH nf-next 4/4] netfilter: ipv6: avoid nf_iterate recursion

return NF_ACCEPT to move on to the next hook except for -EINPROGRESS (which means skb has been queued for reassembly), in which case we return NF_STOLEN. Signed-off-by: Florian Westphal <f...@strlen.de> --- include/net/netfilter/ipv6/nf_defrag_ipv6.h | 2 +- net/ipv6/net

[PATCH nf-next 0/4] netfilter: rework netfilter ipv6 defrag

[ CC netdev since patch #2 isn't nf-specific. Dave, if you want I can resubmit that one after the next nf-pull request; let me know if you would prefer that ]. Openvswitch seems broken wrt. to defragmentation, it doesn't call nf_ct_frag6_consume_orig to free the original fragments.

[PATCH nf-next 2/4] inet: kill obsolete skb_free op

The only user was removed in preceeding commit. Signed-off-by: Florian Westphal <f...@strlen.de> --- include/net/inet_frag.h | 1 - net/ieee802154/6lowpan/reassembly.c | 1 - net/ipv4/inet_fragment.c| 10 +- net/ipv4/ip_fragment.c | 1 - ne

[PATCH -next] Revert ipv4: use skb coalescing in defragmentation

we're sure the skb is not forwarded. But discussion during NFWS resulted in 'lets just remove this for now'. Cc: Eric Dumazet eduma...@google.com Signed-off-by: Florian Westphal f...@strlen.de --- diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c index a50dc6d..4d3fffa 100644 --- a/net/ipv4

[PATCH -next crap] net: icmp: work around bogus pmtu errors

[647.106708] icmp: 192.0.0.2 reports mtu 1474 for packet size 1466 to host 204.236.132.12 [663.084586] icmp: 192.0.0.2 reports mtu 1474 for packet size 1466 to host 54.219.255.254 sigh. Signed-off-by: Florian Westphal f...@strlen.de --- Might be caused by DS-LITE. I either need the turd below

[PATCH -next] ipv6: use flag instead of u16 for hop in inet6_skb_parm

Hop was always either 0 or sizeof(struct ipv6hdr). Signed-off-by: Florian Westphal f...@strlen.de --- include/linux/ipv6.h | 2 +- net/ipv6/af_inet6.c | 4 ++-- net/ipv6/datagram.c | 8 net/ipv6/exthdrs.c | 2 +- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/include

Re: [PATCH -next] net: tcp: move to timewait when receiving data post active-close

Eric Dumazet wrote: > On Wed, 2015-11-18 at 16:54 +0100, Hannes Frederic Sowa wrote: > > > Still, the RST packet can be dropped along the way. So the teardown of > > the socket on the other side might not happen. > > This is why it is better to send RST for every

Re: [PATCH -next] net: tcp: move to timewait when receiving data post active-close

Eric Dumazet <eric.duma...@gmail.com> wrote: > On Wed, 2015-11-18 at 16:03 +0100, Florian Westphal wrote: > > RFC 1122, 4.2.2.13: > > [..] if new data is received after CLOSE is called, its TCP > > SHOULD send a RST to show that data was lost. > > > >

[PATCH -next 2/3] net: fib6: reduce identation in ip6_convert_metrics

From: Daniel Borkmann dan...@iogearbox.net Reduce the identation a bit, there's no need to artificically have it increased. Signed-off-by: Daniel Borkmann dan...@iogearbox.net --- net/ipv6/route.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff

[PATCH -next 3/3] tcp: use dctcp if enabled on the route to the initiator

flag in RTAX_FEATURES. In other words, when ECT(0) is set on the SYN packet, set ecn_ok=1 iff route RTAX_FEATURES contains RTAX_FEATURE_ECN_CA. This allows to only do a single metric feature lookup inside tcp_ecn_create_request(). Joint work with Florian Westphal. Signed-off-by: Daniel Borkmann

[PATCH -next 1/3] net: fib: move metrics parsing to a helper

fib_create_info() is already quite large, so before adding more code to the metrics section move that to a helper, similar to ip6_convert_metrics. Suggested-by: Daniel Borkmann dan...@iogearbox.net Signed-off-by: Florian Westphal f...@strlen.de --- net/ipv4/fib_semantics.c | 71

Re: WARNING at net/ipv4/netfilter/ip_tables.c:530

Cong Wang cw...@twopensource.com wrote: Your commit 98d1bd802cdbc8f56868fae51edec13e86b59515 (netfilter: xtables: compute exact size needed for jumpstack) introduced the following kernel warning during boot. It looks like the if check inside mark_source_chains() isn't correct, this causes

Re: [PATCH net-next] Revert "net/ipv6: add sysctl option accept_ra_min_hop_limit"

David Miller wrote: > From: Sabrina Dubroca > Date: Wed, 2 Sep 2015 11:43:01 +0200 > > > This reverts commit 8013d1d7eafb0589ca766db6b74026f76b7f5cb4. > > > > There are several issues with this patch. > > It completely cancels the security changes

Re: [PATCH v2] net: Fix behaviour of unreachable, blackhole and prohibit routes

Nikola Forró wrote: > Man page of ip-route(8) says following about route types: > > unreachable - these destinations are unreachable. Packets are dis‐ > carded and the ICMP message host unreachable is generated. The local > senders get an EHOSTUNREACH error. > >

Re: Netfilter: BUG: unable to handle kernel paging request, RIP: physdev_mt+0xd6/0x160

Sander Eikelenboom wrote: > Using a linux-4.3-rc1 kernel i encountered the splat below: Thanks for reporting this bug. > [ 290.200642] BUG: unable to handle kernel paging request at > 0484195d > [ 290.211702] IP: [] physdev_mt+0xd6/0x160 [..] > [ 290.444088]

Re: Netfilter: BUG: unable to handle kernel paging request, RIP: physdev_mt+0xd6/0x160

Sander Eikelenboom <li...@eikelenboom.it> wrote: > On 2015-09-13 20:06, Florian Westphal wrote: > >Sander Eikelenboom <li...@eikelenboom.it> wrote: > >>Using a linux-4.3-rc1 kernel i encountered the splat below: > > > >Thanks for reporting this bug. &g

Re: [PATCH v4] add stealth mode

Matteo Croce wrote: > Add option to disable any reply not related to a listening socket, > like RST/ACK for TCP and ICMP Port-Unreachable for UDP. > Also disables ICMP replies to echo request and timestamp. > The stealth mode can be enabled selectively for a single interface.

Re: IPv6 routing/fragmentation panic

David Woodhouse wrote: > I can repeatably crash my router with 'ping6 -s 2000' to an external > machine: > [ 61.741618] skbuff: skb_under_panic: text:c1277f1e len:1294 put:14 > head:dec98000 data:dec97ffc tail:0xdec9850a end:0xdec98f40 dev:br-lan > [ 61.754128]

Re: IPv6 routing/fragmentation panic

David Woodhouse <dw...@infradead.org> wrote: > On Wed, 2015-09-16 at 01:48 +0200, Florian Westphal wrote: > > > > What I don't understand is why you see this with fragmented ipv6 > > packets only (and not with all ipv6 forwarded skbs). > > > &g

[PATCH net] ipv6: ip6_fragment: fix headroom tests and skb leak

are allocated, fastpath is taken (14 byte ethernet header was pulled, so 16 byte headroom available in all fragments). Reported-by: David Woodhouse <dw...@infradead.org> Diagnosed-by: David Woodhouse <dw...@infradead.org> Signed-off-by: Florian Westphal <f...@strlen.de> --- net/ipv6

  1   2   3   4   5   6   7   8   9   >