* [PATCH] staging: rtl8821ae: Fix potential infinite loop
From: Larry Finger @ 2014-02-12 23:10 UTC (permalink / raw)
To: gregkh; +Cc: netdev, devel, Larry Finger
Smatch reports the following:
drivers/staging/rtl8821ae/rtl8821ae/hw.c:153 _rtl8821ae_set_fw_clock_on() info: ignoring unreachable code.
Upon investigation, the code in this region has the capability of creating
an infinite loop.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/staging/rtl8821ae/rtl8821ae/hw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hw.c b/drivers/staging/rtl8821ae/rtl8821ae/hw.c
index 5ed7a11..e8344be 100644
--- a/drivers/staging/rtl8821ae/rtl8821ae/hw.c
+++ b/drivers/staging/rtl8821ae/rtl8821ae/hw.c
@@ -147,6 +147,7 @@ static void _rtl8821ae_set_fw_clock_on(struct ieee80211_hw *hw,
} else {
rtlhal->bfw_clk_change_in_progress = false;
spin_unlock_bh(&rtlpriv->locks.fw_ps_lock);
+ break;
}
}
--
1.8.4.5
^ permalink raw reply related
* Re: bnx2x + SR-IOV, no internal L2 switching
From: Ben Hutchings @ 2014-02-12 23:10 UTC (permalink / raw)
To: yoann.juet; +Cc: netdev, Ariel Elior
In-Reply-To: <52FB7843.6050601@univ-nantes.fr>
[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]
On Wed, 2014-02-12 at 14:33 +0100, Yoann Juet wrote:
> Hi all,
>
> I'm conducting experiments on SR-IOV with Broadcom and Intel cards on
> debian/unstable with KVM hypervisor. On Broadcom cards (bnx2x module,
> BCM57810 devices), Virtual Functions (VFs) get running, Virtual Machines
> attached to such VFs inherit network connectivity with excellent
> performance.
>
> However, VMs attached to VFs on the Broadcom Physical Functions (PFs)
> behave like they were connected to an ancient hub, not a L2 switch. It
> is as if there was no internal L2 switching on the Broadcom card to
> process VF <-> VF or VF <-> PF communications. As a result, a VM sees
> all inbound/outbound traffic from/to others VMs as well as traffic
> destined to the PF (for instance, the physical ethX has an IP address).
Are you're using the ISC DHCP client, which puts the interface in
promiscuous mode? If the Broadcom NIC supports promiscuous mode on VFs,
that may explain what you're seeing.
> On the other hand, everything works like a charm with Intel cards (ixgbe
> module, 82599EB devices). Traffic between VFs or VF/PF is switched
> internally by the card.
I think these VFs don't support promiscuous mode. Anyway, the ixgbevf
driver silently ignores it.
Ben.
> I found very little literature about SR-IOV on Broadcom devices. I
> wonder if it's a normal behaviour, a misconfiguration on my side or
> perhaps a firmware/driver bug.
>
> Have you seen this issue before ?
>
> ---
> Kernel 3.12.9 (same behaviour with kernels 3.10.x)
> driver: bnx2x
> firmware-version: 7.8.17
> Debian/unstable
> libvirt 1.2.1
> QEMU 1.7.0
> ---
>
> Best regards,
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH] net: clear iflink when moving to a new netns
From: Ben Hutchings @ 2014-02-12 23:18 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, David S. Miller, Eric W. Biederman, Eric Dumazet,
Hannes Frederic Sowa, Cong Wang
In-Reply-To: <1392162690-6647-1-git-send-email-xiyou.wangcong@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 802 bytes --]
On Tue, 2014-02-11 at 15:51 -0800, Cong Wang wrote:
> From: Cong Wang <cwang@twopensource.com>
>
> BZ: https://bugzilla.kernel.org/show_bug.cgi?id=66691
>
> macvlan and vlan both use iflink to identify its lower device,
> however, after such device is moved to the new netns, its iflink
> would become meaningless as ifindex is per netns. So, instead of
> forbid them moving to another netns, just clear this field so that
> it will not be dumped at least.
[...]
And what if it's moved back into the same netns?
I think iflink should be changed to a net_device pointer, so it remains
valid for in-kernel users but rtnetlink can do the netns check before
revealing it to userland.
Ben.
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: Clear local_df only if crossing namespace.
From: Hannes Frederic Sowa @ 2014-02-12 23:35 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: Pravin Shelar, David Miller, netdev, Templin, Fred L,
Steffen Klassert
In-Reply-To: <52FB3FC1.8080603@6wind.com>
On Wed, Feb 12, 2014 at 10:32:49AM +0100, Nicolas Dichtel wrote:
> Le 12/02/2014 05:26, Pravin Shelar a écrit :
> >On Mon, Feb 10, 2014 at 6:11 PM, Hannes Frederic Sowa
> >I am not sure why the caller can not just set skb->local_df before
> >calling iptunnel_xmit() rather than passing extra arg to this
> >function?
> >There are not that many caller of this function.
> The benefit is that it ensures that future callers will think about this
> point
> ;-)
Exactly, I thought about adding skb->local_df = 0 to all the tunnel code but
wanted to force users of the interface to think about the parameter and its
consequences.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH net-next 00/13] Cleanup patches for the SFC driver
From: David Miller @ 2014-02-12 23:42 UTC (permalink / raw)
To: sshah; +Cc: netdev, linux-net-drivers
In-Reply-To: <52FBC3C2.7030103@solarflare.com>
From: Shradha Shah <sshah@solarflare.com>
Date: Wed, 12 Feb 2014 18:56:02 +0000
> This patch set consists of some cleanup and housekeeping
> patches for the sfc driver.
> These patches help to reduce the differences between the in-
> tree and out-of-tree driver.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] intel: Remove unnecessary OOM messages
From: Aaron Brown @ 2014-02-12 23:46 UTC (permalink / raw)
To: Joe Perches; +Cc: Jeff Kirsher, e1000-devel, netdev
In-Reply-To: <1392168397.23721.2.camel@joe-AO722>
On Tue, 2014-02-11 at 17:26 -0800, Joe Perches wrote:
> Don't emit these as there's a generic OOM with a dump_stack()
> on allocation failures.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
Thanks Joe, I have added this to Jeff's queue.
^ permalink raw reply
* Re: RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel
From: Grant Grundler @ 2014-02-12 23:58 UTC (permalink / raw)
To: hayeswang; +Cc: Inki Yoo, netdev, David Miller
In-Reply-To: <6929A44AB95D46C6B919DDD537CDD37B@realtek.com.tw>
On Tue, Feb 11, 2014 at 7:47 PM, hayeswang <hayeswang@realtek.com> wrote:
> It still works for me. The followings are some messages from Fedora 20 with kernel 3.14.rc2.
Perfect - thanks for following up.
...
> # ethtool -i eth0
> driver: r815x
> version: 22-Aug-2005
BTW, can you please update the version number to match adding RTL8153 support?
Makes life easier for anyone maintaining older kernels.
> Is your dangle from Samsung?
It's labeled "Realtek USB 3.0 Gigabit Ethernet" externally. I'm not
sure if we got these from Samsung or directly from RealTek.
What's notable is this device has no link or activity LEDs visible.
Normally I'd expect those near the RJ45 port.
Also no MAC address or serial number or anything to further identify
the devices. just the "rectangular black plastic" enclosure with a
silver sticker carrying the Realtek logo + text.
> I would ask our PM to check if there is any difference between our devices.
> Maybe it is not the driver issue.
I don't think it's a r8152 or r815x driver issue either. It's much
more likely related to chromeos-3.8 USB NET patches not matching 3.14
kernel behaviors.
Please don't pursue further. Unless I have a good reason to debug
chromeos-3.8 kernel, I'd rather not. If I have problems with 3.12 or
later kernels, I'd be more motivated and will pester you again. :)
Thanks!
grant
^ permalink raw reply
* Re: [PATCH net-next 05/14] tipc: remove 'links' list from tipc_bearer struct
From: David Miller @ 2014-02-13 0:00 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, paul.gortmaker, erik.hugne, ying.xue, maloy,
tipc-discussion
In-Reply-To: <1392229874-29675-6-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Wed, 12 Feb 2014 13:31:05 -0500
> @@ -146,12 +146,6 @@ int tipc_link_is_active(struct tipc_link *l_ptr)
>
> /**
> * link_timeout - handle expiration of link timer
> - * @l_ptr: pointer to link
> - *
> - * This routine must not grab "tipc_net_lock" to avoid a potential deadlock conflict
> - * with tipc_link_delete(). (There is no risk that the node will be deleted by
> - * another thread because tipc_link_delete() always cancels the link timer before
> - * tipc_node_delete() is called.)
> */
> static void link_timeout(struct tipc_link *l_ptr)
> {
There is no reason to remove the kerneldoc entry for @l_ptr in this comment,
the argument is still there.
^ permalink raw reply
* Re: xfrm: is pmtu broken with ESP tunneling?
From: Hannes Frederic Sowa @ 2014-02-13 0:01 UTC (permalink / raw)
To: Ortwin Glück; +Cc: linux-kernel, netdev
In-Reply-To: <52FA8618.5030509@odi.ch>
On Tue, Feb 11, 2014 at 09:20:40PM +0100, Ortwin Glück wrote:
> On 02/11/2014 03:32 AM, Hannes Frederic Sowa wrote:
> >>net.ipv4.ip_no_pmtu_disc=1.
> >
> >This setting will shrink the path mtu to min_pmtu when a frag needed icmp
> >is
> >received.
>
> The UDP+ESP encapsulation adds 60 bytes to the original packet size.
>
> ifconfig wla0 shows an mtu of 1500.
>
> The size of the first big packet on the interface:
> net.ipv4.ip_no_pmtu_disc=1: packet length is 1300
> net.ipv4.ip_no_pmtu_disc=0: packet length is 1500
>
> Length is without the ESP wrapper and UDP encapsulation. The packets are so
> big that they can't even leave the wireless interface and never show up on
> the router. So no ICMP packets are received. PMTU can't work with initial
> packets of that size.
>
> dump question: which layer discard these packets? qdisc? why no
> notification to the sender?
Could you try either dropwatch or perf script net_dropmonitor and flood the
network with the problematic packets. From the traces we could see where the
packets get dropped without notification in the kernel.
> When I increase the mtu of the interface to 2000 with ifconfig, then I
> start seeing ICMP fragmentation needed from the next hop, indicating 1500
> as the mtu as response to a 1560 byte UDP[ESP] packet.
>
> The next UDP[ESP] packet is shorter: 1360 bytes. It gets hard to see what's
> going on after that, but the connection is still not working.
>
> So, instead of somehow losing these packets on the way out of the interface
> should the kernel not start with a lower mtu in the first place? Now it
> seems it is trying with the maximum of the interface and expecting to scale
> down with pmtu - which can ever happen.
>
> >Can you send a ip route get <ip> to the problematic target to see how
> >far off the calculated value is?
>
> That command doesn't return anything useful. No hint on the mtu here.
>
> BTW, instead of disabling pmtu, setting mtu explicitly also helps:
> ip route add 10.6.6.0/24 via ${localip} mtu 1300
Strange that the problem disappears if you enable no_pmtu_disc then.
Thanks,
Hannes
^ permalink raw reply
* [PATCH] usbnet: remove generic hard_header_len check
From: Emil Goode @ 2014-02-13 0:03 UTC (permalink / raw)
To: Steve Glendinning, Oliver Neukum, Bjørn Mork,
David S. Miller, Freddy Xin, Eric Dumazet, Ming Lei,
Paul Gortmaker, Jeff Kirsher, Liu Junliang, Octavian Purdila
Cc: linux-usb, netdev, linux-kernel, Emil Goode
This patch removes a generic hard_header_len check from the usbnet
module that is causing dropped packages under certain circumstances
for devices that send rx packets that cross urb boundaries.
One example is the AX88772B which occasionally send rx packets that
cross urb boundaries where the remaining partial packet is sent with
no hardware header. When the buffer with a partial packet is of less
number of octets than the value of hard_header_len the buffer is
discarded by the usbnet module.
With AX88772B this can be reproduced by using ping with a packet
size between 1965-1976.
The bug has been reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=29082
This patch introduces the following changes:
- Removes the generic hard_header_len check in the rx_complete
function in the usbnet module.
- Introduces a ETH_HLEN check for skbs that are not cloned from
within a rx_fixup callback.
- For safety a hard_header_len check is added to each rx_fixup
callback function that could be affected by this change.
These extra checks could possibly be removed by someone
who has the hardware to test.
The changes place full responsibility on the rx_fixup callback
functions that clone skbs to only pass valid skbs to the
usbnet_skb_return function.
Signed-off-by: Emil Goode <emilgoode@gmail.com>
Reported-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
---
An alternative solution is to add the ETH_HLEN check to
usbnet_skb_return() and add short skbs to the skb->done
list to be cleaned up in rx_process().
drivers/net/usb/ax88179_178a.c | 4 ++++
drivers/net/usb/gl620a.c | 4 ++++
drivers/net/usb/mcs7830.c | 5 +++--
drivers/net/usb/net1080.c | 4 ++++
drivers/net/usb/qmi_wwan.c | 8 ++++----
drivers/net/usb/rndis_host.c | 4 ++++
drivers/net/usb/smsc75xx.c | 4 ++++
drivers/net/usb/smsc95xx.c | 4 ++++
drivers/net/usb/sr9800.c | 4 ++++
drivers/net/usb/usbnet.c | 25 ++++++++++---------------
10 files changed, 45 insertions(+), 21 deletions(-)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index d6f64da..955df81 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1118,6 +1118,10 @@ static int ax88179_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
u16 hdr_off;
u32 *pkt_hdr;
+ /* This check is no longer done by usbnet */
+ if (skb->len < dev->net->hard_header_len)
+ return 0;
+
skb_trim(skb, skb->len - 4);
memcpy(&rx_hdr, skb_tail_pointer(skb), 4);
le32_to_cpus(&rx_hdr);
diff --git a/drivers/net/usb/gl620a.c b/drivers/net/usb/gl620a.c
index e4a8a93..1cc24e6 100644
--- a/drivers/net/usb/gl620a.c
+++ b/drivers/net/usb/gl620a.c
@@ -84,6 +84,10 @@ static int genelink_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
u32 size;
u32 count;
+ /* This check is no longer done by usbnet */
+ if (skb->len < dev->net->hard_header_len)
+ return 0;
+
header = (struct gl_header *) skb->data;
// get the packet count of the received skb
diff --git a/drivers/net/usb/mcs7830.c b/drivers/net/usb/mcs7830.c
index a305a7b..82d844a 100644
--- a/drivers/net/usb/mcs7830.c
+++ b/drivers/net/usb/mcs7830.c
@@ -526,8 +526,9 @@ static int mcs7830_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
{
u8 status;
- if (skb->len == 0) {
- dev_err(&dev->udev->dev, "unexpected empty rx frame\n");
+ /* This check is no longer done by usbnet */
+ if (skb->len < dev->net->hard_header_len) {
+ dev_err(&dev->udev->dev, "unexpected tiny rx frame\n");
return 0;
}
diff --git a/drivers/net/usb/net1080.c b/drivers/net/usb/net1080.c
index 0a85d92..4cbdb13 100644
--- a/drivers/net/usb/net1080.c
+++ b/drivers/net/usb/net1080.c
@@ -364,6 +364,10 @@ static int net1080_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
struct nc_trailer *trailer;
u16 hdr_len, packet_len;
+ /* This check is no longer done by usbnet */
+ if (skb->len < dev->net->hard_header_len)
+ return 0;
+
if (!(skb->len & 0x01)) {
netdev_dbg(dev->net, "rx framesize %d range %d..%d mtu %d\n",
skb->len, dev->net->hard_header_len, dev->hard_mtu,
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index ff5c871..b2e2aee 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -80,10 +80,10 @@ static int qmi_wwan_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
{
__be16 proto;
- /* usbnet rx_complete guarantees that skb->len is at least
- * hard_header_len, so we can inspect the dest address without
- * checking skb->len
- */
+ /* This check is no longer done by usbnet */
+ if (skb->len < dev->net->hard_header_len)
+ return 0;
+
switch (skb->data[0] & 0xf0) {
case 0x40:
proto = htons(ETH_P_IP);
diff --git a/drivers/net/usb/rndis_host.c b/drivers/net/usb/rndis_host.c
index a48bc0f..524a47a 100644
--- a/drivers/net/usb/rndis_host.c
+++ b/drivers/net/usb/rndis_host.c
@@ -492,6 +492,10 @@ EXPORT_SYMBOL_GPL(rndis_unbind);
*/
int rndis_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
{
+ /* This check is no longer done by usbnet */
+ if (skb->len < dev->net->hard_header_len)
+ return 0;
+
/* peripheral may have batched packets to us... */
while (likely(skb->len)) {
struct rndis_data_hdr *hdr = (void *)skb->data;
diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index f17b9e0..d9e7892 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -2106,6 +2106,10 @@ static void smsc75xx_rx_csum_offload(struct usbnet *dev, struct sk_buff *skb,
static int smsc75xx_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
{
+ /* This check is no longer done by usbnet */
+ if (skb->len < dev->net->hard_header_len)
+ return 0;
+
while (skb->len > 0) {
u32 rx_cmd_a, rx_cmd_b, align_count, size;
struct sk_buff *ax_skb;
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 8dd54a0..424db65e 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1723,6 +1723,10 @@ static void smsc95xx_rx_csum_offload(struct sk_buff *skb)
static int smsc95xx_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
{
+ /* This check is no longer done by usbnet */
+ if (skb->len < dev->net->hard_header_len)
+ return 0;
+
while (skb->len > 0) {
u32 header, align_count;
struct sk_buff *ax_skb;
diff --git a/drivers/net/usb/sr9800.c b/drivers/net/usb/sr9800.c
index 4175eb9..575be80 100644
--- a/drivers/net/usb/sr9800.c
+++ b/drivers/net/usb/sr9800.c
@@ -63,6 +63,10 @@ static int sr_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
{
int offset = 0;
+ /* This check is no longer done by usbnet */
+ if (skb->len < dev->net->hard_header_len)
+ return 0;
+
while (offset + sizeof(u32) < skb->len) {
struct sk_buff *sr_skb;
u16 size;
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 4671da7..dd10d58 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -542,17 +542,19 @@ static inline void rx_process (struct usbnet *dev, struct sk_buff *skb)
}
// else network stack removes extra byte if we forced a short packet
- if (skb->len) {
- /* all data was already cloned from skb inside the driver */
- if (dev->driver_info->flags & FLAG_MULTI_PACKET)
- dev_kfree_skb_any(skb);
- else
- usbnet_skb_return(dev, skb);
+ /* all data was already cloned from skb inside the driver */
+ if (dev->driver_info->flags & FLAG_MULTI_PACKET)
+ goto done;
+
+ if (skb->len < ETH_HLEN) {
+ dev->net->stats.rx_errors++;
+ dev->net->stats.rx_length_errors++;
+ netif_dbg(dev, rx_err, dev->net, "rx length %d\n", skb->len);
+ } else {
+ usbnet_skb_return(dev, skb);
return;
}
- netif_dbg(dev, rx_err, dev->net, "drop\n");
- dev->net->stats.rx_errors++;
done:
skb_queue_tail(&dev->done, skb);
}
@@ -574,13 +576,6 @@ static void rx_complete (struct urb *urb)
switch (urb_status) {
/* success */
case 0:
- if (skb->len < dev->net->hard_header_len) {
- state = rx_cleanup;
- dev->net->stats.rx_errors++;
- dev->net->stats.rx_length_errors++;
- netif_dbg(dev, rx_err, dev->net,
- "rx length %d\n", skb->len);
- }
break;
/* stalls need manual reset. this is rare ... except that
--
1.7.10.4
^ permalink raw reply related
* RE: [PATCH net,v2] hyperv: Fix the carrier status setting
From: Haiyang Zhang @ 2014-02-13 0:05 UTC (permalink / raw)
To: Jason Wang, davem@davemloft.net, netdev@vger.kernel.org
Cc: driverdev-devel@linuxdriverproject.org, olaf@aepfle.de,
linux-kernel@vger.kernel.org
In-Reply-To: <52F9F293.7080601@redhat.com>
> -----Original Message-----
> From: Jason Wang [mailto:jasowang@redhat.com]
> Sent: Tuesday, February 11, 2014 4:51 AM
> To: Haiyang Zhang; davem@davemloft.net; netdev@vger.kernel.org
> Cc: KY Srinivasan; olaf@aepfle.de; linux-kernel@vger.kernel.org; driverdev-
> devel@linuxdriverproject.org
> Subject: Re: [PATCH net,v2] hyperv: Fix the carrier status setting
>
> On 02/11/2014 02:15 AM, Haiyang Zhang wrote:
> > Without this patch, the "cat /sys/class/net/ethN/operstate" shows
> > "unknown", and "ethtool ethN" shows "Link detected: yes", when VM
> > boots up with or without vNIC connected.
> >
> > This patch fixed the problem.
> >
> > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
> > ---
> > drivers/net/hyperv/netvsc_drv.c | 24 +++++++++++++++---------
> > 1 files changed, 15 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/net/hyperv/netvsc_drv.c
> > b/drivers/net/hyperv/netvsc_drv.c index 7756118..18916f7 100644
> > --- a/drivers/net/hyperv/netvsc_drv.c
> > +++ b/drivers/net/hyperv/netvsc_drv.c
> > @@ -88,8 +88,12 @@ static int netvsc_open(struct net_device *net) {
> > struct net_device_context *net_device_ctx = netdev_priv(net);
> > struct hv_device *device_obj = net_device_ctx->device_ctx;
> > + struct netvsc_device *nvdev;
> > + struct rndis_device *rdev;
> > int ret = 0;
> >
> > + netif_carrier_off(net);
> > +
> > /* Open up the device */
> > ret = rndis_filter_open(device_obj);
> > if (ret != 0) {
> > @@ -99,6 +103,11 @@ static int netvsc_open(struct net_device *net)
> >
> > netif_start_queue(net);
> >
> > + nvdev = hv_get_drvdata(device_obj);
> > + rdev = nvdev->extension;
> > + if (!rdev->link_state)
>
> What if the link status interrupt comes here at this time?
Thank you for pointing this out. I have submitted an updated patch.
- Haiyang
^ permalink raw reply
* Re: [PATCH net 1/3] kref: add kref_sub_return
From: David Miller @ 2014-02-13 0:06 UTC (permalink / raw)
To: gregkh
Cc: virtio-dev, anatol.pomozov, mst, netdev, linux-kernel,
virtualization, qinchuanyu, joern
In-Reply-To: <20140212165630.GA22991@kroah.com>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Wed, 12 Feb 2014 08:56:30 -0800
> On Wed, Feb 12, 2014 at 06:38:21PM +0200, Michael S. Tsirkin wrote:
>> It is sometimes useful to get the value of the reference count after
>> decrement.
>> For example, vhost wants to execute some periodic cleanup operations
>> once number of references drops below a specific value, before it
>> reaches zero (for efficiency).
>
> You should never care about what the value of the kref is, if you are
> using it correctly :)
It isn't being used to determine when to destroy things.
They use it to as a heuristic of when to trigger polling.
Each ubuf attached gets a kref to the higher level virtio_net buffer
holding object, they want to trigger polling when that reference drops
to 1 or lower.
Right now they are reading the atomic refcount directly, which
I think is much worse than this helper.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: do not set "u" bit for temporary addresses
From: Hannes Frederic Sowa @ 2014-02-13 0:11 UTC (permalink / raw)
To: Florent Fourcot; +Cc: netdev
In-Reply-To: <1392203286-17833-1-git-send-email-florent.fourcot@enst-bretagne.fr>
On Wed, Feb 12, 2014 at 12:08:06PM +0100, Florent Fourcot wrote:
> The bit 6 of interface identifier was before the "universal/local bit",
> indicating local significance only. This rule is now obsoleted by the
> RFC 7136, removing all significance of bits in interface identifier.
>
> The new rule is "In all cases, the bits in an IID have no generic
> semantics; in other words, they have opaque values.", so we can remove
> the setting of bit 6, it will improve the entropy of random addresses.
>
> Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Hmm, the RFC only talks about new methods of IID generation. Not sure
if old software depends on that. I actually know about one commercial
available ip management system which does make use of those bits to
classify ipv6 addresses for displaying purposes (that's how I actually
learned about those bits ;) ).
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH 01/10] net: phy: use network device in phy_print_status
From: David Miller @ 2014-02-13 0:13 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev
In-Reply-To: <1392168462-18888-2-git-send-email-f.fainelli@gmail.com>
Series applied, but this patch series had several problems which I want you
absolutely to correct in future submissions.
First of all, when you submit more than one patch at a time, you must
provide a leading "PATCH 00/NN" posting which gives a top-level,
detailed, description of the overall nature of the changes you are
submitting.
It also gives me a single, specific, posting to reply to when I reply
the whole series. Otherwise I have only two options, 1) pick an
arbitrary patch to reply to (which I am doing right now) or 2) reply
to every single patch (which is a serious waste of everyone's time).
Furthermore, some of your patches added empty lines to the end of files.
I corrected this by hand, but please avoid this in the future.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next v2] IPv6: enable bind() to assign an anycast address
From: Hannes Frederic Sowa @ 2014-02-13 0:16 UTC (permalink / raw)
To: Francois-Xavier Le Bail
Cc: NETDEV, David Miller, kuznet, christoph.paasch, eric.dumazet
In-Reply-To: <1392212332-10463-1-git-send-email-fx.lebail@yahoo.com>
Hi!
[added Cc list from old thread]
On Wed, Feb 12, 2014 at 02:38:51PM +0100, Francois-Xavier Le Bail wrote:
> - Use ipv6_chk_acast_addr_src() in inet6_bind().
>
> Signed-off-by: Francois-Xavier Le Bail <fx.lebail@yahoo.com>
I would agree with the change but would like to see some people from the old
thread about this change to agree with it, too.
> ---
> v2: ipv6_chk_acast_addr_src() was previously added.
>
> net/ipv6/af_inet6.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
> index c921d5d..68b81e9 100644
> --- a/net/ipv6/af_inet6.c
> +++ b/net/ipv6/af_inet6.c
> @@ -347,7 +347,9 @@ int inet6_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
> if (!(addr_type & IPV6_ADDR_MULTICAST)) {
> if (!(inet->freebind || inet->transparent) &&
> !ipv6_chk_addr(net, &addr->sin6_addr,
> - dev, 0)) {
> + dev, 0) &&
> + !ipv6_chk_acast_addr_src(net, dev,
> + &addr->sin6_addr)) {
> err = -EADDRNOTAVAIL;
> goto out_unlock;
> }
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net-next 0/9] bnx2x: Enhancements & semantic changes series
From: David Miller @ 2014-02-13 0:16 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, ariele
In-Reply-To: <1392221997-25525-1-git-send-email-yuvalmin@broadcom.com>
From: Yuval Mintz <yuvalmin@broadcom.com>
Date: Wed, 12 Feb 2014 18:19:48 +0200
> This patch series contains several semantic (or mostly semantic) patches,
> as well as adding support for packet aggregations on the receive path
> of windows VMs and updating bnx2x to the new FW recently accepted upstream.
>
> Please consider applying these patches to `net-next'.
>
> (This is a repost as net-next was still closed when this was previously
> sent)
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/14] Xilinx axi ethernet patches
From: David Miller @ 2014-02-13 0:18 UTC (permalink / raw)
To: michal.simek
Cc: netdev, sthokal, devicetree, monstr, John.Linn, anirudh,
linux-kernel, grant.likely, robh+dt, linux-arm-kernel
In-Reply-To: <cover.1392220536.git.michal.simek@xilinx.com>
From: Michal Simek <michal.simek@xilinx.com>
Date: Wed, 12 Feb 2014 16:55:34 +0100
> I have exctracted patches which I have in our
> xilinx git tree which are missing in the mainline.
>
> The first two patches fix compilation error and
> warnings. Then 5 feature patches
> and the rest is OF cleanup and with kernel-doc
> and checkpatch problems.
You should not combine bug fix and feature patches.
Rather, you should submit bug fixes against the 'net' tree. Then when
those bug fixes get applied and propagate to the 'net-next' tree you
can submit the feature patches and cleanups against the 'net-next'
tree.
^ permalink raw reply
* Re: [PATCH 01/10] net: phy: use network device in phy_print_status
From: Florian Fainelli @ 2014-02-13 0:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20140212.191313.1073971139703427607.davem@davemloft.net>
2014-02-12 16:13 GMT-08:00 David Miller <davem@davemloft.net>:
>
> Series applied, but this patch series had several problems which I want you
> absolutely to correct in future submissions.
>
> First of all, when you submit more than one patch at a time, you must
> provide a leading "PATCH 00/NN" posting which gives a top-level,
> detailed, description of the overall nature of the changes you are
> submitting.
Weird, did not you receive this cover-letter:
http://permalink.gmane.org/gmane.linux.network/303496
if not, that probably explains why the threading was all messed up in
your inbox.
>
> It also gives me a single, specific, posting to reply to when I reply
> the whole series. Otherwise I have only two options, 1) pick an
> arbitrary patch to reply to (which I am doing right now) or 2) reply
> to every single patch (which is a serious waste of everyone's time).
>
> Furthermore, some of your patches added empty lines to the end of files.
> I corrected this by hand, but please avoid this in the future.
Thanks!
>
> Thank you.
>
--
Florian
^ permalink raw reply
* Re: [PATCH 01/10] net: phy: use network device in phy_print_status
From: David Miller @ 2014-02-13 0:22 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev
In-Reply-To: <CAGVrzcZQA6g73PmRoN7BJ8qDpUi5avHGrQ03L8cT4_PGqh_ACg@mail.gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 12 Feb 2014 16:20:19 -0800
> 2014-02-12 16:13 GMT-08:00 David Miller <davem@davemloft.net>:
>>
>> Series applied, but this patch series had several problems which I want you
>> absolutely to correct in future submissions.
>>
>> First of all, when you submit more than one patch at a time, you must
>> provide a leading "PATCH 00/NN" posting which gives a top-level,
>> detailed, description of the overall nature of the changes you are
>> submitting.
>
> Weird, did not you receive this cover-letter:
> http://permalink.gmane.org/gmane.linux.network/303496
> if not, that probably explains why the threading was all messed up in
> your inbox.
Weird indeed, I'll watch out for this in the future.
^ permalink raw reply
* Re: [PATCH net-next 00/10] Support for Broadcom GENET driver
From: Florian Fainelli @ 2014-02-13 0:23 UTC (permalink / raw)
To: netdev
Cc: David Miller, Kevin Cernekee, devicetree@vger.kernel.org,
Florian Fainelli
In-Reply-To: <1392178053-3143-1-git-send-email-f.fainelli@gmail.com>
2014-02-11 20:07 GMT-08:00 Florian Fainelli <f.fainelli@gmail.com>:
> Hi all,
>
> This patchset adds support for the Broadcom GENET Gigabit Ethernet MAC
> controller. This controller is found on the Broadcom BCM7xxx Set Top Box
> System-on-a-Chip.
I just found a small bug in the main driver file, and due to my
previous series touching libphy, this will not apply cleanly anymore.
I will wait for some initial feedback before doing a second respin
though.
>
> Florian Fainelli (10):
> net: phy: add "internal" PHY mode
> net: phy: add MoCA PHY type
> net: phy: update port type for MoCA PHYs
> net: phy: add Broadcom BCM7xxx internal PHY driver
> net: bcmgenet: add driver definitions and private structure
> net: bcmgenet: add main driver file
> net: bcmgenet: add MDIO routines
> net: bcmgenet: hook into the build system
> Documentation: add Device tree bindings for Broadcom GENET
> MAINTAINERS: add entry for the Broadcom GENET driver
>
> .../devicetree/bindings/net/broadcom-bcmgenet.txt | 111 +
> MAINTAINERS | 6 +
> drivers/net/ethernet/broadcom/Kconfig | 10 +
> drivers/net/ethernet/broadcom/Makefile | 1 +
> drivers/net/ethernet/broadcom/genet/Makefile | 2 +
> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 2685 ++++++++++++++++++++
> drivers/net/ethernet/broadcom/genet/bcmgenet.h | 631 +++++
> drivers/net/ethernet/broadcom/genet/bcmmii.c | 483 ++++
> drivers/net/phy/Kconfig | 6 +
> drivers/net/phy/Makefile | 1 +
> drivers/net/phy/bcm7xxx.c | 322 +++
> drivers/net/phy/phy.c | 5 +-
> drivers/of/of_net.c | 2 +
> include/linux/brcmphy.h | 9 +
> include/linux/phy.h | 5 +-
> 15 files changed, 4277 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
> create mode 100644 drivers/net/ethernet/broadcom/genet/Makefile
> create mode 100644 drivers/net/ethernet/broadcom/genet/bcmgenet.c
> create mode 100644 drivers/net/ethernet/broadcom/genet/bcmgenet.h
> create mode 100644 drivers/net/ethernet/broadcom/genet/bcmmii.c
> create mode 100644 drivers/net/phy/bcm7xxx.c
>
> --
> 1.8.3.2
>
--
Florian
^ permalink raw reply
* Re: [PATCH] ipv4: arp: process only if ipv4 address configured
From: Hannes Frederic Sowa @ 2014-02-13 0:24 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
In-Reply-To: <1392226067-21736-1-git-send-email-fw@strlen.de>
On Wed, Feb 12, 2014 at 06:27:47PM +0100, Florian Westphal wrote:
> 8030f54499925d073a88c09f ([IPV4] devinet: Register inetdev earlier.)
> changed arp behaviour (2.6.22 onwards).
>
> Before this, inetdev_init() was called only when the first address was
> added to the interface, i.e. arp_process always dropped incoming arp
> packets as __in_dev_get_rcu() returned NULL when no IP address was set
> on the interface.
>
> With >= 2.6.22 we now process arp packets even if no address is assigned.
> It can cause issues if the machine has several interfaces in the same
> segment; requests receive answers from multiple macs.
I actually expect arp answers for ip addresses bound to loopback even from an
interface without ip address, if we strictly conform to the week end host
model in linux.
This is e.g. a common setup for BGP routers, where you assign the IBGP
address to loopback or dummy and thus make it interface independent.
Greetings,
Hannes
^ permalink raw reply
* Re: [Patch net-next v3 0/5] net_sched: act: more cleanup and improvement
From: David Miller @ 2014-02-13 0:24 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, stephen, jhs
In-Reply-To: <1392167255-21744-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 11 Feb 2014 17:07:30 -0800
> v2 -> v3:
> * fix a mis-splitted patch
> * keep hinfo as a pointer in ops
>
> v1 -> v2:
> * Fix a bug noticed by Jamal
> * Drop patches already merged into net-next
> * Add patch 5/5
>
> Patches are cleanup's for the structures of tc actions, except patch 4
> which is an improvement.
>
> See each patch for details.
>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv4: arp: process only if ipv4 address configured
From: David Miller @ 2014-02-13 0:25 UTC (permalink / raw)
To: hannes; +Cc: fw, netdev
In-Reply-To: <20140213002413.GK11150@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Thu, 13 Feb 2014 01:24:13 +0100
> I actually expect arp answers for ip addresses bound to loopback even from an
> interface without ip address, if we strictly conform to the week end host
> model in linux.
Agreed.
^ permalink raw reply
* Re: [PATCH v2] ipx: implement shutdown()
From: David Miller @ 2014-02-13 0:26 UTC (permalink / raw)
To: sd; +Cc: acme, netdev, 00cpxxx
In-Reply-To: <1391901818-13338-1-git-send-email-sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Sun, 9 Feb 2014 00:23:38 +0100
> IPX doesn't implement shutdown, which poses a problem to some users:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=67841
>
> This patch is heavily based on the shutdown implementation for unix
> sockets.
>
> Reported-by: Bruno Jesus <00cpxxx@gmail.com>
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> ---
> v2, without debug messages
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] ipv4: ipconfig.c: add parentheses in an if statement
From: David Miller @ 2014-02-13 0:29 UTC (permalink / raw)
To: fx.lebail; +Cc: netdev
In-Reply-To: <1392047214-21237-1-git-send-email-fx.lebail@yahoo.com>
From: Francois-Xavier Le Bail <fx.lebail@yahoo.com>
Date: Mon, 10 Feb 2014 16:46:54 +0100
> Even if the 'time_before' macro expand with parentheses, the look is bad.
>
> Signed-off-by: Francois-Xavier Le Bail <fx.lebail@yahoo.com>
Applied, 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