* Re: [PATCH net V2 2/2] macvtap: limit head length of skb allocated
From: David Miller @ 2013-11-14 21:06 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, mst, stefanha, gregory.v.rose
In-Reply-To: <1384322440-29038-2-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Wed, 13 Nov 2013 14:00:40 +0800
> We currently use hdr_len as a hint of head length which is advertised by
> guest. But when guest advertise a very big value, it can lead to an 64K+
> allocating of kmalloc() which has a very high possibility of failure when host
> memory is fragmented or under heavy stress. The huge hdr_len also reduce the
> effect of zerocopy or even disable if a gso skb is linearized in guest.
>
> To solves those issues, this patch introduces an upper limit (PAGE_SIZE) of the
> head, which guarantees an order 0 allocation each time.
>
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH 1/2] random32: add __init prefix to prandom_start_seed_timer
From: David Miller @ 2013-11-14 21:06 UTC (permalink / raw)
To: dborkman; +Cc: netdev, hannes
In-Reply-To: <1384296342-3348-1-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Tue, 12 Nov 2013 23:45:41 +0100
> We only call that in functions annotated with __init, so add __init
> prefix in prandom_start_seed_timer() as well, so that the kernel can
> make use of this hint and we can possibly free up resources after it's
> usage. And since it's an internal function rename it to
> __prandom_start_seed_timer().
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] random32: use msecs_to_jiffies for reseed timer
From: David Miller @ 2013-11-14 21:07 UTC (permalink / raw)
To: dborkman; +Cc: netdev, hannes
In-Reply-To: <1384296342-3348-2-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Tue, 12 Nov 2013 23:45:42 +0100
> Use msecs_to_jiffies, for these calculations as different HZ
> considerations are taken into account for conversion of the timer
> shot, and also it makes the code more readable.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied.
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Vlad Yasevich @ 2013-11-14 21:13 UTC (permalink / raw)
To: Veaceslav Falico, Stefan Priebe - Profihost AG
Cc: vyasevic, Linux Netdev List
In-Reply-To: <20131114122928.GV19702@redhat.com>
On 11/14/2013 07:29 AM, Veaceslav Falico wrote:
> On Thu, Nov 14, 2013 at 08:47:28AM +0100, Stefan Priebe - Profihost AG
> wrote:
>> Hi,
>>
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>> \ ---- tap114i1
>>
>> thos one works fine now.
>>
>>
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 \ vmbr1.3000
>>> \ ---- tap114i1
>>
>> this one does not. Another note to this one. It also never worked on
>> RHEL6 - it started working with about 2.6.39 and stopped with 3.9 or
>> 3.10. But it was the only one where gvrp on vlans had worked.
>
> bridge device in this config is neither master nor slave, if I read it
> correctly.
Bridge doesn't propagate rx_flags to lower-level devices. It
automatically set all lower devices to promisc mode.
So, in the second case above, eth2 and eth3 have to be in promisc, but
nothing else does. I am not sure I understand Stefans notation though
wrt to how vmbr1.3000 and tap114i1 are configured. Stefan, can you
elaborate?
Thanks
-vlad
>
> You might want to try my patch to see if it works (my previous email).
>
>>
>> Greets,
>> Stefan
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net 0/3] bridge: Fix undesirable behavior related to vlan
From: David Miller @ 2013-11-14 21:17 UTC (permalink / raw)
To: makita.toshiaki; +Cc: stephen, vyasevic, netdev
In-Reply-To: <1384331175-4136-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Date: Wed, 13 Nov 2013 17:26:11 +0900
> There seem to be some problems around vlan code.
>
> - Unexpectedly filter vlan by NIC.
> - Not correctly decrement refcount of vlan_vid_info.
> - Memory leak when deleting a bridge with vlan_info allocated.
>
> This is a patch series to fix these issues.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: ethernet: ti/cpsw: do not crash on single-MAC machines during resume
From: David Miller @ 2013-11-14 21:21 UTC (permalink / raw)
To: zonque; +Cc: netdev, mugunthanvnm
In-Reply-To: <1384347180-3490-1-git-send-email-zonque@gmail.com>
From: Daniel Mack <zonque@gmail.com>
Date: Wed, 13 Nov 2013 13:53:00 +0100
> To prevent Oopses, cpsw_suspend() should only soft-reset sliver 1
> on dual MAC enabled machines.
>
> Signed-off-by: Daniel Mack <zonque@gmail.com>
Please reimplement this using for_each_slave() as Mungunthan suggested.
Thanks.
^ permalink raw reply
* Re: [PATCH] connector: improved unaligned access error fix
From: Chris Metcalf @ 2013-11-14 21:22 UTC (permalink / raw)
To: Pete Zaitcev
Cc: Evgeniy Polyakov, Erik Jacobson, Andrew Morton, Matt Helsley,
netdev, linux-kernel
In-Reply-To: <20131114124549.7b5f3a7b@lembas.zaitcev.lan>
On 11/14/2013 2:45 PM, Pete Zaitcev wrote:
> On Thu, 14 Nov 2013 12:09:21 -0500
> Chris Metcalf <cmetcalf@tilera.com> wrote:
>
>> - __u8 buffer[CN_PROC_MSG_SIZE];
>> + __u8 buffer[CN_PROC_MSG_SIZE] __aligned(8);
>> - msg = (struct cn_msg *)buffer;
>> + msg = buffer_to_cn_msg(buffer);
>> ev = (struct proc_event *)msg->data;
>> memset(&ev->event_data, 0, sizeof(ev->event_data));
> Why is memset(buffer,0,CN_PROC_MSG_SIZE) not acceptable?
That would be fine from a correctness point of view; I'm happy
either way. My patch nominally has better performance, for
what that's worth, since the memset() call is for a smaller
range (24 bytes instead of 60). It also avoids the need for
put_unaligned(), which even on platforms that allow unaligned
stores can still be slower.
I can certainly do a v2 with the larger memset() instead if
that's the consensus.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: [PATCH] net-tcp: fix panic in tcp_fastopen_cache_set()
From: Eric Dumazet @ 2013-11-14 21:22 UTC (permalink / raw)
To: Johannes Berg; +Cc: Dave Jones, David Miller, netdev, Yuchung Cheng
In-Reply-To: <1384462403.13941.41.camel@jlt4.sipsolutions.net>
On Thu, 2013-11-14 at 21:53 +0100, Johannes Berg wrote:
> Heh. I have no idea, it just seemed a little odd on first look given
> that __sk_dst_get() *can* actually use RCU protection. :)
Yep, the deal is that if you own socket lock, you do not need
rcu_read_lock()
Look for dst_negative_advice() as another example :
We call __sk_dst_get(sk) without rcu_read_lock() protection.
^ permalink raw reply
* Re: [PATCH net 0/6] net_tstamp: Validate hwtstamp_config completely before applying it
From: David Miller @ 2013-11-14 21:23 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, richardcochran
In-Reply-To: <1384389542.29151.5.camel@bwh-desktop.uk.level5networks.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 14 Nov 2013 00:39:02 +0000
> This series fixes very similar bugs in 6 implementations of
> SIOCSHWTSTAMP.
Series applied, thanks Ben.
^ permalink raw reply
* Re: [PATCH v2] tcp: tsq: restore minimal amount of queueing
From: David Miller @ 2013-11-14 21:26 UTC (permalink / raw)
To: eric.dumazet; +Cc: arno, sujith, xiyou.wangcong, netdev, nbd
In-Reply-To: <1384353174.28458.110.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 13 Nov 2013 06:32:54 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> After commit c9eeec26e32e ("tcp: TSQ can use a dynamic limit"), several
> users reported throughput regressions, notably on mvneta and wifi
> adapters.
>
> 802.11 AMPDU requires a fair amount of queueing to be effective.
>
> This patch partially reverts the change done in tcp_write_xmit()
> so that the minimal amount is sysctl_tcp_limit_output_bytes.
>
> It also remove the use of this sysctl while building skb stored
> in write queue, as TSO autosizing does the right thing anyway.
>
> Users with well behaving NICS and correct qdisc (like sch_fq),
> can then lower the default sysctl_tcp_limit_output_bytes value from
> 128KB to 8KB.
>
> This new usage of sysctl_tcp_limit_output_bytes permits each driver
> authors to check how their driver performs when/if the value is set
> to a minimum of 4KB.
>
> Normally, line rate for a single TCP flow should be possible,
> but some drivers rely on timers to perform TX completion and
> too long TX completion delays prevent reaching full throughput.
>
> Fixes: c9eeec26e32e ("tcp: TSQ can use a dynamic limit")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Sujith Manoharan <sujith@msujith.org>
> Reported-by: Arnaud Ebalard <arno@natisbad.org>
> Tested-by: Sujith Manoharan <sujith@msujith.org>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH net] bonding: fix two race conditions in bond_store_updelay/downdelay
From: David Miller @ 2013-11-14 21:29 UTC (permalink / raw)
To: nikolay; +Cc: netdev, fubar, andy, vfalico
In-Reply-To: <1384358866-15157-1-git-send-email-nikolay@redhat.com>
From: Nikolay Aleksandrov <nikolay@redhat.com>
Date: Wed, 13 Nov 2013 17:07:46 +0100
> This patch fixes two race conditions between bond_store_updelay/downdelay
> and bond_store_miimon which could lead to division by zero as miimon can
> be set to 0 while either updelay/downdelay are being set and thus miss the
> zero check in the beginning, the zero div happens because updelay/downdelay
> are stored as new_value / bond->params.miimon. Use rtnl to synchronize with
> miimon setting.
>
> CC: Jay Vosburgh <fubar@us.ibm.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> CC: Veaceslav Falico <vfalico@redhat.com>
> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] net: phylib: add adjust_state callback to phy device
From: David Miller @ 2013-11-14 21:32 UTC (permalink / raw)
To: zonque; +Cc: netdev, marek.belisko, ujhelyi.m
In-Reply-To: <1384376870-7810-1-git-send-email-zonque@gmail.com>
From: Daniel Mack <zonque@gmail.com>
Date: Wed, 13 Nov 2013 22:07:49 +0100
> Allow phy drivers to take action when the core does its link adjustment.
> No change for drivers that do not implement this callback.
>
> Signed-off-by: Daniel Mack <zonque@gmail.com>
So you're using this to reset the entire PHY via the reset bit in the
BMCR register when the link goes down.
But this is going to break things.
If the phy library previously programmed a non-autonegotiated static
link configuration into the BMCR register, your reset is going to
undo that.
Now the configuration phylib thinks the chip has and the one it
acutally does is out of sync.
I'm not applying these patches, sorry.
^ permalink raw reply
* Re: [PATCH] net-tcp: fix panic in tcp_fastopen_cache_set()
From: David Miller @ 2013-11-14 21:33 UTC (permalink / raw)
To: eric.dumazet; +Cc: davej, netdev, ycheng
In-Reply-To: <1384383646.28458.138.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 13 Nov 2013 15:00:46 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> We had some reports of crashes using TCP fastopen, and Dave Jones
> gave a nice stack trace pointing to the error.
>
> Issue is that tcp_get_metrics() should not be called with a NULL dst
>
> Fixes: 1fe4c481ba637 ("net-tcp: Fast Open client - cookie cache")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Dave Jones <davej@redhat.com>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH] net: sctp: bug-fixing: retran_path not set properly after transports recovering (v3)
From: David Miller @ 2013-11-14 21:36 UTC (permalink / raw)
To: changxiangzhong; +Cc: vyasevich, nhorman, linux-sctp, netdev
In-Reply-To: <1384387106-8105-1-git-send-email-changxiangzhong@gmail.com>
From: Chang Xiangzhong <changxiangzhong@gmail.com>
Date: Thu, 14 Nov 2013 00:58:26 +0100
> When a transport recovers due to the new coming sack, SCTP should
> iterate all of its transport_list to locate the __two__ most recently used
> transport and set to active_path and retran_path respectively. The exising
> code does not find the two properly - In case of the following list:
>
> [most-recent] -> [2nd-most-recent] -> ...
>
> Both active_path and retran_path would be set to the 1st element.
>
> The bug happens when:
> 1) multi-homing
> 2) failure/partial_failure transport recovers
> Both active_path and retran_path would be set to the same most-recent one, in
> other words, retran_path would not take its role - an end user might not even
> notice this issue.
>
> Signed-off-by: Chang Xiangzhong <changxiangzhong@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 1/1] net:fec: fix WARNING caused by lack of calls to dma_mapping_error()
From: David Miller @ 2013-11-14 21:37 UTC (permalink / raw)
To: B38611; +Cc: bhutchings, netdev, stephen
In-Reply-To: <1384394230-23380-1-git-send-email-B38611@freescale.com>
From: Fugang Duan <B38611@freescale.com>
Date: Thu, 14 Nov 2013 09:57:10 +0800
> The driver fails to check the results of DMA mapping and results in
> the following warning: (with kernel config "CONFIG_DMA_API_DEBUG" enable)
...
> Because dma-debug add new interfaces to debug dma mapping errors, pls refer
> to: http://lwn.net/Articles/516640/
>
> After dma mapping, it must call dma_mapping_error() to check mapping error,
> otherwise the map_err_type alway is MAP_ERR_NOT_CHECKED, check_unmap() define
> the mapping is not checked and dump the error msg. So,add dma_mapping_error()
> checking to fix the WARNING
>
> And RX DMA buffers are used repeatedly and the driver copies it into an skb,
> fec_enet_rx() should not map or unmap, use dma_sync_single_for_cpu()/dma_sync_single_for_device()
> instead of dma_map_single()/dma_unmap_single().
>
> There have another potential issue: fec_enet_rx() passes the DMA address to __va().
> Physical and DMA addresses are *not* the same thing. They may differ if the device
> is behind an IOMMU or bounce buffering was required, or just because there is a fixed
> offset between the device and host physical addresses. Also fix it in this patch.
>
> =============================================
> V2: add net_ratelimit() to limit map err message.
> use dma_sync_single_for_cpu() instead of dma_map_single().
> fix the issue that pass DMA addresses to __va() to get virture address.
> V1: initial send
> =============================================
>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
Applied, thanks a lot.
^ permalink raw reply
* [PATCH] ipv4: fix possible seqlock deadlock
From: Eric Dumazet @ 2013-11-14 21:37 UTC (permalink / raw)
To: Dave Jones, David Miller; +Cc: netdev
In-Reply-To: <1384458103.28716.33.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
ip4_datagram_connect() being called from process context,
it should use IP_INC_STATS() instead of IP_INC_STATS_BH()
otherwise we can deadlock on 32bit arches, or get corruptions of
SNMP counters.
Fixes: 584bdf8cbdf6 ("[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Dave Jones <davej@redhat.com>
---
net/ipv4/datagram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/datagram.c b/net/ipv4/datagram.c
index b28e863fe0a7..19e36376d2a0 100644
--- a/net/ipv4/datagram.c
+++ b/net/ipv4/datagram.c
@@ -57,7 +57,7 @@ int ip4_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
if (IS_ERR(rt)) {
err = PTR_ERR(rt);
if (err == -ENETUNREACH)
- IP_INC_STATS_BH(sock_net(sk), IPSTATS_MIB_OUTNOROUTES);
+ IP_INC_STATS(sock_net(sk), IPSTATS_MIB_OUTNOROUTES);
goto out;
}
^ permalink raw reply related
* Re: Fw: [Bug 64981] New: pulseaudio over network desyncs
From: Eric Dumazet @ 2013-11-14 21:40 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, tjakobi
In-Reply-To: <20131114125854.337ca105@samsung-9>
On Thu, 2013-11-14 at 12:58 -0800, Stephen Hemminger wrote:
>
> Begin forwarded message:
>
> Date: Thu, 14 Nov 2013 12:13:46 -0800
> From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
> To: "stephen@networkplumber.org" <stephen@networkplumber.org>
> Subject: [Bug 64981] New: pulseaudio over network desyncs
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=64981
>
> Bug ID: 64981
> Summary: pulseaudio over network desyncs
> Product: Networking
> Version: 2.5
> Kernel Version: 3.10.18
> Hardware: x86-64
> OS: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> Assignee: shemminger@linux-foundation.org
> Reporter: liquid.acid@gmx.net
> Regression: Yes
>
> Hello,
>
> I updated my dedicated audio server to 3.10.18 at the beginning of the week.
> Yesterday I noticed this issue:
>
> When playing back a video/audio file with mpv (mplayer2 also works), where the
> audio is streamed from my local machine to the audio server via pulseaudio, the
> playback desyncs after 5~10 seconds.
>
> The video playback goes into slow-mo, while the audio plays back fine from the
> DAC connected to the audio server. The maintainer of mpv explained that the
> application relies on the pulseaudio output module returning appropriate
> feedback about the samples played back.
>
> Which in turns requires the audio server to reply properly. Going back to
> 3.10.17 solves the issue, so I bisected and got this commit:
>
> tcp: TSQ can use a dynamic limit
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=0ae5f47eff2e543c3b94eec51c740f38a5071432
>
> What is interesting, that I only get these 5~10 seconds of proper playback
> after boot of the system. If I don't reboot, all subsequent playback attempts
> result in an immediate desync.
>
> I also double-checked that this is related to network. I setup an identical PA
> server here on my laptop (just with a different audio output device), updated
> the kernel to this specific commit and used another machine to play back some
> content. Results in the same issue, so I highly doubt this is related to audio
> components.
>
> Greets,
> Tobias
>
Should be fixed by :
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=98e09386c0ef4dfd48af7ba60ff908f0d525cdee
Thanks !
^ permalink raw reply
* Re: [PATCH] ipv4: fix possible seqlock deadlock
From: Dave Jones @ 2013-11-14 21:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1384465074.28716.41.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Nov 14, 2013 at 01:37:54PM -0800, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> ip4_datagram_connect() being called from process context,
> it should use IP_INC_STATS() instead of IP_INC_STATS_BH()
> otherwise we can deadlock on 32bit arches, or get corruptions of
> SNMP counters.
>
> Fixes: 584bdf8cbdf6 ("[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP")
whoa, 2007. Any idea why I only just started hitting this ?
Dave
^ permalink raw reply
* Re: [patch] isdnloop: use strlcpy() instead of strcpy()
From: David Miller @ 2013-11-14 21:50 UTC (permalink / raw)
To: dan.carpenter; +Cc: netdev, isdn, kernel-janitors, isdn4linux
In-Reply-To: <20131114082110.GD8150@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 14 Nov 2013 11:21:10 +0300
> These strings come from a copy_from_user() and there is no way to be
> sure they are NUL terminated.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied and queued up for -stable, thanks Dan.
^ permalink raw reply
* Re: [PATCH] ipv4: fix possible seqlock deadlock
From: Eric Dumazet @ 2013-11-14 21:52 UTC (permalink / raw)
To: Dave Jones; +Cc: David Miller, netdev
In-Reply-To: <20131114214402.GA23872@redhat.com>
On Thu, 2013-11-14 at 16:44 -0500, Dave Jones wrote:
> On Thu, Nov 14, 2013 at 01:37:54PM -0800, Eric Dumazet wrote:
> > From: Eric Dumazet <edumazet@google.com>
> >
> > ip4_datagram_connect() being called from process context,
> > it should use IP_INC_STATS() instead of IP_INC_STATS_BH()
> > otherwise we can deadlock on 32bit arches, or get corruptions of
> > SNMP counters.
> >
> > Fixes: 584bdf8cbdf6 ("[IPV4]: Fix "ipOutNoRoutes" counter error for TCP and UDP")
>
> whoa, 2007. Any idea why I only just started hitting this ?
>
lockdep support was added very recently.
^ permalink raw reply
* Re: [PATCH net v3] bonding: add ip checks when store ip target
From: David Miller @ 2013-11-14 21:55 UTC (permalink / raw)
To: dingtianhong; +Cc: fubar, andy, nikolay, vfalico, netdev
In-Reply-To: <5284ADD2.2060004@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Thu, 14 Nov 2013 19:02:42 +0800
> targets = bond->params.arp_targets;
> - newtarget = in_aton(buf + 1);
> + if (!in4_pton(buf + 1, -1, (u8 *)&newtarget, -1, NULL) ||
> + IS_IP_TARGET_UNUSABLE_ADDRESS(newtarget)) {
This is not indented correctly.
On the second line, the IS_IP_TARGET... should start at the very
first column after the openning parenthesis on the previous line.
If you are using only TAB characters to indent, rather than an
appropriate mix of TAB and SPACE characters, you are doing it
wrong.
Thanks.
^ permalink raw reply
* Re: [PATCH net 1/3] sit: fix prefix length of ll and v4mapped addresses
From: David Miller @ 2013-11-14 21:59 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <1384433467-4780-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 14 Nov 2013 13:51:05 +0100
> When the local IPv4 endpoint is wilcard (0.0.0.0), the prefix length is
> correctly set, ie 64 if the address is a link local one or 96 if the address is
> a v4 mapped one.
> But when the local endpoint is specified, the prefix length is set to 128 for
> both kind of address. This patch fix this wrong prefix length.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 2/3] sit: link local routes are missing
From: David Miller @ 2013-11-14 21:59 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <1384433467-4780-2-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 14 Nov 2013 13:51:06 +0100
> When a link local address was added to a sit interface, the corresponding route
> was not configured. This breaks routing protocols that use the link local
> address, like OSPFv3.
>
> To ease the code reading, I remove sit_route_add(), which only adds v4 mapped
> routes, and add this kind of route directly in sit_add_v4_addrs(). Thus link
> local and v4 mapped routes are configured in the same place.
>
> Reported-by: Li Hongjun <hongjun.li@6wind.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 3/3] sit/gre6: don't try to add the same route two times
From: David Miller @ 2013-11-14 21:59 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <1384433467-4780-3-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 14 Nov 2013 13:51:07 +0100
> addrconf_add_linklocal() already adds the link local route, so there is no
> reason to add it before calling this function.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH net v2 1/2] macvlan: introduce macvlan_dev_real_dev() helper function
From: David Miller @ 2013-11-14 22:03 UTC (permalink / raw)
To: mkubecek; +Cc: vyasevich, netdev, kaber, john.r.fastabend
In-Reply-To: <20131114155756.GA4161@lion.mk-sys.cz>
From: Michal Kubecek <mkubecek@suse.cz>
Date: Thu, 14 Nov 2013 16:57:57 +0100
> On Thu, Nov 14, 2013 at 10:03:19AM -0500, Vlad Yasevich wrote:
>> On 11/14/2013 09:00 AM, Michal Kubecek wrote:
>> >+#if IS_ENABLED(CONFIG_MACVLAN)
>> >+static inline struct net_device *
>> >+macvlan_dev_real_dev(const struct net_device *dev)
>> >+{
>> >+ struct macvlan_dev *macvlan = netdev_priv(dev);
>> >+
>> >+ return macvlan->lowerdev;
>> >+}
>> >+#else
>> >+static inline struct net_device *
>> >+macvlan_dev_real_dev(const struct net_device *dev)
>> >+{
>> >+ return NULL;
>> >+}
>> >+#endif
>> >+
>>
>> You may want to do the same here as was done for
>> vlan_dev_real_dev(). This function is not intended to be called
>> blindly and should always
>> be called after netif_is_macvlan().
>
> I'm not sure. It makes sense from the developer point of view: if we
> find an inconsistency which must be caused by a bug in kernel code, do
> panic so that the bug is found and fixed as soon as possible. However,
> I remember a discussion where the point was that BUG() and BUG_ON()
> should only be used if there is no way to recover. From this point of
> view, WARN or WARN_ONCE might be better choice - but I'm not strictly
> opposed to BUG().
At least for the time being use BUG(), to be consistent with the same
way how VLAN handles this situation.
Thanks.
^ 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