* Re: [PATCH v2 1/3] vxlan: silence one build warning
From: David Miller @ 2013-10-29 4:19 UTC (permalink / raw)
To: zwu.kernel; +Cc: netdev, linux-kernel, stephen, wuzhy
In-Reply-To: <1382940110-10737-1-git-send-email-zwu.kernel@gmail.com>
From: Zhi Yong Wu <zwu.kernel@gmail.com>
Date: Mon, 28 Oct 2013 14:01:48 +0800
> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
>
> drivers/net/vxlan.c: In function ‘vxlan_sock_add’:
> drivers/net/vxlan.c:2298:11: warning: ‘sock’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/net/vxlan.c:2275:17: note: ‘sock’ was declared here
> LD drivers/net/built-in.o
>
> Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH v2 1/2] net/benet: Remove interface type
From: David Miller @ 2013-10-29 4:17 UTC (permalink / raw)
To: shangw; +Cc: netdev, Sathya.Perla
In-Reply-To: <1382926367-14968-1-git-send-email-shangw@linux.vnet.ibm.com>
These two patches don't apply cleanly to net-next and that's where I
intend to apply them.
Please respin and resubmit, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2] ipv4: fix DO and PROBE pmtu mode regarding local fragmentation with UFO/CORK
From: David Miller @ 2013-10-29 4:16 UTC (permalink / raw)
To: hannes; +Cc: netdev
In-Reply-To: <20131027162911.GA4714@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Sun, 27 Oct 2013 17:29:11 +0100
> UFO as well as UDP_CORK do not respect IP_PMTUDISC_DO and
> IP_PMTUDISC_PROBE well enough.
>
> UFO enabled packet delivery just appends all frags to the cork and hands
> it over to the network card. So we just deliver non-DF udp fragments
> (DF-flag may get overwritten by hardware or virtual UFO enabled
> interface).
>
> UDP_CORK does enqueue the data until the cork is disengaged. At this
> point it sets the correct IP_DF and local_df flags and hands it over to
> ip_fragment which in this case will generate an icmp error which gets
> appended to the error socket queue. This is not reflected in the syscall
> error (of course, if UFO is enabled this also won't happen).
>
> Improve this by checking the pmtudisc flags before appending data to the
> socket and if we still can fit all data in one packet when IP_PMTUDISC_DO
> or IP_PMTUDISC_PROBE is set, only then proceed.
>
> We use (mtu-fragheaderlen) to check for the maximum length because we
> ensure not to generate a fragment and non-fragmented data does not need
> to have its length aligned on 64 bit boundaries. Also the passed in
> ip_options are already aligned correctly.
>
> Maybe, we can relax some other checks around ip_fragment. This needs
> more research.
>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
> v2:
> Switch from maxfraglen to mtu for length check as outlined in the commit
> message.
Looks good, applied.
^ permalink raw reply
* Re: [PATCH net] cxgb3: Fix length calculation in write_ofld_wr() on 32-bit architectures
From: David Miller @ 2013-10-29 4:14 UTC (permalink / raw)
To: ben; +Cc: divy, netdev
In-Reply-To: <1382907759.2994.36.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sun, 27 Oct 2013 21:02:39 +0000
> The length calculation here is now invalid on 32-bit architectures,
> since sk_buff::tail is a pointer and sk_buff::transport_header is
> an integer offset:
>
> drivers/net/ethernet/chelsio/cxgb3/sge.c: In function 'write_ofld_wr':
> drivers/net/ethernet/chelsio/cxgb3/sge.c:1603:9: warning: passing argument 4 of 'make_sgl' makes integer from pointer without a cast [enabled by default]
> adap->pdev);
> ^
> drivers/net/ethernet/chelsio/cxgb3/sge.c:964:28: note: expected 'unsigned int' but argument is of type 'sk_buff_data_t'
> static inline unsigned int make_sgl(const struct sk_buff *skb,
> ^
>
> Use the appropriate skb accessor functions.
>
> Compile-tested only.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> Fixes: 1a37e412a022 ('net: Use 16bits for *_headers fields of struct skbuff')
> ---
> This is needed for 3.11-stable.
Applied and queued up for -stable, thanks Ben.
^ permalink raw reply
* Re: [PATCH net 0/2] bnx2x: Bug fixes patch series
From: David Miller @ 2013-10-29 4:13 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, dmitry, ariele, eilong
In-Reply-To: <1382872008-1073-1-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Sun, 27 Oct 2013 13:06:47 +0200
> This series contains 2 unrelated fixes:
>
> 1. FW asserts during unload might be encountered if specific memory
> allocations fail during load.
>
> 2. SR-IOV related, fixes a crash that will occour if the driver were to
> be rmmoded and then re-probed while there are both assigned and unassigned
> VFs originating from the same PF.
>
> Please consider applying these patches to `net'.
Both applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: introduce new IP_MTU_DISCOVER mode IP_PMTUDISC_INTERFACE
From: David Miller @ 2013-10-29 4:08 UTC (permalink / raw)
To: hannes; +Cc: netdev, fweimer
In-Reply-To: <20131026201158.GI15744@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Sat, 26 Oct 2013 22:11:58 +0200
> Sockets marked with IP_PMTUDISC_INTERFACE won't do path mtu discovery,
> their sockets won't accept and install new path mtu information and they
> will always use the interface mtu for outgoing packets. It is guaranteed
> that the packet is not fragmented locally. But we won't set the DF-Flag
> on the outgoing frames.
>
> Florian Weimer had the idea to use this flag to ensure DNS servers are
> never generating outgoing fragments. They may well be fragmented on the
> path, but the server never stores or usees path mtu values, which could
> well be forged in an attack.
>
> (The root of the problem with path MTU discovery is that there is
> no reliable way to authenticate ICMP Fragmentation Needed But DF Set
> messages because they are sent from intermediate routers with their
> source addresses, and the IMCP payload will not always contain sufficient
> information to identify a flow.)
I do not like this reasoning. You have several more acceptable paths to take
to resolve this problem:
1) "I don't trust path MTU information at all"
Just turn it off globally, end of story. It has the same effect as your
new per-application mode.
2) "I don't trust path MTU information unless the full socket ID is available
in the ICMP packets quoted headers"
Then simply implement a policy as such and submit it to me.
^ permalink raw reply
* Re: [PATCH net-next] tcp: gso: fix truesize tracking
From: David Miller @ 2013-10-29 4:05 UTC (permalink / raw)
To: eric.dumazet; +Cc: ast, edumazet, stephen, netdev
In-Reply-To: <1382747177.4032.21.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 25 Oct 2013 17:26:17 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> commit 6ff50cd55545 ("tcp: gso: do not generate out of order packets")
> had an heuristic that can trigger a warning in skb_try_coalesce(),
> because skb->truesize of the gso segments were exactly set to mss.
>
> This breaks the requirement that
>
> skb->truesize >= skb->len + truesizeof(struct sk_buff);
>
> It can trivially be reproduced by :
>
> ifconfig lo mtu 1500
> ethtool -K lo tso off
> netperf
>
> As the skbs are looped into the TCP networking stack, skb_try_coalesce()
> warns us of these skb under-estimating their truesize.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Alexei Starovoitov <ast@plumgrid.com>
I decided to apply this to 'net' and queue it up for -stable,
thanks Eric!
^ permalink raw reply
* Re: [PATCH net-next] 3c515: Fix warning when building
From: David Miller @ 2013-10-29 4:03 UTC (permalink / raw)
To: ricec2; +Cc: netdev
In-Reply-To: <1382738386-29888-1-git-send-email-ricec2@rpi.edu>
From: Colin Rice <ricec2@rpi.edu>
Date: Fri, 25 Oct 2013 21:59:46 +0000
> - outl((int) (skb->data), ioaddr + Wn7_MasterAddr);
> + outl((size_t) (skb->data), ioaddr + Wn7_MasterAddr);
outl() takes an "int" not a "size_t". You're avoiding the warning,
but on 64-bit, for example, you're silently allowing the compiler
to accept chopping off the top 32-bits of the 64-bit pointer address
off.
The warning is valid, this code won't work in certain environments,
and killing the warning is just papering over the problem such that
it will never get addressed properly.
I'm not applying patches like this, sorry.
^ permalink raw reply
* Re: [PATCH net-next] WD80x3: fix printk() calls to netdev_*() calls
From: David Miller @ 2013-10-29 4:00 UTC (permalink / raw)
To: quantumdude836; +Cc: netdev
In-Reply-To: <1382738165-27852-1-git-send-email-quantumdude836@gmail.com>
From: Drew McGowen <quantumdude836@gmail.com>
Date: Fri, 25 Oct 2013 21:56:05 +0000
> - printk("%s: WD80x3 at %#3x, %pM",
> - dev->name, ioaddr, dev->dev_addr);
> + netdev_info(dev, "WD80x3 at %#3x, %pM",
> + ioaddr, dev->dev_addr);
This is incorrect indentation.
On a multi-line function call, the arguments one the second and subsequent
lines must start at exactly the first column after the openning parenthesis
on the first line.
Everyone who makes this mistake is trying to be lazy and use only TAB
characters to indent their code, don't do this. You must use the
appropriate number of TAB _and_ SPACE characters necessary to achieve
the correct indentation.
^ permalink raw reply
* Re: [BUG] 3.12.0-rcX IPv6 panic
From: Bob Tracy @ 2013-10-29 4:00 UTC (permalink / raw)
To: linux-kernel, netdev
In-Reply-To: <20131021234041.GA12350@gherkin.frus.com>
On Mon, Oct 21, 2013 at 06:40:41PM -0500, Bob Tracy wrote:
> On Mon, Oct 21, 2013 at 05:52:52PM +0200, Hannes Frederic Sowa wrote:
> > On Mon, Oct 21, 2013 at 08:18:46AM -0500, Bob Tracy wrote:
> > > Actually, a regression: the 3.11 kernel is rock-solid stable on my
> > > Alpha.
> > >
> > > Beginning with 3.12.0-rc1, I can reliably trigger a kernel panic by
> > > executing the gogo6.net "gw6c" IPv6 client program. If the networking
> > > layer is active, an "Oops" will eventually (within a day) occur regardless
> > > of whether I attempt to run "gw6c". 3.12.0-rcX is stable as long as I
> > > leave networking completely disabled. The error has persisted up through
> > > -rc6. Apologies for not mentioning this earlier, but the state of my
> > > PWS-433au has been questionable, and I wanted to make sure I had a
> > > legitimate bug sighting.
> > >
> > > I'll have to transcribe the panic backtrace by hand: nothing makes it
> > > into any of the system logs :-(. I *can* recall that every backtrace
> > > I've seen thus far has included one of the skb_copy() variants near the
> > > top of the list (first or second function).
> >
> > Try to capture the panic via serial console. Otherwise a picture
> > would give us a first hint. Please watch out for lines like
> > skb_(over|under)_panic.
>
> I'll get a screen capture of some kind for you within the next day or
> so.
>
> > gw6c is a tunnel client? Can you post ip -6 tunnel ls?
>
> Assuming you meant "show [NAME]" (no "ls" option for the tunnel object),
> that yields the following with "gw6c" running on a 3.11.0 kernel:
>
> smirkin:~# ip -6 tunnel show sit1
> sit1: any/ipv6 remote 4056:5874:: local 4500:0:0:4000:4029:: encaplimit 0 hoplimit 0 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)
>
> I'm running the gw6c client in gateway mode: the Alpha is my IPv6
> gateway/firewall.
Update: no significant change for 3.12.0-rc7. Can still reliably panic
the system by running "gw6c" to set up the IPv6 tunnel. Here's a hand-
transcribed backtrace: I hope it's sufficient... I would have included
the stack/register dump, but about half of it had scrolled off the top
of the screen.
skb_copy_and_csum_bits+0x88/0x380
icmp_glue_bits+0x48/0xce0
__ip_append_data+0x8f4/0xb40
ip_append_data+0xb0/0x130
icmp_glue_bits+0x0/0xe0
icmp_glue_bits+0x0/0xe0 (yes: repeated once)
icmp_push_reply+0x6c/0x190
icmp_send+0x3fc/0x4c0
ip_local_deliver_finish+0x20c/0x2e0
ip_rcv_finish+0x1d8/0x3d0
nf_ct_attach+0x32/0x40
ip_rcv_finish_0x148/0x3d0
__netif_receive_skb_core+0x27c/0x890
process_backlog+0xb8/0x1a0
net_rx_action+0xc8/0x210
__do_softirq+0x1a0/0x230
do_softirq+0x5c/0x70
irq_exit+0x68/0x80
handle_irq+0x90/0xf0
miata_srm_device_interrupt+0x30/0x50
do_entInt+0x1cc/0x1f0
__do_fault+0x3e0/0x5e0
ret_from_sys_call+0x0/0x10
entMM+0x9c/0xc0
do_page_fault+0x0/0x500
do_page_fault+0x48/0x500
entMM+0x9c/0xc0
filp_close+0x6c/0xe0
filp_close+0x98/0xe0
filp_close+0x6c/0xe0
filp_close+0x98/0xe0
__close_fd+0xb8/0xe0
Code: 44640003 e4600010 203ffff2 a77de680 b67e0010 47f10410 <b0340000> 47ff0411
--Bob
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: migrate mergeable rx buffers to page frag allocators
From: David Miller @ 2013-10-29 3:57 UTC (permalink / raw)
To: eric.dumazet
Cc: ffusco, mwdalton, mst, netdev, dborkman, virtualization, edumazet
In-Reply-To: <1383002389.4344.7.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 28 Oct 2013 16:19:49 -0700
> On Mon, 2013-10-28 at 15:44 -0700, Michael Dalton wrote:
>> The virtio_net driver's mergeable receive buffer allocator
>> uses 4KB packet buffers. For MTU-sized traffic, SKB truesize
>> is > 4KB but only ~1500 bytes of the buffer is used to store
>> packet data, reducing the effective TCP window size
>> substantially. This patch addresses the performance concerns
>> with mergeable receive buffers by allocating MTU-sized packet
>> buffers using page frag allocators. If more than MAX_SKB_FRAGS
>> buffers are needed, the SKB frag_list is used.
>>
>> Signed-off-by: Michael Dalton <mwdalton@google.com>
>> ---
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> Daniel & Francesco, this should address the performance problem you
> tried to address with ("tcp: rcvbuf autotuning improvements")
>
> ( http://www.spinics.net/lists/netdev/msg252642.html )
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next 2/3] tipc: message reassembly using fragment chain
From: David Miller @ 2013-10-29 3:49 UTC (permalink / raw)
To: ying.xue
Cc: maloy, jon.maloy, paul.gortmaker, erik.hugne, tipc-discussion,
netdev
In-Reply-To: <526F15E8.9020009@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Tue, 29 Oct 2013 09:56:56 +0800
> Therefore, the best method is to divide tipc_recv_msg() into several
> smaller functions to simplify the current implementation. But it's not
> an easy job. Actually I ever tried to do it, but I gave up lastly
> because I did not find one perfect solution about how to divide it.
But you're going to have to find a way, this indent level is out of
control.
^ permalink raw reply
* Re: [PATCH] ethernet/arc/arc_emac: drop redundant mac address check
From: David Miller @ 2013-10-29 3:48 UTC (permalink / raw)
To: luka; +Cc: netdev, abrodkin
In-Reply-To: <1383010340-26445-1-git-send-email-luka@openwrt.org>
I've seen you use three inconsistent Subject prefixes here, pick a scheme
and stick to it please!
First patch was:
netdev: ${driver_name}:
Second patch was:
net: ${driver_name}:
Third patch was:
patch/to/driver/directory:
This is really not acceptable. Just using "${driver_name}: " is good
enough.
^ permalink raw reply
* [PATCH] net/cdc_ncm: fix null pointer panic at usbnet_link_change
From: Du, ChangbinX @ 2013-10-29 3:30 UTC (permalink / raw)
To: oliver@neukum.org
Cc: linux-usb@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
From: "Du, Changbin" <changbinx.du@intel.com>
In cdc_ncm_bind() function, it call cdc_ncm_bind_common() to setup usb.
But cdc_ncm_bind_common() may meet error and cause usbnet_disconnect()
be called which calls free_netdev(net). Thus usbnet structure(alloced
with net_device structure) will be freed,too.
So we cannot call usbnet_link_change() if cdc_ncm_bind_common() return
error.
BUG: unable to handle kernel NULL pointer dereference at 00000078
EIP is at usbnet_link_change+0x1e/0x80
Call Trace:
[<c24bc69a>] cdc_ncm_bind+0x3a/0x50
[<c24b8d32>] usbnet_probe+0x282/0x7d0
[<c2167f2c>] ? sysfs_new_dirent+0x6c/0x100
[<c2821253>] ? mutex_lock+0x13/0x40
[<c24bb278>] cdc_ncm_probe+0x8/0x10
[<c24e0ef7>] usb_probe_interface+0x187/0x2c0
[<c23caa8a>] ? driver_sysfs_add+0x6a/0x90
[<c23cb290>] ? __driver_attach+0x90/0x90
[<c23caf14>] driver_probe_device+0x74/0x360
[<c24e07b1>] ? usb_match_id+0x41/0x60
[<c24e081e>] ? usb_device_match+0x4e/0x90
[<c23cb290>] ? __driver_attach+0x90/0x90
[<c23cb2c9>] __device_attach+0x39/0x50
[<c23c93f4>] bus_for_each_drv+0x34/0x70
[<c23cae2b>] device_attach+0x7b/0x90
[<c23cb290>] ? __driver_attach+0x90/0x90
[<c23ca38f>] bus_probe_device+0x6f/0x90
[<c23c8a08>] device_add+0x558/0x630
[<c24e4821>] ? usb_create_ep_devs+0x71/0xd0
[<c24dd0db>] ? create_intf_ep_devs+0x4b/0x70
[<c24df2bf>] usb_set_configuration+0x4bf/0x800
[<c23cb290>] ? __driver_attach+0x90/0x90
[<c24e809b>] generic_probe+0x2b/0x90
[<c24e105c>] usb_probe_device+0x2c/0x70
[<c23caf14>] driver_probe_device+0x74/0x360
Signed-off-by: Du, Changbin <changbinx.du@intel.com>
---
drivers/net/usb/cdc_ncm.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 43afde8..af37ecf 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -603,14 +603,15 @@ static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
/* NCM data altsetting is always 1 */
ret = cdc_ncm_bind_common(dev, intf, 1);
-
- /*
- * We should get an event when network connection is "connected" or
- * "disconnected". Set network connection in "disconnected" state
- * (carrier is OFF) during attach, so the IP network stack does not
- * start IPv6 negotiation and more.
- */
- usbnet_link_change(dev, 0, 0);
+ if (!ret) {
+ /*
+ * We should get an event when network connection is "connected"
+ * or "disconnected". Set network connection in "disconnected"
+ * state (carrier is OFF) during attach, so the IP network stack
+ * does not start IPv6 negotiation and more.
+ */
+ usbnet_link_change(dev, 0, 0);
+ }
return ret;
}
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH net V3] xen-netback: use jiffies_64 value to calculate credit timeout
From: annie li @ 2013-10-29 2:39 UTC (permalink / raw)
To: Wei Liu; +Cc: xen-devel, netdev, david.vrabel, jbeulich, Ian Campbell,
Jason Luan
In-Reply-To: <1382962077-13406-1-git-send-email-wei.liu2@citrix.com>
On 2013-10-28 20:07, Wei Liu wrote:
> time_after_eq() only works if the delta is < MAX_ULONG/2.
>
> For a 32bit Dom0, if netfront sends packets at a very low rate, the time
> between subsequent calls to tx_credit_exceeded() may exceed MAX_ULONG/2
> and the test for timer_after_eq() will be incorrect. Credit will not be
> replenished and the guest may become unable to send packets (e.g., if
> prior to the long gap, all credit was exhausted).
>
> Use jiffies_64 variant to mitigate this problem for 32bit Dom0.
>
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Reviewed-by: David Vrabel <david.vrabel@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jason Luan <jianhai.luan@oracle.com>
> ---
> drivers/net/xen-netback/common.h | 1 +
> drivers/net/xen-netback/interface.c | 3 +--
> drivers/net/xen-netback/netback.c | 10 +++++-----
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
> index 5715318..400fea1 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -163,6 +163,7 @@ struct xenvif {
> unsigned long credit_usec;
> unsigned long remaining_credit;
> struct timer_list credit_timeout;
> + u64 credit_window_start;
>
> /* Statistics */
> unsigned long rx_gso_checksum_fixup;
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index 01bb854..459935a 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -312,8 +312,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
> vif->credit_bytes = vif->remaining_credit = ~0UL;
> vif->credit_usec = 0UL;
> init_timer(&vif->credit_timeout);
> - /* Initialize 'expires' now: it's used to track the credit window. */
> - vif->credit_timeout.expires = jiffies;
> + vif->credit_window_start = get_jiffies_64();
>
> dev->netdev_ops = &xenvif_netdev_ops;
> dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO;
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index f3e591c..900da4b 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1185,9 +1185,8 @@ out:
>
> static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
> {
> - unsigned long now = jiffies;
> - unsigned long next_credit =
> - vif->credit_timeout.expires +
> + u64 now = get_jiffies_64();
> + u64 next_credit = vif->credit_window_start +
> msecs_to_jiffies(vif->credit_usec / 1000);
>
> /* Timer could already be pending in rare cases. */
> @@ -1195,8 +1194,8 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
> return true;
>
> /* Passed the point where we can replenish credit? */
> - if (time_after_eq(now, next_credit)) {
> - vif->credit_timeout.expires = now;
> + if (time_after_eq64(now, next_credit)) {
> + vif->credit_window_start = now;
> tx_add_credit(vif);
> }
>
> @@ -1208,6 +1207,7 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
> tx_credit_callback;
> mod_timer(&vif->credit_timeout,
> next_credit);
> + vif->credit_window_start = next_credit;
>
> return true;
> }
This patch looks good, thanks Wei.
Thanks
Annie
^ permalink raw reply
* Re: [PATCH] bridge: pass correct vlan id to multicast code
From: Amos Kong @ 2013-10-29 2:36 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, shemminger, makita.toshiaki
In-Reply-To: <1382989507-23061-1-git-send-email-vyasevic@redhat.com>
On Mon, Oct 28, 2013 at 03:45:07PM -0400, Vlad Yasevich wrote:
> Currently multicast code attempts to extrace the vlan id from
> the skb even when vlan filtering is disabled. This can lead
> to mdb entries being created with the wrong vlan id.
> Pass the already extracted vlan id to the multicast
> filtering code to make the correct id is used in
> creation as well as lookup.
Hi Vlad,
Can we just update br_vlan_get_tag() to set vid to 0 if dev->vlan is
disabled? I guess it would effect br_handle_local_finish().
> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
> ---
> net/bridge/br_device.c | 2 +-
> net/bridge/br_input.c | 2 +-
> net/bridge/br_multicast.c | 44 +++++++++++++++++++-------------------------
> net/bridge/br_private.h | 6 ++++--
> 4 files changed, 25 insertions(+), 29 deletions(-)
...
> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> index 8b0b610..686284f 100644
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -947,7 +947,8 @@ void br_multicast_disable_port(struct net_bridge_port *port)
>
> static int br_ip4_multicast_igmp3_report(struct net_bridge *br,
> struct net_bridge_port *port,
> - struct sk_buff *skb)
> + struct sk_buff *skb,
> + u16 vid)
> {
> struct igmpv3_report *ih;
> struct igmpv3_grec *grec;
> @@ -957,12 +958,10 @@ static int br_ip4_multicast_igmp3_report(struct net_bridge *br,
> int type;
> int err = 0;
> __be32 group;
> - u16 vid = 0;
>
> if (!pskb_may_pull(skb, sizeof(*ih)))
> return -EINVAL;
>
> - br_vlan_get_tag(skb, &vid);
After applied the patch, we always use vid in br_dev_xmit()->br_allowed_ingress(),
is it possible that the vlan of bridge is re-enabled when other
changed functions are called?
We can just add a enabled checking before this kind of br_vlan_get_tag()?
if (!br->vlan_enabled)
br_vlan_get_tag(skb2, &vid);
> ih = igmpv3_report_hdr(skb);
> num = ntohs(ih->ngrec);
> len = sizeof(*ih);
...
--
Amos.
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: migrate mergeable rx buffers to page frag allocators
From: Rusty Russell @ 2013-10-29 1:51 UTC (permalink / raw)
To: Michael Dalton, David S. Miller
Cc: netdev, Eric Dumazet, Michael S. Tsirkin, Daniel Borkmann,
virtualization, Michael Dalton
In-Reply-To: <1383000258-1458-1-git-send-email-mwdalton@google.com>
Michael Dalton <mwdalton@google.com> writes:
> The virtio_net driver's mergeable receive buffer allocator
> uses 4KB packet buffers. For MTU-sized traffic, SKB truesize
> is > 4KB but only ~1500 bytes of the buffer is used to store
> packet data, reducing the effective TCP window size
> substantially. This patch addresses the performance concerns
> with mergeable receive buffers by allocating MTU-sized packet
> buffers using page frag allocators. If more than MAX_SKB_FRAGS
> buffers are needed, the SKB frag_list is used.
>
> Signed-off-by: Michael Dalton <mwdalton@google.com>
Hi Michael,
Nice work! Just one comment. Your patch highlights the
anachronistic name MAX_PACKET_LEN: it was from the original
implementation which only supported 1500 byte packets, and only used in
one place.
Please apply a first patch like this, then come up with a new constant
name (GOOD_PACKET_LEN?) for that value. Because it's not the maximum
packet we can receive for mergable buffers.
Thanks,
Rusty.
Subject: virtio_net: remove anachronistic MAX_PACKET_LEN constant.
From: Rusty Russell <rusty@rustcorp.com.au>
The initial implementation of virtio_net only allowed ethernet-style
MTU packets; with more recent features this isn't true. Move the
constant into the function where it's used.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 057ea13..dcbfccd 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -35,8 +35,6 @@ static bool csum = true, gso = true;
module_param(csum, bool, 0444);
module_param(gso, bool, 0444);
-/* FIXME: MTU in config. */
-#define MAX_PACKET_LEN (ETH_HLEN + VLAN_HLEN + ETH_DATA_LEN)
#define GOOD_COPY_LEN 128
#define VIRTNET_DRIVER_VERSION "1.0.0"
@@ -434,12 +432,13 @@ static int add_recvbuf_small(struct receive_queue *rq, gfp_t gfp)
struct sk_buff *skb;
struct skb_vnet_hdr *hdr;
int err;
+ const int len = ETH_HLEN + VLAN_HLEN + ETH_DATA_LEN;
- skb = __netdev_alloc_skb_ip_align(vi->dev, MAX_PACKET_LEN, gfp);
+ skb = __netdev_alloc_skb_ip_align(vi->dev, len, gfp);
if (unlikely(!skb))
return -ENOMEM;
- skb_put(skb, MAX_PACKET_LEN);
+ skb_put(skb, len);
hdr = skb_vnet_hdr(skb);
sg_set_buf(rq->sg, &hdr->hdr, sizeof hdr->hdr);
^ permalink raw reply related
* Re: [PATCH net-next 2/3] tipc: message reassembly using fragment chain
From: Ying Xue @ 2013-10-29 1:56 UTC (permalink / raw)
To: Jon Maloy; +Cc: jon.maloy, netdev, tipc-discussion, David Miller
In-Reply-To: <526E3B49.9030506@donjonn.com>
On 10/28/2013 06:24 PM, Jon Maloy wrote:
> On 10/28/2013 01:07 AM, David Miller wrote:
>> From: Jon Maloy <jon.maloy@ericsson.com>
>> Date: Sat, 26 Oct 2013 14:41:02 -0400
>>
>>> + int ret = tipc_link_recv_fragment(
>>> + &node->bclink.reasm_head,
>>> + &node->bclink.reasm_tail,
>>> + &buf);
>> This is not the correct way to indent a function call that spans
>> multiple lines. In such a situation the arguments that appear
>> on the second and subsequent lines must start at the first column
>> after the openning parenthesis of the function call.
>>
>> Like this:
>>
>> func(a, b, c,
>> d, e, f);
>>
>> Please audit this in your entire set of patches and resubmit,
>> thanks.
>
> Doing as David says here means that some lines will be >80 chars.
> This was the reason for the somewhat strange indentation.
> I tried to rename the function to tipc_link_rcv_fragm(), but one
> line was still too long. The problem we have goes deeper.
>
> In Linus' coding style manual I read that the 80 char limit is a hard limit,
> a limit we violate in several places. One offender is that we have too
> many indentation levels, at least in tipc_recv_msg() and probably in
> some other places. This is sensitive code, that I don't feel for touching
> right now. A more low hanging fruit is our local variable names:
> names such as l_ptr, n_ptr, b_ptr is exactly what Linus characterizes
> as "brain dead Hungarian style", and I never liked that naming anyway.
> For me l, n, and b is good enough as long as the context is clear.
>
> But, doing so, at least in tipc_recv_msg(), would require another, separate,
> patch, and it would lead to style inconsistency.
>
> In brief, I am at loss about to proceed here, and I am not going to submit
> this patch again until I have some feedback from somebody who can tell me
> what is the right thing to do. Maybe > 80 chars is fine for now?
>
It's hard completely resolve the issue by simply changing variable
names. So in my opinion, this is not a simple code style problem any
more. As tipc_recv_msg() is too complex, it includes at least three
embedded loops so that it doesn't remain too much space for functions in
the most inner loop. This is the key point.
Therefore, the best method is to divide tipc_recv_msg() into several
smaller functions to simplify the current implementation. But it's not
an easy job. Actually I ever tried to do it, but I gave up lastly
because I did not find one perfect solution about how to divide it.
Regards,
Ying
> ///jon
>
>
>
>
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
^ permalink raw reply
* Re: [PATCH 2/4] wl1251: move power GPIO handling into the driver
From: Mark Brown @ 2013-10-29 1:33 UTC (permalink / raw)
To: Grazvydas Ignotas, Alexander Shiyan, Luciano Coelho, Mark Rutland,
devicetree, Russell King, Pawel Moll, Ian Campbell, Tony Lindgren,
Greg Kroah-Hartman, Stephen Warren, linux-doc, John W. Linville,
Rob Herring, linux-kernel@vger.kernel.org, Sachin Kamat,
Bill Pemberton, Felipe Balbi, Rob Landley, netdev,
linux-wireless@vger.kernel.org, linux-omap@vger.kernel.org
In-Reply-To: <20131028232624.GA950@earth.universe>
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
On Tue, Oct 29, 2013 at 12:26:26AM +0100, Sebastian Reichel wrote:
> 1. The pin is named PMEN in the Nokia N900 schematics
> 2. PMEN is described as "Power management enable - system shutdown"
> in a crippled datasheet of the wl1253, which I found in the internet.
> I don't think this is supposed to be handled by the regulator API.
I agree, this sounds like a GPIO that the driver should be understanding
directly to me.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] ethernet/arc/arc_emac: drop redundant mac address check
From: Luka Perkov @ 2013-10-29 1:32 UTC (permalink / raw)
To: netdev; +Cc: abrodkin, Luka Perkov
Checking if MAC address is valid using is_valid_ether_addr() is already done in
of_get_mac_address(). While at it, reorganize checking so it matches checks in
other drivers.
Signed-off-by: Luka Perkov <luka@openwrt.org>
---
drivers/net/ethernet/arc/emac_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/arc/emac_main.c b/drivers/net/ethernet/arc/emac_main.c
index 9e16014..d818ded 100644
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -725,10 +725,10 @@ static int arc_emac_probe(struct platform_device *pdev)
/* Get MAC address from device tree */
mac_addr = of_get_mac_address(pdev->dev.of_node);
- if (!mac_addr || !is_valid_ether_addr(mac_addr))
- eth_hw_addr_random(ndev);
- else
+ if (mac_addr)
memcpy(ndev->dev_addr, mac_addr, ETH_ALEN);
+ else
+ eth_hw_addr_random(ndev);
dev_info(&pdev->dev, "MAC address is now %pM\n", ndev->dev_addr);
--
1.8.4.1
^ permalink raw reply related
* [PATCH] net: mvneta: drop redundant mac address check
From: Luka Perkov @ 2013-10-29 1:29 UTC (permalink / raw)
To: netdev; +Cc: thomas.petazzoni, Luka Perkov
Checking if MAC address is valid using is_valid_ether_addr() is already done in
of_get_mac_address().
Signed-off-by: Luka Perkov <luka@openwrt.org>
---
drivers/net/ethernet/marvell/mvneta.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index e35bac7..7d99e695 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2811,7 +2811,7 @@ static int mvneta_probe(struct platform_device *pdev)
}
dt_mac_addr = of_get_mac_address(dn);
- if (dt_mac_addr && is_valid_ether_addr(dt_mac_addr)) {
+ if (dt_mac_addr) {
mac_from = "device tree";
memcpy(dev->dev_addr, dt_mac_addr, ETH_ALEN);
} else {
--
1.8.4.1
^ permalink raw reply related
* [PATCH] netdev: octeon_mgmt: drop redundant mac address check
From: Luka Perkov @ 2013-10-29 1:27 UTC (permalink / raw)
To: netdev; +Cc: david.daney, Luka Perkov
Checking if MAC address is valid using is_valid_ether_addr() is already done in
of_get_mac_address().
Signed-off-by: Luka Perkov <luka@openwrt.org>
---
drivers/net/ethernet/octeon/octeon_mgmt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/octeon/octeon_mgmt.c b/drivers/net/ethernet/octeon/octeon_mgmt.c
index 622aa75..1b326cbc 100644
--- a/drivers/net/ethernet/octeon/octeon_mgmt.c
+++ b/drivers/net/ethernet/octeon/octeon_mgmt.c
@@ -1545,7 +1545,7 @@ static int octeon_mgmt_probe(struct platform_device *pdev)
mac = of_get_mac_address(pdev->dev.of_node);
- if (mac && is_valid_ether_addr(mac))
+ if (mac)
memcpy(netdev->dev_addr, mac, ETH_ALEN);
else
eth_hw_addr_random(netdev);
--
1.8.4.1
^ permalink raw reply related
* Re: Bug in skb_segment: fskb->len != len
From: Eric Dumazet @ 2013-10-29 1:15 UTC (permalink / raw)
To: Christoph Paasch; +Cc: Herbert Xu, netdev
In-Reply-To: <1382966471.13037.18.camel@edumazet-glaptop.roam.corp.google.com>
On Mon, 2013-10-28 at 06:21 -0700, Eric Dumazet wrote:
> But we also need to fix the skb_segment() bug anyway.
Hi Christoph
I cooked a minimal patch, could you please try it ?
I'll refactor skb_segment() to be smarter for the next release
(linux-3.14).
Thanks !
net/core/skbuff.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 0ab32faa520f..771946487a8d 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2761,7 +2761,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
unsigned int len;
__be16 proto;
bool csum;
- int sg = !!(features & NETIF_F_SG);
+ bool sg = !!(features & NETIF_F_SG);
int nfrags = skb_shinfo(skb)->nr_frags;
int err = -ENOMEM;
int i = 0;
@@ -2793,7 +2793,11 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
hsize = len;
if (!hsize && i >= nfrags) {
- BUG_ON(fskb->len != len);
+ if (fskb->len != len) {
+ hsize = len;
+ sg = false;
+ goto do_linear;
+ }
pos += len;
nskb = skb_clone(fskb, GFP_ATOMIC);
@@ -2812,6 +2816,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
skb_release_head_state(nskb);
__skb_push(nskb, doffset);
} else {
+do_linear:
nskb = __alloc_skb(hsize + doffset + headroom,
GFP_ATOMIC, skb_alloc_rx_flag(skb),
NUMA_NO_NODE);
@@ -2838,9 +2843,6 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
nskb->data - tnl_hlen,
doffset + tnl_hlen);
- if (fskb != skb_shinfo(skb)->frag_list)
- goto perform_csum_check;
-
if (!sg) {
nskb->ip_summed = CHECKSUM_NONE;
nskb->csum = skb_copy_and_csum_bits(skb, offset,
@@ -2849,6 +2851,9 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
continue;
}
+ if (fskb != skb_shinfo(skb)->frag_list)
+ goto perform_csum_check;
+
frag = skb_shinfo(nskb)->frags;
skb_copy_from_linear_data_offset(skb, offset,
^ permalink raw reply related
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: David Miller @ 2013-10-29 0:46 UTC (permalink / raw)
To: hannes
Cc: dcbw, jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji, kaber,
thaller, stephen
In-Reply-To: <20131029001340.GC26185@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Tue, 29 Oct 2013 01:13:40 +0100
> On Mon, Oct 28, 2013 at 08:08:10PM -0400, David Miller wrote:
>> From: Dan Williams <dcbw@redhat.com>
>> Date: Mon, 28 Oct 2013 18:16:19 -0500
>>
>> > On Mon, 2013-10-28 at 17:17 -0400, David Miller wrote:
>> > First off, what's the reasoning behind having IPv6 privacy as a config
>> > option? It's off-by-default and must be explicitly turned on, so is
>> > there any harm in removing the config? Or is it just for
>> > smallest-kernel-ever folks?
>>
>> I think it's for "smallest kernel ever" stuff. Even every arch
>> defconfig that mentions it has it enabled :-)
>>
>> Maybe it was optional initially because the code was new and
>> experimental'ish. I don't know.
>>
>> Regardless of the reason I think it only obfuscates the code with
>> ifdefs right now and I would be happy to see it disappear.
>>
>> Any objections to this patch?
>
> Yeah, I changed my mind. The ifdefs are really hideous. Fine for me.
Ok, pushed to net-next.
^ permalink raw reply
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: David Miller @ 2013-10-29 0:43 UTC (permalink / raw)
To: hannes
Cc: jiri, vyasevich, netdev, kuznet, jmorris, yoshfuji, kaber,
thaller, stephen
In-Reply-To: <20131028233158.GA26185@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Tue, 29 Oct 2013 00:31:58 +0100
> I wonder why NetworkManager rewrote IPv6 router discovery but not IPv4
> DHCP client stuff. It could have been a good moment to introduce something
> like PROT_DHCP sockets. Maybe it is not too late... ;)
Note that you don't even need to put the DHCP protocol core into the
kernel to fix the promiscuous problem. You just have to use the
current kernel interfaces correctly.
It used to be the case a very long time ago that you couldn't even
receive broadcast UDP datagrams on a socket until an address was
configured on it.
So everyone turns on promiscuous mode and uses RAW sockets or
AF_PACKET.
Stupid? yes.
But now the kernel will receive broadcast UDP datagrams just fine even
if there are no ipv4 addresses assigned yet.
I did a mock-up simple ipv4 DHCP client implementation just to test it
out, and it did work just fine. Unfortunately, I can't find it at the
moment, I hope I didn't just delete it in frustration. :-)
> My current idea to handle this, is that a kernel boot parameter is
> provided to stop the generation of link-local addresses and that we kick
> off address configuration from user-space at early as the secret key is
> provided, which may well be from the initramfs. I'll send a RFC as soon
> as I can find some time to clean it up and have it actually tested.
I guess I'm ok with this, as I can't come up with any reasonable
alternative scheme.
^ 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