* Re: [PATCH net-next] pkt_sched: fq: better control of DDOS traffic
From: David Miller @ 2015-02-03 2:18 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1422626772.21689.90.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 30 Jan 2015 06:06:12 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> FQ has a fast path for skb attached to a socket, as it does not
> have to compute a flow hash. But for other packets, FQ being non
> stochastic means that hosts exposed to random Internet traffic
> can allocate million of flows structure (104 bytes each) pretty
> easily. Not only host can OOM, but lookup in RB trees can take
> too much cpu and memory resources.
>
> This patch adds a new attribute, orphan_mask, that is adding
> possibility of having a stochastic hash for orphaned skb.
>
> Its default value is 1024 slots.
>
> This patch also handles the specific case of SYNACK messages:
>
> They are attached to the listener socket, and therefore all map
> to a single hash bucket. If listener have set SO_MAX_PACING_RATE,
> hoping to have new accepted socket inherit this rate, SYNACK
> might be paced and even dropped.
>
> This is very similar to an internal patch Google have used more
> than one year.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Can you document the mask value a little bit more?
For example, I don't understand why "(1024 - 1) << 1" means 1024
slots just from looking at this change.
Thanks.
^ permalink raw reply
* Re: [PATCH net] sunvnet: set queue mapping when doing packet copies
From: David Miller @ 2015-02-03 2:21 UTC (permalink / raw)
To: david.stevens; +Cc: netdev, sowmini.varadhan, eric.dumazet
In-Reply-To: <54CBBF89.4070800@oracle.com>
From: David L Stevens <david.stevens@oracle.com>
Date: Fri, 30 Jan 2015 12:29:45 -0500
>
>
> This patch fixes a bug where vnet_skb_shape() didn't set the already-selected
> queue mapping when a packet copy was required. This results in using the
> wrong queue index for stops/starts, hung tx queues and watchdog timeouts
> under heavy load.
>
> Signed-off-by: David L Stevens <david.stevens@oracle.com>
> Acked-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
>
> --
> I'm resubmitting this in its original form. Since skb_segment() doesn't do
> TCP flow control either, due to an incorrect destructor check, and those
> issues raised by Eric are a matter of fairness, while this missing queue_mapping
> assignment results in crashes, I'd like to get this piece fixed separately.
Fair enough, applied.
Please sort out the callback issues with Eric, thanks.
^ permalink raw reply
* Re: [PATCH v2] net: bluetooth: hci_sock: Use 'const void *' instead of 'void *' for 2nd parameter of hci_test_bit()
From: Chen Gang S @ 2015-02-03 2:32 UTC (permalink / raw)
To: Joe Perches
Cc: marcel-kz+m5ild9QBg9hUCZPvPmw, gustavo-THi1TnShQwVAfugRpC6u6w,
johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w, David S. Miller,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1422912017.30476.28.camel-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
On 2/3/15 05:20, Joe Perches wrote:
> On Tue, 2015-02-03 at 05:14 +0800, Chen Gang S wrote:
>> hci_test_bit() does not modify 2nd parameter, so it is better to let it
>> be constant, or may cause build warning. The related warning (with
>> allmodconfig under xtensa):
> []
>> diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
> []
>> @@ -46,7 +46,7 @@ struct hci_pinfo {
>> unsigned short channel;
>> };
>>
>> -static inline int hci_test_bit(int nr, void *addr)
>> +static inline int hci_test_bit(int nr, const void *addr)
>> {
>> return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
>> }
>
> It's probably better to use const __u32 * here too, but the
> real thing I wonder is whether or not there's an issue with
> one of the 2 uses of this function.
>
> One of them passes a unsigned long *, the other a u32 *.
>
> $ git grep -w hci_test_bit
> net/bluetooth/hci_sock.c:static inline int hci_test_bit(int nr, void *addr)
> net/bluetooth/hci_sock.c: if (!hci_test_bit(flt_event, &flt->event_mask))
> net/bluetooth/hci_sock.c: !hci_test_bit(ocf & HCI_FLT_OCF_BITS,
> net/bluetooth/hci_sock.c- &hci_sec_filter.ocf_mask[ogf])) &&
>
> hci_sec_filter.ocf_mask is __u32
> but flt->event_mask is unsigned long.
>
> Any possible issue here on 64-bit systems?
>
For me, it can not cause issue on 64-bit systems. hci_test_bit() treats
'addr' as "__u32 *", and has to use the pointer to do something.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
^ permalink raw reply
* Re: [PATCHv2 net] net: restore lro after device detached from bridge
From: Fan Du @ 2015-02-03 2:29 UTC (permalink / raw)
To: Michal Kubecek; +Cc: Alexander Duyck, Fan Du, bhutchings, davem, netdev
In-Reply-To: <20150202111556.GA8655@unicorn.suse.cz>
于 2015年02月02日 19:15, Michal Kubecek 写道:
> On Mon, Feb 02, 2015 at 10:20:12AM +0800, Fan Du wrote:
>>
>> I think you are talking about bad scenarios when net device is
>> attached to a bridge. Then what's the good reason user has to pay
>> extra cpu power for using GRO, instead of using hw capable LRO/RSC
>> when this net device is detached from bridge acting as a standalone
>> NIC?
>
> Being bridged is only one of the situations when LRO needs to be
> disabled. Does your patch make sure it doesn't enable LRO if there are
> other reasons for it to be disabled, e.g. if forwarding is enabled for
> it or any of its upper devices?
>
> I'm afraid the only way to make the automatic reenabling work correctly
> would be to keep track if LRO was disabled manually (e.g. by ethtool) or
> only automatically because the device is bridged, forwarding is enabled
> for it, LRO is disabled for any upper device etc. And to reenable LRO
> only in the second case and even then only if none of the possible
> reasons holds. I don't think it's worth the effort.
>
>> Note, SRC is defaulted to *ON* in practice for ALL ixgbe NICs, as same
>> other RSC capable NICs.
>
> A very bad idea, IMHO. A lot of bug reports resulted from it.
Why are you saying this an idea?? this a fact for all RSC capable NIC drivers.
search drivers/net/ethernet/ to find more.
>> Attaching net device to a bridge _once_ should not changed its default
>> configuration, moreover it's a subtle change without any message that
>> user won't noticed at all.
> IMHO the key point here is that LRO enabled when it shouldn't is much
> more serious problem than LRO disabled when it could be enabled.
I agree with you here more than I disagree.
btw, I see this subtle behaviour not because I "seeing issues with routing or
bridging being enabled and" as Alexander assuming, it's because I see my testbed
82599EB supports LRO, and the driver enabled after probing from code review,
but for no reason ethtool -k reports lro is off, it looks like this interface
is bound to bridge by one of service.
>
> Michal Kubecek
>
^ permalink raw reply
* Re: [PATCH net-next v3 0/3] net-timestamp: blinding
From: David Miller @ 2015-02-03 2:47 UTC (permalink / raw)
To: richardcochran; +Cc: willemb, netdev, luto
In-Reply-To: <20150201112931.GA4323@localhost.localdomain>
From: Richard Cochran <richardcochran@gmail.com>
Date: Sun, 1 Feb 2015 12:29:31 +0100
> On Fri, Jan 30, 2015 at 01:29:30PM -0500, Willem de Bruijn wrote:
>> Two issues were raised during recent timestamping discussions:
>> 1. looping full packets on the error queue exposes packet headers
>> 2. TCP timestamping with retransmissions generates many timestamps
>
> For the series,
>
> Acked-by: Richard Cochran <richardcochran@gmail.com>
Series applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH -next] net: dctcp: loosen requirement to assert ECT(0) during 3WHS
From: David Miller @ 2015-02-03 2:49 UTC (permalink / raw)
To: fw; +Cc: netdev, daniel, glenn.judd
In-Reply-To: <1422647120-27252-1-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Fri, 30 Jan 2015 20:45:20 +0100
> One deployment requirement of DCTCP is to be able to run
> in a DC setting along with TCP traffic. As Glenn Judd's
> NSDI'15 paper "Attaining the Promise and Avoiding the Pitfalls
> of TCP in the Datacenter" [1] (tba) explains, one way to
> solve this on switch side is to split DCTCP and TCP traffic
> in two queues per switch port based on the DSCP: one queue
> soley intended for DCTCP traffic and one for non-DCTCP traffic.
>
> For the DCTCP queue, there's the marking threshold K as
> explained in commit e3118e8359bb ("net: tcp: add DCTCP congestion
> control algorithm") for RED marking ECT(0) packets with CE.
> For the non-DCTCP queue, there's f.e. a classic tail drop queue.
> As already explained in e3118e8359bb, running DCTCP at scale
> when not marking SYN/SYN-ACK packets with ECT(0) has severe
> consequences as for non-ECT(0) packets, traversing the RED
> marking DCTCP queue will result in a severe reduction of
> connection probability.
>
> This is due to the DCTCP queue being dominated by ECT(0) traffic
> and switches handle non-ECT traffic in the RED marking queue
> after passing K as drops, where K is usually a low watermark
> in order to leave enough tailroom for bursts. Splitting DCTCP
> traffic among several queues (ECN and non-ECN queue) is being
> considered a terrible idea in the network community as it
> splits single flows across multiple network paths.
>
> Therefore, commit e3118e8359bb implements this on Linux as
> ECT(0) marked traffic, as we argue that marking all packets
> of a DCTCP flow is the only viable solution and also doesn't
> speak against the draft.
>
> However, recently, a DCTCP implementation for FreeBSD hit also
> their mainline kernel [2]. In order to let them play well
> together with Linux' DCTCP, we would need to loosen the
> requirement that ECT(0) has to be asserted during the 3WHS as
> not implemented in FreeBSD. This simplifies the ECN test and
> lets DCTCP work together with FreeBSD.
>
> Joint work with Daniel Borkmann.
>
> [1] https://www.usenix.org/conference/nsdi15/technical-sessions/presentation/judd
> [2] https://github.com/freebsd/freebsd/commit/8ad879445281027858a7fa706d13e458095b595f
>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Applied.
^ permalink raw reply
* Re: [PATCH] Documentation: Update netlink_mmap.txt
From: David Miller @ 2015-02-03 2:50 UTC (permalink / raw)
To: richard; +Cc: corbet, shemming, linux-doc, netdev, linux-kernel
In-Reply-To: <1422647444-4004-1-git-send-email-richard@nod.at>
From: Richard Weinberger <richard@nod.at>
Date: Fri, 30 Jan 2015 20:50:44 +0100
> Update netlink_mmap.txt wrt. commit 4682a0358639b29cf
> ("netlink: Always copy on mmap TX.").
>
> Signed-off-by: Richard Weinberger <richard@nod.at>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: hip04: add missing MODULE_LICENSE
From: David Miller @ 2015-02-03 2:51 UTC (permalink / raw)
To: arnd; +Cc: netdev, zhangfei.gao, dingtianhong
In-Reply-To: <4018099.9I7f6kd5jC@wuerfel>
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 30 Jan 2015 22:57:01 +0100
> The hip04 ethernet driver causes a new compile-time warning
> when built as a loadable module:
>
> WARNING: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/hisilicon/hip04_eth.o
> see include/linux/module.h for more information
>
> This adds the license as "GPL", which matches the header of the file.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH] net/tulip: don't warn about unknown ARM architecture
From: David Miller @ 2015-02-03 2:54 UTC (permalink / raw)
To: arnd; +Cc: netdev, linux-arm-kernel, linux-kernel, grundler
In-Reply-To: <1780413.LLpv9s01CB@wuerfel>
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 30 Jan 2015 22:58:19 +0100
> ARM has 32-byte cache lines, which according to the comment in
> the init registers function seems to work best with the default
> value of 0x4800 that is also used on sparc and parisc.
>
> This adds ARM to the same list, to use that default but no
> longer warn about it.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4 : Improve IEEE DCBx support, other minor open-lldp fixes
From: David Miller @ 2015-02-03 2:55 UTC (permalink / raw)
To: anish; +Cc: netdev, hariprasad
In-Reply-To: <1422667217-2610-1-git-send-email-anish@chelsio.com>
From: Anish Bhatt <anish@chelsio.com>
Date: Fri, 30 Jan 2015 17:20:17 -0800
> * Add support for IEEE ets & pfc api.
> * Fix bug that resulted in incorrect bandwidth percentage being returned for
> CEE peers
> * Convert pfc enabled info from firmware format to what dcbnl expects before
> returning
>
> Signed-off-by: Anish Bhatt <anish@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] net: bluetooth: hci_sock: Use 'const void *' instead of 'void *' for 2nd parameter of hci_test_bit()
From: Chen Gang S @ 2015-02-03 2:59 UTC (permalink / raw)
To: Joe Perches
Cc: marcel, gustavo, johan.hedberg, David S. Miller, linux-bluetooth,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <54D0332B.6050701@sunrus.com.cn>
On 2/3/15 10:32, Chen Gang S wrote:
> On 2/3/15 05:20, Joe Perches wrote:
>> On Tue, 2015-02-03 at 05:14 +0800, Chen Gang S wrote:
>>> hci_test_bit() does not modify 2nd parameter, so it is better to let it
>>> be constant, or may cause build warning. The related warning (with
>>> allmodconfig under xtensa):
>> []
>>> diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
>> []
>>> @@ -46,7 +46,7 @@ struct hci_pinfo {
>>> unsigned short channel;
>>> };
>>>
>>> -static inline int hci_test_bit(int nr, void *addr)
>>> +static inline int hci_test_bit(int nr, const void *addr)
>>> {
>>> return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
>>> }
>>
>> It's probably better to use const __u32 * here too, but the
>> real thing I wonder is whether or not there's an issue with
>> one of the 2 uses of this function.
>>
>> One of them passes a unsigned long *, the other a u32 *.
>>
>> $ git grep -w hci_test_bit
>> net/bluetooth/hci_sock.c:static inline int hci_test_bit(int nr, void *addr)
>> net/bluetooth/hci_sock.c: if (!hci_test_bit(flt_event, &flt->event_mask))
>> net/bluetooth/hci_sock.c: !hci_test_bit(ocf & HCI_FLT_OCF_BITS,
>> net/bluetooth/hci_sock.c- &hci_sec_filter.ocf_mask[ogf])) &&
>>
>> hci_sec_filter.ocf_mask is __u32
>> but flt->event_mask is unsigned long.
>>
>> Any possible issue here on 64-bit systems?
>>
>
> For me, it can not cause issue on 64-bit systems. hci_test_bit() treats
> 'addr' as "__u32 *", and has to use the pointer to do something.
>
'event_mask' is intended to type cast to "__u32 *" within 'hci_sock.c'.
So for me, "const __u32 *" is better than "const void *" for 2nd
parameter of hci_test_bit().
If what I said above is correct, and also if necessary, I shall patch v3
for it.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
^ permalink raw reply
* Re: [PATCH net-next v4] Add support of Cavium Liquidio ethernet adapters
From: David Miller @ 2015-02-03 3:00 UTC (permalink / raw)
To: rvatsavayi
Cc: netdev, derek.chickles, satananda.burla, felix.manlunas,
raghu.vatsavayi
In-Reply-To: <1422671378-1300-1-git-send-email-rvatsavayi@caviumnetworks.com>
From: Raghu Vatsavayi <rvatsavayi@caviumnetworks.com>
Date: Fri, 30 Jan 2015 18:29:38 -0800
> create mode 100644 drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
...
> create mode 100644 drivers/net/ethernet/cavium/liquidio/cn68xx_device.c
These two file have several functions which are nearly identical.
Especially the device init register programming sequence.
Please consolidate the common code some more.
THanks.
^ permalink raw reply
* Re: [PATCH 0/2] rhashtable: Add walk iterator primitives and use them in netlink
From: David Miller @ 2015-02-03 3:19 UTC (permalink / raw)
To: herbert; +Cc: tgraf, ying.xue, kaber, paulmck, netdev, netfilter-devel
In-Reply-To: <20150131031356.GA26781@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 31 Jan 2015 14:13:56 +1100
> On Thu, Jan 29, 2015 at 02:42:46PM -0800, David Miller wrote:
>>
>> I'm holding off on this series for now.
>>
>> Let me know if you want me to do something different.
>
> No problems. Here is a new version of these two patches which
> hopefully should work on netfilter as well.
>
> Note that the major functional difference compared to the previous
> one is that resizes are now handled properly and will cause the
> iterator to restart from scratch.
>
> However, as with all existing hash table walker implementations,
> if you remove an element from the chain that we're walking over
> while we're waiting for user-space to give us a new buffer, then
> the walk may miss elements that are still on that chain.
Series applied to net-next.
^ permalink raw reply
* Re: netfilter: Use rhashtable walk iterator
From: David Miller @ 2015-02-03 3:19 UTC (permalink / raw)
To: herbert; +Cc: tgraf, ying.xue, kaber, paulmck, netdev, netfilter-devel
In-Reply-To: <20150131043151.GA27524@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 31 Jan 2015 15:31:51 +1100
> On Sat, Jan 31, 2015 at 02:13:56PM +1100, Herbert Xu wrote:
>>
>> No problems. Here is a new version of these two patches which
>> hopefully should work on netfilter as well.
>
> And here is the patch for netfilter.
>
> -- >8 --
> This patch gets rid of the manual rhashtable walk in nft_hash
> which touches rhashtable internals that should not be exposed.
> It does so by using the rhashtable iterator primitives.
>
> Note that I'm leaving nft_hash_destroy alone since it's only
> invoked on shutdown and it shouldn't be affected by changes
> to rhashtable internals (or at least not what I'm planning to
> change).
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied to net-next.
^ permalink raw reply
* Re: rhashtable: Fix potential crash on destroy in rhashtable_shrink
From: David Miller @ 2015-02-03 3:19 UTC (permalink / raw)
To: herbert; +Cc: tgraf, netdev
In-Reply-To: <20150131093637.GA29106@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 31 Jan 2015 20:36:38 +1100
> The current being_destroyed check in rhashtable_expand is not
> enough since if we start a shrinking process after freeing all
> elements in the table that's also going to crash.
>
> This patch adds a being_destroyed check to the deferred worker
> thread so that we bail out as soon as we take the lock.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied to net-next
^ permalink raw reply
* Re: rhashtable: Move hash_rnd into bucket_table
From: David Miller @ 2015-02-03 3:19 UTC (permalink / raw)
To: herbert; +Cc: tgraf, netdev
In-Reply-To: <20150131102150.GA29498@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sat, 31 Jan 2015 21:21:50 +1100
> Currently hash_rnd is a parameter that users can set. However,
> no existing users set this parameter. It is also something that
> people are unlikely to want to set directly since it's just a
> random number.
>
> In preparation for allowing the reseeding/rehashing of rhashtable,
> this patch moves hash_rnd into bucket_table so that it's now an
> internal state rather than a parameter.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Also applied to net-next, thanks a lot.
^ permalink raw reply
* Re: Question: should local address be expired when updating PMTU?
From: shengyong @ 2015-02-03 3:21 UTC (permalink / raw)
To: Calvin Owens, Alex Gartrell
Cc: davem, netdev, yangyingling, steffen.klassert, hannes, lvs-devel,
kernel-team
In-Reply-To: <20150203021007.GA1866582@mail.thefacebook.com>
在 2015/2/3 10:10, Calvin Owens 写道:
> On Monday 02/02 at 16:52 -0800, Alex Gartrell wrote:
>> Hello Shengyong,
>>
>>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>>> index b2614b2..b80317a 100644
>>> --- a/net/ipv6/route.c
>>> +++ b/net/ipv6/route.c
>>> @@ -1136,6 +1136,9 @@ static void ip6_rt_update_pmtu(struct
>> dst_entry *dst, struct sock *sk,
>>> {
>>> struct rt6_info *rt6 = (struct rt6_info*)dst;
>>>
>>> + if (rt6->rt6i_flags & RTF_LOCAL)
>>> + return;
>>> +
>>> dst_confirm(dst);
>>> if (mtu < dst_mtu(dst) && rt6->rt6i_dst.plen == 128) {
>>> struct net *net = dev_net(dst->dev);
>>>
>>> So is this modification correct? Or how can we avoid such expiring?
>>
>> FWIW, we encountered this problem with IPVS tunneling. Here's a
>> patch done by Calvin (cc'ed) that fixes my attempted fix for this.
>> We're not particularly proud of this...
>>
>> At a high level, I don't think the RTF_LOCAL check was sufficient,
>> but I didn't investigate deeply enough and hopefully Calvin can say
>> why.
>
> I honestly didn't spend much time at all finding the underlying cause
> because it appeared to be fixed upstream: on 3.19-rc5 you get all 3
> expected routes after the last step of my repro below.
Hi,
I do my test on 3.19.0-rc7 just now, it seems it still doesn't solve the
local-addr-expired problem.
I just really
> needed to get this working at the time, and the gross disgusting
> horrible ugly awful [more negative adjectives] patch included below made
> it work.
>
> FWIW, the explanation I wrote down in my notes was:
>
> "The absence of RTF_NONEXTHOP is causing COWs to happen, which are
> always marked as RTF_CACHE. Somehow that's screwing things up in
> rt6_do_redirect()"
>
> That could be BS though, I don't at all remember how I came to that
> conclusion.
>
> (/me resolves to write better notes in the future...)
>
> Here's how to get the weird behavior on 3.10 (+stable):
>
> $ sudo ip addr add local 4444::1 dev lo
> ### Now I have 2 routes in /proc/net/ipv6_route, a local and a non-local
> ### Both have the RTF_NONEXTHOP flag set (0x00200000)
> $ sudo ip route add local 4444::1 dev lo
> ### Now I have 3 routes in /proc/net/ipv6_route to 4444::1
> ### Notice the new route does NOT have the RTF_NONEXTHOP flag set
> $ sudo ip addr del local 4444::1 dev lo
> ### Now I just have the one route I created before
> $ sudo ip addr add local 4444::1 dev lo
> ### And now I have 3 routes again
> $ sudo ping6 4444::1
> [blah blah blah successful ping]
> $ sudo ip addr del local 4444::1 dev lo
> $ sudo ip addr add local 4444::1 dev lo
> ### Still have 3 routes
> $ sudo ip addr del local 4444::1 dev lo
> ### Now I just have my one route yet again
> ### Now, *without the address on lo*, talk to it (it works), then re-add it
> $ ping6 4444::1
> [blah blah blah successful ping]
> $ sudo ip addr add local 4444::1 dev lo
> ### Now I only have 2 routes... WAT!?
> ### Notice the LOCAL (0x80000000) route doesn't have the RTF_NONEXTHOP flag set
Looks like we meet different problems. Here is how I do my test (as well as on 3.10
+stable):
Host only
PC <------------> Virtual Machine
create and send a packet using scapy:
-----------------------------------
| IPv6 (src=PC-addr, dst=VM-addr) |
|---------------------------------|
| ICMPv6 (Packet Too Big) |
|---------------------------------|
| IPv6 (src=VM-addr, dst=VM-addr) |
|---------------------------------|
| ICMPv6 (Neighbor Advertisement) |
-----------------------------------
Then the local-addr is set to expire. After expired, the VM is unreachable from
PC side.
thanks,
Sheng
>
> Thanks,
> Calvin
>
>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>> index f14d49b..c607a42 100644
>> --- a/net/ipv6/route.c
>> +++ b/net/ipv6/route.c
>> @@ -1159,18 +1159,18 @@ static void ip6_rt_update_pmtu(struct
>> dst_entry *dst, struct sock *sk,
>> }
>> dst_metric_set(dst, RTAX_MTU, mtu);
>>
>> - /* FACEBOOK HACK: We need to not expire local non-expiring
>> - * routes so that we don't accidentally start blackholing
>> - * ipvs traffic when we happen to use it locally for
>> - * healthchecking (see ip_vs_xmit.c --
>> - * __ip_vs_get_out_rt_v6 invokes update_pmtu if the rt is
>> - * associated with a socket)
>> - * Alex Gartrell <agartrell@fb.com>
>> + /*
>> + * FACEBOOK HACK: Only expire routes that aren't destined for
>> + * the loopback interface.
>> + *
>> + * This prevents the strange route coalescing that happens when
>> + * you add an address to the loopback that had a route that had
>> + * been used when the address didn't exist from getting expired
>> + * and causing packet loss in shiv.
>> */
>> - if (!(rt6->rt6i_flags & RTF_LOCAL) ||
>> - (rt6->rt6i_flags & (RTF_EXPIRES | RTF_CACHE)))
>> - rt6_update_expires(
>> - rt6, net->ipv6.sysctl.ip6_rt_mtu_expires);
>> + if (!(dst->dev->flags & IFF_LOOPBACK))
>> + rt6_update_expires(rt6,
>> + net->ipv6.sysctl.ip6_rt_mtu_expires);
>> }
>> }
>>
>>
>> Cheers,
>> --
>> Alex Gartrell <agartrell@fb.com>
>
> .
>
^ permalink raw reply
* Re: [PATCH net-next 3/4] ethtool: add RX_ALLOC_ORDER to tunable
From: David Miller @ 2015-02-03 3:21 UTC (permalink / raw)
To: _govind; +Cc: netdev, ssujith, benve, edumazet, ben
In-Reply-To: <1422707290-939-4-git-send-email-_govind@gmx.com>
From: Govindarajulu Varadarajan <_govind@gmx.com>
Date: Sat, 31 Jan 2015 17:58:09 +0530
> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
This is terrible.
You haven't explained what this means.
And to tell you the truth, from what I can tell this tunable is
very specific to how you have implemented RX frags in the enic
driver in this series and won't necessarily translate to how
other drivers manage RX buffers.
You need to actually design this facility properly, understand
what the needs are of other drivers and how this facility
can be relevant for more drivers than your own.
^ permalink raw reply
* Re: rhashtable: Move hash_rnd into bucket_table
From: David Miller @ 2015-02-03 3:26 UTC (permalink / raw)
To: herbert; +Cc: tgraf, netdev
In-Reply-To: <20150202.191956.404010205495035337.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 02 Feb 2015 19:19:56 -0800 (PST)
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Sat, 31 Jan 2015 21:21:50 +1100
>
>> Currently hash_rnd is a parameter that users can set. However,
>> no existing users set this parameter. It is also something that
>> people are unlikely to want to set directly since it's just a
>> random number.
>>
>> In preparation for allowing the reseeding/rehashing of rhashtable,
>> this patch moves hash_rnd into bucket_table so that it's now an
>> internal state rather than a parameter.
>>
>> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> Also applied to net-next, thanks a lot.
Actually this and the netfilter change break the build.
I'm reverting all of these rhashtable changes, please fix this stuff
up.
Firstly, the hash_rnd change results in this:
lib/rhashtable.c: In function ‘obj_raw_hashfn’:
lib/rhashtable.c:84:9: warning: passing argument 1 of ‘lockdep_rht_mutex_is_held’ discards ‘const’ qualifier from pointer target type [enabled by default]
lib/rhashtable.c:57:5: note: expected ‘struct rhashtable *’ but argument is of type ‘const struct rhashtable *’
Next, the netfilter change results in:
ERROR: "rhashtable_walk_start" [net/netfilter/nft_hash.ko] undefined!
^ permalink raw reply
* Re: [PATCH net-next 0/6] ipv6: Add lockless UDP send path
From: David Miller @ 2015-02-03 3:28 UTC (permalink / raw)
To: vyasevich; +Cc: netdev, herbert, hannes, vyasevic
In-Reply-To: <1422718818-21093-1-git-send-email-vyasevic@redhat.com>
From: Vladislav Yasevich <vyasevich@gmail.com>
Date: Sat, 31 Jan 2015 10:40:12 -0500
> This series introduces a lockless UDPv6 send path similar to
> what Herbert Xu did for IPv4 a while ago.
>
> There are some difference from IPv4. IPv6 caching for flow
> label is a bit different, as well as it requires another cork
> cork structure that holds the IPv6 ancillary data.
>
> Please take a look.
This looks good to me, applied, thanks Vlad.
^ permalink raw reply
* Re: [PATCH] net: sctp: Deletion of an unnecessary check before the function call "kfree"
From: David Miller @ 2015-02-03 3:30 UTC (permalink / raw)
To: elfring
Cc: nhorman, vyasevich, linux-sctp, netdev, linux-kernel,
kernel-janitors, julia.lawall
In-Reply-To: <54CD0DCF.9020804@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 31 Jan 2015 18:15:59 +0100
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 31 Jan 2015 18:10:03 +0100
>
> The kfree() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH 0/4] Netfilter/IPVS fixes for net
From: David Miller @ 2015-02-03 3:31 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1422737711-5169-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Sat, 31 Jan 2015 21:55:07 +0100
> The following patchset contains Netfilter/IPVS fixes for your net tree,
> they are:
>
> 1) Validate hooks for nf_tables NAT expressions, otherwise users can
> crash the kernel when using them from the wrong hook. We already
> got one user trapped on this when configuring masquerading.
>
> 2) Fix a BUG splat in nf_tables with CONFIG_DEBUG_PREEMPT=y. Reported
> by Andreas Schultz.
>
> 3) Avoid unnecessary reroute of traffic in the local input path
> in IPVS that triggers a crash in in xfrm. Reported by Florian
> Wiessner and fixes by Julian Anastasov.
>
> 4) Fix memory and module refcount leak from the error path of
> nf_tables_newchain().
Pulled, thanks Pablo.
^ permalink raw reply
* Re: [PATCH net-next] pkt_sched: fq: better control of DDOS traffic
From: Eric Dumazet @ 2015-02-03 3:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20150202.181834.2201965486446161539.davem@davemloft.net>
On Mon, 2015-02-02 at 18:18 -0800, David Miller wrote:
> Can you document the mask value a little bit more?
>
> For example, I don't understand why "(1024 - 1) << 1" means 1024
> slots just from looking at this change.
>
Sure , will do.
Thats because we reserve low order bit of the sk/hash value,
to make sure the stochastic hash is only applied on non locally
generated traffic.
Thanks
^ permalink raw reply
* Re: [PATCH net] net/mlx4_core: Fix kernel Oops (mem corruption) when working with more than 80 VFs
From: David Miller @ 2015-02-03 3:38 UTC (permalink / raw)
To: amirv; +Cc: netdev, ogerlitz, yevgenyp, jackm
In-Reply-To: <1422883122-29020-1-git-send-email-amirv@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Mon, 2 Feb 2015 15:18:42 +0200
> From: Jack Morgenstein <jackm@dev.mellanox.co.il>
>
> Commit de966c592802 (net/mlx4_core: Support more than 64 VFs) was meant to
> allow up to 126 VFs. However, due to leaving MLX4_MFUNC_MAX too low, using
> more than 80 VFs resulted in memory corruptions (and Oopses) when more than
> 80 VFs were requested. In addition, the number of slaves was left too high.
>
> This commit fixes these issues.
>
> Fixes: de966c592802 ("net/mlx4_core: Support more than 64 VFs")
> Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCHv1 net] xen-netback: stop the guest rx thread after a fatal error
From: David Miller @ 2015-02-03 3:39 UTC (permalink / raw)
To: david.vrabel; +Cc: netdev, xen-devel, ian.campbell, wei.liu2
In-Reply-To: <1422896271-26551-1-git-send-email-david.vrabel@citrix.com>
From: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 2 Feb 2015 16:57:51 +0000
> After commit e9d8b2c2968499c1f96563e6522c56958d5a1d0d (xen-netback:
> disable rogue vif in kthread context), a fatal (protocol) error would
> leave the guest Rx thread spinning, wasting CPU time. Commit
> ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e (xen-netback: reintroduce
> guest Rx stall detection) made this even worse by removing a
> cond_resched() from this path.
>
> Since a fatal error is non-recoverable, just allow the guest Rx thread
> to exit. This requires taking additional refs to the task so the
> thread exiting early is handled safely.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Reported-by: Julien Grall <julien.grall@linaro.org>
> Tested-by: Julien Grall <julien.grall@linaro.org>
Applied, thank you.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox