* Re: Why are IPv6 host and anycast routes referencing lo device?
From: David Ahern @ 2016-11-08 3:00 UTC (permalink / raw)
To: YOSHIFUJI Hideaki, Hannes Frederic Sowa, netdev@vger.kernel.org
In-Reply-To: <14a4ccfb-11d9-f96b-a741-c8595b81ca45@miraclelinux.com>
On 11/7/16 7:26 PM, YOSHIFUJI Hideaki wrote:
> Once I tried I did not work.
> You could try again to see what happens.
I did and both worked fine in quick POC testing. I'll do more in-depth testing and send a patch. Thanks.
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH] igb: drop field "tail" of struct igb_ring
From: Cao jin @ 2016-11-08 2:50 UTC (permalink / raw)
To: Alexander Duyck
Cc: linux-kernel@vger.kernel.org, Netdev,
Izumi, Taku/泉 拓, intel-wired-lan
In-Reply-To: <CAKgT0UcHutO9kotxN2-MTH=rrB1PjmyMdjyeT4PkYbBXkBquFw@mail.gmail.com>
On 11/08/2016 02:49 AM, Alexander Duyck wrote:
> On Mon, Nov 7, 2016 at 4:44 AM, Cao jin <caoj.fnst@cn.fujitsu.com> wrote:
>> Under certain condition, I find guest will oops on writel() in
>> igb_configure_tx_ring(), because hw->hw_address is NULL. While other
>> register access won't oops kernel because they use wr32/rd32 which have
>> a defense against NULL pointer. The oops message are as following:
>>
>> [ 141.225449] pcieport 0000:00:1c.0: AER: Multiple Uncorrected (Fatal)
>> error received: id=0101
>> [ 141.225523] igb 0000:01:00.1: PCIe Bus Error: severity=Uncorrected
>> (Fatal), type=Unaccessible, id=0101(Unregistered Agent ID)
>> [ 141.299442] igb 0000:01:00.1: broadcast error_detected message
>> [ 141.300539] igb 0000:01:00.0 enp1s0f0: PCIe link lost, device now
>> detached
>> [ 141.351019] igb 0000:01:00.1 enp1s0f1: PCIe link lost, device now
>> detached
>> [ 143.465904] pcieport 0000:00:1c.0: Root Port link has been reset
>> [ 143.465994] igb 0000:01:00.1: broadcast slot_reset message
>> [ 143.466039] igb 0000:01:00.0: enabling device (0000 -> 0002)
>> [ 144.389078] igb 0000:01:00.1: enabling device (0000 -> 0002)
>> [ 145.312078] igb 0000:01:00.1: broadcast resume message
>> [ 145.322211] BUG: unable to handle kernel paging request at
>> 0000000000003818
>> [ 145.361275] IP: [<ffffffffa02fd38d>] igb_configure_tx_ring+0x14d/0x280 [igb]
>> [ 145.438007] Oops: 0002 [#1] SMP
>>
>> On the other hand, commit 238ac817 does some optimization which
>> dropped the field "head". So I think it is time to drop "tail" as well.
>
> There is a bug here, but removing tail isn't the fix.
>
Yes, totally agree with you. The oops issue just drive me find that
"tail" may should be dropped as "head", at least won't oops kernel when
this driver's bug come out.
Couldn't we remove "tail"? Removed "head" while left "tail" untouched
seems weird, and all the other register's access go via rd32/wr32,
except "tail", it also seems weird, isn't it?
>> Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
>> ---
>> drivers/net/ethernet/intel/igb/igb.h | 1 -
>> drivers/net/ethernet/intel/igb/igb_main.c | 16 +++++++++-------
>> 2 files changed, 9 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
>> index d11093d..0df06bc 100644
>> --- a/drivers/net/ethernet/intel/igb/igb.h
>> +++ b/drivers/net/ethernet/intel/igb/igb.h
>> @@ -247,7 +247,6 @@ struct igb_ring {
>> };
>> void *desc; /* descriptor ring memory */
>> unsigned long flags; /* ring specific flags */
>> - void __iomem *tail; /* pointer to ring tail register */
>> dma_addr_t dma; /* phys address of the ring */
>> unsigned int size; /* length of desc. ring in bytes */
>>
>> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
>> index edc9a6a..e177d0e 100644
>> --- a/drivers/net/ethernet/intel/igb/igb_main.c
>> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
>> @@ -3390,9 +3390,8 @@ void igb_configure_tx_ring(struct igb_adapter *adapter,
>> tdba & 0x00000000ffffffffULL);
>> wr32(E1000_TDBAH(reg_idx), tdba >> 32);
>>
>> - ring->tail = hw->hw_addr + E1000_TDT(reg_idx);
>
> This line is where the bug is. This should be adapter->io_addr, not
> hw->hw_addr.
hw->hw_addr could be alterred to NULL(in igb_rd32), this is why writel
oops the kernel, you give a fine solution.
But from the oops message, we can find, register reading returns all
F's, I also have a question want to consult: when igb device is reset,
would reading register(no matter config space or non-PCIe configuration
registers) during reset returns all F's? (I guess this is the core of my
issue)
>
>> wr32(E1000_TDH(reg_idx), 0);
>> - writel(0, ring->tail);
>> + wr32(E1000_TDT(reg_idx), 0);
>>
>> txdctl |= IGB_TX_PTHRESH;
>> txdctl |= IGB_TX_HTHRESH << 8;
>> @@ -3729,9 +3728,8 @@ void igb_configure_rx_ring(struct igb_adapter *adapter,
>> ring->count * sizeof(union e1000_adv_rx_desc));
>>
>> /* initialize head and tail */
>> - ring->tail = hw->hw_addr + E1000_RDT(reg_idx);
>
> Same thing here. It looks like the wrong values where used.
>
>> wr32(E1000_RDH(reg_idx), 0);
>> - writel(0, ring->tail);
>> + wr32(E1000_RDT(reg_idx), 0);
>>
>> /* set descriptor configuration */
>
> Would you prefer to submit the patch for this or should I? Basically
> all you need to do is change the two lines where ring->tail is
> populated so that you use adapter->io_addr instead of hw->hw_addr.
>
> Thanks.
>
> - Alex
>
>
> .
>
--
Yours Sincerely,
Cao jin
^ permalink raw reply
* Re: Why are IPv6 host and anycast routes referencing lo device?
From: YOSHIFUJI Hideaki @ 2016-11-08 2:26 UTC (permalink / raw)
To: David Ahern, Hannes Frederic Sowa, netdev@vger.kernel.org
Cc: hideaki.yoshifuji
In-Reply-To: <db922fb9-2553-7801-d597-0f40999be944@cumulusnetworks.com>
Hi,
David Ahern wrote:
>
> Can anyone explain why host routes and anycast routes for IPv6 are added with the device set to loopback versus the device with the address:
>
> local ::1 dev lo proto none metric 0 pref medium
> local 2000:1:: dev lo proto none metric 0 pref medium
> local 2000:1::3 dev lo proto none metric 0 pref medium
> local 2100:2:: dev lo proto none metric 0 pref medium
> local 2100:2::3 dev lo proto none metric 0 pref medium
>
>
> This behavior differs from IPv4 where host routes use the device with the address:
>
> broadcast 10.1.1.0 dev eth0 proto kernel scope link src 10.1.1.3
> local 10.1.1.3 dev eth0 proto kernel scope host src 10.1.1.3
> broadcast 10.1.1.255 dev eth0 proto kernel scope link src 10.1.1.3
> broadcast 10.100.2.0 dev eth2 proto kernel scope link src 10.100.2.3
> local 10.100.2.3 dev eth2 proto kernel scope host src 10.100.2.3
> broadcast 10.100.2.255 dev eth2 proto kernel scope link src 10.100.2.3
>
> The use of loopback pre-dates the git history, so wondering if someone recalls the reason why. We would like to change that to make it consistent with IPv4 - with a sysctl to maintain backwards compatibility.
Once I tried I did not work.
You could try again to see what happens.
--yoshfuji
>
> Thanks,
> David
>
--
Hideaki Yoshifuji <hideaki.yoshifuji@miraclelinux.com>
Technical Division, MIRACLE LINUX CORPORATION
^ permalink raw reply
* linux-next: manual merge of the rdma-leon-test tree with the net-next tree
From: Stephen Rothwell @ 2016-11-08 2:06 UTC (permalink / raw)
To: Leon Romanovsky, David Miller, Networking
Cc: linux-next, linux-kernel, David Ahern
Hi Leon,
Today's linux-next merge of the rdma-leon-test tree got a conflict in:
drivers/infiniband/core/roce_gid_mgmt.c
between commit:
453d39329ad0 ("IB/core: Flip to the new dev walk API")
from the net-next tree and commit:
e4b4d6b5d8c2 ("IB/core: Remove debug prints after allocation failure")
from the rdma-leon-test tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/infiniband/core/roce_gid_mgmt.c
index 3a64a0881882,c86ddcea7675..000000000000
--- a/drivers/infiniband/core/roce_gid_mgmt.c
+++ b/drivers/infiniband/core/roce_gid_mgmt.c
@@@ -437,28 -434,6 +434,26 @@@ static void callback_for_addr_gid_devic
&parsed->gid_attr);
}
+struct upper_list {
+ struct list_head list;
+ struct net_device *upper;
+};
+
+static int netdev_upper_walk(struct net_device *upper, void *data)
+{
+ struct upper_list *entry = kmalloc(sizeof(*entry), GFP_ATOMIC);
+ struct list_head *upper_list = data;
+
- if (!entry) {
- pr_info("roce_gid_mgmt: couldn't allocate entry to delete ndev\n");
++ if (!entry)
+ return 0;
- }
+
+ list_add_tail(&entry->list, upper_list);
+ dev_hold(upper);
+ entry->upper = upper;
+
+ return 0;
+}
+
static void handle_netdev_upper(struct ib_device *ib_dev, u8 port,
void *cookie,
void (*handle_netdev)(struct ib_device *ib_dev,
^ permalink raw reply
* Re: [lkp] [net] af1fee9821: BUG:spinlock_trylock_failure_on_UP_on_CPU
From: Ye Xiaolong @ 2016-11-08 2:01 UTC (permalink / raw)
To: Allan W. Nielsen
Cc: Andrew Lunn, Raju Lakkaraju, David S. Miller, LKML, netdev, lkp
In-Reply-To: <20161107132714.GA10669@microsemi.com>
On 11/07, Allan W. Nielsen wrote:
>Hi,
>
>I tried to get this "lkp" up and running, but I had some troubles gettting
>these scripts to work.
Hi, Allan
Could you tell us what troubles you have met when trying the "lkp qemu"
tool, it would be better if you could paste some log so we can help to
improve it.
Thanks,
Xiaolong
>
>But it seems like it can be reproduced using th eprovided config file, and qemu.
^ permalink raw reply
* Re: [net PATCH] fib_trie: Correct /proc/net/route off by one error
From: David Miller @ 2016-11-08 1:41 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev, alexander.duyck, apw, jbaron
In-Reply-To: <20161104191157.13974.70665.stgit@ahduyck-blue-test.jf.intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Fri, 04 Nov 2016 15:11:57 -0400
> The display of /proc/net/route has had a couple issues due to the fact that
> when I originally rewrote most of fib_trie I made it so that the iterator
> was tracking the next value to use instead of the current.
>
> In addition it had an off by 1 error where I was tracking the first piece
> of data as position 0, even though in reality that belonged to the
> SEQ_START_TOKEN.
>
> This patch updates the code so the iterator tracks the last reported
> position and key instead of the next expected position and key. In
> addition it shifts things so that all of the leaves start at 1 instead of
> trying to report leaves starting with offset 0 as being valid. With these
> two issues addressed this should resolve any off by one errors that were
> present in the display of /proc/net/route.
>
> Fixes: 25b97c016b26 ("ipv4: off-by-one in continuation handling in /proc/net/route")
> Cc: Andy Whitcroft <apw@canonical.com>
> Reported-by: Jason Baron <jbaron@akamai.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] Documentation: networking: dsa: Update tagging protocols
From: David Miller @ 2016-11-08 1:39 UTC (permalink / raw)
To: architekt
Cc: corbet, vivien.didelot, f.fainelli, andrew, standby24x7,
linux-doc, linux-kernel, netdev
In-Reply-To: <1478261774-14265-1-git-send-email-architekt@coding4coffee.org>
From: Fabian Mewes <architekt@coding4coffee.org>
Date: Fri, 4 Nov 2016 13:16:14 +0100
> Add Qualcomm QCA tagging introduced in cafdc45c9 to the
> list of supported protocols.
>
> Signed-off-by: Fabian Mewes <architekt@coding4coffee.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v3] cadence: Add LSO support.
From: David Miller @ 2016-11-08 1:38 UTC (permalink / raw)
To: rafalo; +Cc: nicolas.ferre, netdev, linux-kernel
In-Reply-To: <1478259618-23474-1-git-send-email-rafalo@cadence.com>
From: Rafal Ozieblo <rafalo@cadence.com>
Date: Fri, 4 Nov 2016 11:40:18 +0000
> + if (IPPROTO_UDP == (((struct iphdr *)skb_network_header(skb))->protocol))
This is simply "ip_hdr(skb)->protocol", please use it everywhere you
have this ugly cast thing in this change.
Thanks.
^ permalink raw reply
* Re: [PATCH] virtio-net: drop legacy features in virtio 1 mode
From: David Miller @ 2016-11-08 1:36 UTC (permalink / raw)
To: mst; +Cc: linux-kernel, stable, jasowang, virtualization, netdev
In-Reply-To: <1478256865-29003-1-git-send-email-mst@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Fri, 4 Nov 2016 12:55:36 +0200
> Virtio 1.0 spec says VIRTIO_F_ANY_LAYOUT and VIRTIO_NET_F_GSO are
> legacy-only feature bits. Do not negotiate them in virtio 1 mode. Note
> this is a spec violation so we need to backport it to stable/downstream
> kernels.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 1/1] driver: macvlan: Destroy new macvlan port if macvlan_common_newlink failed.
From: David Miller @ 2016-11-08 1:33 UTC (permalink / raw)
To: fgao; +Cc: kaber, netdev, gfree.wind
In-Reply-To: <1478226529-26766-1-git-send-email-fgao@ikuai8.com>
From: fgao@ikuai8.com
Date: Fri, 4 Nov 2016 10:28:49 +0800
> From: Gao Feng <fgao@ikuai8.com>
>
> When there is no existing macvlan port in lowdev, one new macvlan port
> would be created. But it doesn't be destoried when something failed later.
> It casues some memleak.
>
> Now add one flag to indicate if new macvlan port is created.
>
> Signed-off-by: Gao Feng <fgao@ikuai8.com>
You need to be more patient, it sometimes take several days before
your get patch reviewed or applied. Sometimes nobody reviews a change
for some time because it is obscure or everyone is busy.
All patches are tracked in patchwork, so it is never an issue of a
change getting "lost". Therefore, it never makes sense to ping the
list again and ask if a change is "ok".
Personally, when people ping like that, it makes me want to review
that patch _less_ not more. So please do not do it.
Thank you.
^ permalink raw reply
* Re: [PATCH] net: icmp6_send should use dst dev to determine L3 domain
From: David Miller @ 2016-11-08 1:31 UTC (permalink / raw)
To: dsa; +Cc: netdev
In-Reply-To: <1478215046-18806-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Thu, 3 Nov 2016 16:17:26 -0700
> icmp6_send is called in response to some event. The skb may not have
> the device set (skb->dev is NULL), but it is expected to have a dst set.
> Update icmp6_send to use the dst on the skb to determine L3 domain.
>
> Fixes: ca254490c8dfd ("net: Add VRF support to IPv6 stack")
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Applied and queued up for -stable, thanks David.
^ permalink raw reply
* Re: [PATCH net-next] sock: do not set sk_err in sock_dequeue_err_skb
From: David Miller @ 2016-11-08 1:29 UTC (permalink / raw)
To: soheil.kdev; +Cc: netdev, edumazet, willemb, ncardwell, soheil
In-Reply-To: <1478211867-24569-1-git-send-email-soheil.kdev@gmail.com>
From: Soheil Hassas Yeganeh <soheil.kdev@gmail.com>
Date: Thu, 3 Nov 2016 18:24:27 -0400
> From: Soheil Hassas Yeganeh <soheil@google.com>
>
> Do not set sk_err when dequeuing errors from the error queue.
> Doing so results in:
> a) Bugs: By overwriting existing sk_err values, it possibly
> hides legitimate errors. It is also incorrect when local
> errors are queued with ip_local_error. That happens in the
> context of a system call, which already returns the error
> code.
> b) Inconsistent behavior: When there are pending errors on
> the error queue, sk_err is sometimes 0 (e.g., for
> the first timestamp on the error queue) and sometimes
> set to an error code (after dequeuing the first
> timestamp).
> c) Suboptimality: Setting sk_err to ENOMSG on simple
> TX timestamps can abort parallel reads and writes.
>
> Removing this line doesn't break userspace. This is because
> userspace code cannot rely on sk_err for detecting whether
> there is something on the error queue. Except for ICMP messages
> received for UDP and RAW, sk_err is not set at enqueue time,
> and as a result sk_err can be 0 while there are plenty of
> errors on the error queue.
>
> For ICMP packets in UDP and RAW, sk_err is set when they are
> enqueued on the error queue, but that does not result in aborting
> reads and writes. For such cases, sk_err is only readable via
> getsockopt(SO_ERROR) which will reset the value of sk_err on
> its own. More importantly, prior to this patch,
> recvmsg(MSG_ERRQUEUE) has a race on setting sk_err (i.e.,
> sk_err is set by sock_dequeue_err_skb without atomic ops or
> locks) which can store 0 in sk_err even when we have ICMP
> messages pending. Removing this line from sock_dequeue_err_skb
> eliminates that race.
>
> Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
Ok, applied.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2016-11-08 1:25 UTC (permalink / raw)
To: David Miller, Networking
Cc: linux-next, linux-kernel, WANG Cong, Johannes Berg
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/netlink/genetlink.c
between commit:
00ffc1ba02d8 ("genetlink: fix a memory leak on error path")
from the net tree and commit:
2ae0f17df1cd ("genetlink: use idr to track families")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/netlink/genetlink.c
index 49c28e8ef01b,bbd3bff885a1..000000000000
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@@ -402,11 -360,17 +360,17 @@@ int genl_register_family(struct genl_fa
} else
family->attrbuf = NULL;
+ family->id = idr_alloc(&genl_fam_idr, family,
+ start, end + 1, GFP_KERNEL);
+ if (family->id < 0) {
+ err = family->id;
- goto errout_locked;
++ goto errout_free;
+ }
+
err = genl_validate_assign_mc_groups(family);
if (err)
- goto errout_free;
+ goto errout_remove;
- list_add_tail(&family->family_list, genl_family_chain(family->id));
genl_unlock_all();
/* send all events */
@@@ -417,14 -381,13 +381,15 @@@
return 0;
+ errout_remove:
+ idr_remove(&genl_fam_idr, family->id);
+errout_free:
+ kfree(family->attrbuf);
errout_locked:
genl_unlock_all();
- errout:
return err;
}
- EXPORT_SYMBOL(__genl_register_family);
+ EXPORT_SYMBOL(genl_register_family);
/**
* genl_unregister_family - unregister generic netlink family
^ permalink raw reply
* Re: [PATCH] vxlan: hide unused local variable
From: David Miller @ 2016-11-08 1:18 UTC (permalink / raw)
To: pshelar; +Cc: arnd, jbenc, hannes, aduyck, netdev
In-Reply-To: <CAOrHB_AU1vEhff=3CsZTxRbd5z2ixEAV3VtAHDohs3LFXP2snA@mail.gmail.com>
From: Pravin Shelar <pshelar@ovn.org>
Date: Mon, 7 Nov 2016 16:25:54 -0800
> On Mon, Nov 7, 2016 at 2:21 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Monday, November 7, 2016 2:16:30 PM CET Pravin Shelar wrote:
>>> On Monday, November 7, 2016, Arnd Bergmann <arnd@arndb.de> wrote:
>>>
>>> > A bugfix introduced a harmless warning in v4.9-rc4:
>>> >
>>> > drivers/net/vxlan.c: In function 'vxlan_group_used':
>>> > drivers/net/vxlan.c:947:21: error: unused variable 'sock6'
>>> > [-Werror=unused-variable]
>>> >
>>> > This hides the variable inside of the same #ifdef that is
>>> > around its user. The extraneous initialization is removed
>>> > at the same time, it was accidentally introduced in the
>>> > same commit.
>>> >
>>> > Fixes: c6fcc4fc5f8b ("vxlan: avoid using stale vxlan socket.")
>>> > Signed-off-by: Arnd Bergmann <arnd@arndb.de <javascript:;>>
>>> > ---
>>>
>>>
>>> I have already submitted patch to fix this issue.
>>>
>>> https://patchwork.ozlabs.org/patch/691588/
>>
>> You have tagged those seven patches for net-next which seems
>> appropriate, but as I wrote above the commit that introduced
>> it was merged between -rc3 and -rc4, so I think we still need a
>> fix for v4.9, right?
>>
>
> This is not actual bug, So I am not sure if we need the fix for net branch.
Really ugly warnings like this really need to be fixed in 'net'.
^ permalink raw reply
* RE: [PATCH] igb/e1000: correct register comments
From: Brown, Aaron F @ 2016-11-08 1:17 UTC (permalink / raw)
To: Cao jin, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Cc: intel-wired-lan@lists.osuosl.org, Kirsher, Jeffrey T
In-Reply-To: <1478071215-5122-1-git-send-email-caoj.fnst@cn.fujitsu.com>
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Cao jin
> Sent: Wednesday, November 2, 2016 12:20 AM
> To: linux-kernel@vger.kernel.org; netdev@vger.kernel.org
> Cc: intel-wired-lan@lists.osuosl.org; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>
> Subject: [PATCH] igb/e1000: correct register comments
>
> Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
> ---
> drivers/net/ethernet/intel/igb/e1000_regs.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* Re: [net-next PATCH 0/3] qdisc and tx_queue_len cleanups for IFF_NO_QUEUE devices
From: David Miller @ 2016-11-08 1:16 UTC (permalink / raw)
To: brouer; +Cc: netdev, phil, robert, jhs
In-Reply-To: <20161103135534.28737.37657.stgit@firesoul>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Thu, 03 Nov 2016 14:55:56 +0100
> This patchset is a cleanup for IFF_NO_QUEUE devices. It will
> hopefully help userspace get a more consistent behavior when attaching
> qdisc to such virtual devices.
Series applied, thanks Jesper.
^ permalink raw reply
* Re: [PATCH] igmp: Make igmp group member RFC 3376 compliant
From: David Miller @ 2016-11-08 1:13 UTC (permalink / raw)
To: mtesar; +Cc: kuznet, jmorris, kaber, netdev
In-Reply-To: <20161103093834.GA31875@sparky-lenivo.brq.redhat.com>
From: Michal Tesar <mtesar@redhat.com>
Date: Thu, 3 Nov 2016 10:38:34 +0100
> 2. If the received Query is a General Query, the interface timer is
> used to schedule a response to the General Query after the
> selected delay. Any previously pending response to a General
> Query is canceled.
> --8<--
>
> Currently the timer is rearmed with new random expiration time for
> every incoming query regardless of possibly already pending report.
> Which is not aligned with the above RFE.
I don't read it that way. #2 says if this is a general query then any
pending response to a general query is cancelled. And that's
effectively what the code is doing right now.
^ permalink raw reply
* Why are IPv6 host and anycast routes referencing lo device?
From: David Ahern @ 2016-11-08 1:08 UTC (permalink / raw)
To: Hannes Frederic Sowa, YOSHIFUJI Hideaki, netdev@vger.kernel.org
Can anyone explain why host routes and anycast routes for IPv6 are added with the device set to loopback versus the device with the address:
local ::1 dev lo proto none metric 0 pref medium
local 2000:1:: dev lo proto none metric 0 pref medium
local 2000:1::3 dev lo proto none metric 0 pref medium
local 2100:2:: dev lo proto none metric 0 pref medium
local 2100:2::3 dev lo proto none metric 0 pref medium
This behavior differs from IPv4 where host routes use the device with the address:
broadcast 10.1.1.0 dev eth0 proto kernel scope link src 10.1.1.3
local 10.1.1.3 dev eth0 proto kernel scope host src 10.1.1.3
broadcast 10.1.1.255 dev eth0 proto kernel scope link src 10.1.1.3
broadcast 10.100.2.0 dev eth2 proto kernel scope link src 10.100.2.3
local 10.100.2.3 dev eth2 proto kernel scope host src 10.100.2.3
broadcast 10.100.2.255 dev eth2 proto kernel scope link src 10.100.2.3
The use of loopback pre-dates the git history, so wondering if someone recalls the reason why. We would like to change that to make it consistent with IPv4 - with a sysctl to maintain backwards compatibility.
Thanks,
David
^ permalink raw reply
* Re: [PATCH] vxlan: hide unused local variable
From: Pravin Shelar @ 2016-11-08 0:25 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, Jiri Benc, Hannes Frederic Sowa, Alexander Duyck,
netdev@vger.kernel.org
In-Reply-To: <2394498.yAioIp78MI@wuerfel>
On Mon, Nov 7, 2016 at 2:21 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, November 7, 2016 2:16:30 PM CET Pravin Shelar wrote:
>> On Monday, November 7, 2016, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> > A bugfix introduced a harmless warning in v4.9-rc4:
>> >
>> > drivers/net/vxlan.c: In function 'vxlan_group_used':
>> > drivers/net/vxlan.c:947:21: error: unused variable 'sock6'
>> > [-Werror=unused-variable]
>> >
>> > This hides the variable inside of the same #ifdef that is
>> > around its user. The extraneous initialization is removed
>> > at the same time, it was accidentally introduced in the
>> > same commit.
>> >
>> > Fixes: c6fcc4fc5f8b ("vxlan: avoid using stale vxlan socket.")
>> > Signed-off-by: Arnd Bergmann <arnd@arndb.de <javascript:;>>
>> > ---
>>
>>
>> I have already submitted patch to fix this issue.
>>
>> https://patchwork.ozlabs.org/patch/691588/
>
> You have tagged those seven patches for net-next which seems
> appropriate, but as I wrote above the commit that introduced
> it was merged between -rc3 and -rc4, so I think we still need a
> fix for v4.9, right?
>
This is not actual bug, So I am not sure if we need the fix for net branch.
^ permalink raw reply
* RE: [PATCH] igb: Workaround for igb i210 firmware issue.
From: Brown, Aaron F @ 2016-11-07 23:55 UTC (permalink / raw)
To: Chris J Arges, jh@henneberg-systemdesign.com
Cc: intel-wired-lan@lists.osuosl.org, Kirsher, Jeffrey T,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1478096032-22119-1-git-send-email-christopherarges@gmail.com>
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Chris J Arges
> Sent: Wednesday, November 2, 2016 7:14 AM
> To: jh@henneberg-systemdesign.com
> Cc: intel-wired-lan@lists.osuosl.org; Chris J Arges
> <christopherarges@gmail.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [PATCH] igb: Workaround for igb i210 firmware issue.
>
> Sometimes firmware may not properly initialize I347AT4_PAGE_SELECT
> causing
> the probe of an igb i210 NIC to fail. This patch adds an addition zeroing of
> this register during igb_get_phy_id to workaround this issue.
>
> Thanks for Jochen Henneberg for the idea and original patch.
>
> Signed-off-by: Chris J Arges <christopherarges@gmail.com>
> ---
> drivers/net/ethernet/intel/igb/e1000_phy.c | 4 ++++
> 1 file changed, 4 insertions(+)
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
^ permalink raw reply
* Re: [PATCH v3 2/4] kconfig: regenerate *.c_shipped files after previous changes
From: Josh Triplett @ 2016-11-07 23:12 UTC (permalink / raw)
To: Nicolas Pitre
Cc: John Stultz, Michal Marek, Richard Cochran, Paul Bolle,
Thomas Gleixner, Edward Cree, netdev, linux-kbuild, linux-kernel
In-Reply-To: <alpine.LFD.2.20.1611071733010.14694@knanqh.ubzr>
On Mon, Nov 07, 2016 at 05:41:38PM -0500, Nicolas Pitre wrote:
> On Mon, 7 Nov 2016, Josh Triplett wrote:
>
> > [snipping large patch]
> >
> > One suggestion that might make this patch easier to review: you might
> > consider first regenerating the unchanged parser with Bison 3.0.4, then
> > regenerating it again after the "imply" change. I think that'd
> > eliminate quite a lot of noise in this patch.
>
> I tried that. This made two large patches instead of just one, both
> equally obscure.
>
> So this patch stands on its own, containing changes that are
> mechanically generated and therefore shouldn't require manual review.
Fair enough. I hadn't expected that the changes from "imply" would still
be huge.
^ permalink raw reply
* Re: [PATCH net] Fixes: 5943634fc559 ("ipv4: Maintain redirect and PMTU info in struct rtable again.")
From: Stephen Suryaputra Lin @ 2016-11-07 23:05 UTC (permalink / raw)
To: netdev
In-Reply-To: <20161107.112016.598403889913912857.davem@davemloft.net>
I did the temporary clearing/restoring rt_gateway following the deleted
function check_peer_redir(). But, looking again at the function the
assigning of peer->redirect_learned.a4 to rt_gateway can be permanent
because restoring to the old_gw only happens on errors.
I have updated the patch to use __ipv4_neigh_lookup().
Thank you.
On Mon, Nov 07, 2016 at 11:20:16AM -0500, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 07 Nov 2016 08:08:52 -0800
>
> > In any case, rt is a shared object at that time, so even temporarily
> > clearing/restoring rt_gateway seems wrong to me.
> >
> > I would rather call __ipv4_neigh_lookup(dst->dev, new_gw) directly at
> > this point.
>
> Agreed.
^ permalink raw reply
* Re: net/l2tp: use-after-free write in l2tp_ip6_close
From: Cong Wang @ 2016-11-07 23:02 UTC (permalink / raw)
To: Andrey Konovalov
Cc: David S. Miller, Eric Dumazet, Willem de Bruijn,
Hannes Frederic Sowa, Soheil Hassas Yeganeh, Shmulik Ladkani,
Wei Wang, Haishuang Yan, netdev, LKML, Dmitry Vyukov,
Kostya Serebryany, Alexander Potapenko, syzkaller
In-Reply-To: <CAAeHK+wThP9rwA7ecbpTPLaj7BR6+qwTy_N=Zh3Jf+AsO_Njbw@mail.gmail.com>
On Mon, Nov 7, 2016 at 2:35 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> Hi,
>
> I've got the following error report while running the syzkaller fuzzer:
>
> ==================================================================
> BUG: KASAN: use-after-free in l2tp_ip6_close+0x239/0x2a0 at addr
> ffff8800677276d8
> Write of size 8 by task a.out/8668
> CPU: 0 PID: 8668 Comm: a.out Not tainted 4.9.0-rc4+ #354
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffff8800694d7b00 ffffffff81b46a64 ffff88006adb5780 ffff8800677276c0
> ffff880067727c68 ffff8800677276c0 ffff8800694d7b28 ffffffff8150a86c
> ffff8800694d7bb8 ffff88006adb5780 ffff8800e77276d8 ffff8800694d7ba8
> Call Trace:
> [< inline >] __dump_stack lib/dump_stack.c:15
> [<ffffffff81b46a64>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
> [<ffffffff8150a86c>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156
> [< inline >] print_address_description mm/kasan/report.c:194
> [<ffffffff8150ab07>] kasan_report_error+0x1f7/0x4d0 mm/kasan/report.c:283
> [< inline >] kasan_report mm/kasan/report.c:303
> [<ffffffff8150b01e>] __asan_report_store8_noabort+0x3e/0x40
> mm/kasan/report.c:329
> [< inline >] __write_once_size ./include/linux/compiler.h:272
> [< inline >] __hlist_del ./include/linux/list.h:622
> [< inline >] hlist_del_init ./include/linux/list.h:637
> [<ffffffff83825f49>] l2tp_ip6_close+0x239/0x2a0 net/l2tp/l2tp_ip6.c:239
> [<ffffffff8316b31f>] inet_release+0xef/0x1c0 net/ipv4/af_inet.c:415
> [<ffffffff832cd4d0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
> [<ffffffff82b6d89e>] sock_release+0x8e/0x1d0 net/socket.c:570
> [<ffffffff82b6d9f6>] sock_close+0x16/0x20 net/socket.c:1017
> [<ffffffff81524bdd>] __fput+0x29d/0x720 fs/file_table.c:208
> [<ffffffff815250e5>] ____fput+0x15/0x20 fs/file_table.c:244
> [<ffffffff81172928>] task_work_run+0xf8/0x170 kernel/task_work.c:116
> [< inline >] exit_task_work ./include/linux/task_work.h:21
> [<ffffffff8111bda3>] do_exit+0x883/0x2ac0 kernel/exit.c:828
> [<ffffffff8112234e>] do_group_exit+0x10e/0x340 kernel/exit.c:931
> [< inline >] SYSC_exit_group kernel/exit.c:942
> [<ffffffff8112259d>] SyS_exit_group+0x1d/0x20 kernel/exit.c:940
> [<ffffffff83fc1501>] entry_SYSCALL_64_fastpath+0x1f/0xc2
> arch/x86/entry/entry_64.S:209
I guess we need to lock the sock for l2tp_ip6_disconnect() too.
diff --git a/net/l2tp/l2tp_ip6.c b/net/l2tp/l2tp_ip6.c
index ad3468c..ea2ae66 100644
--- a/net/l2tp/l2tp_ip6.c
+++ b/net/l2tp/l2tp_ip6.c
@@ -410,7 +410,7 @@ static int l2tp_ip6_disconnect(struct sock *sk, int flags)
if (sock_flag(sk, SOCK_ZAPPED))
return 0;
- return __udp_disconnect(sk, flags);
+ return udp_disconnect(sk, flags);
}
static int l2tp_ip6_getname(struct socket *sock, struct sockaddr *uaddr,
^ permalink raw reply related
* [PATCH net,v2] Fixes: 5943634fc559 ("ipv4: Maintain redirect and PMTU info in struct rtable again.")
From: Stephen Suryaputra Lin @ 2016-11-07 22:48 UTC (permalink / raw)
To: netdev; +Cc: Stephen Suryaputra Lin
ICMP redirects behavior is different after the commit above. An email
requesting the explanation on why the behavior needs to be different
was sent earlier to netdev (https://patchwork.ozlabs.org/patch/687728/).
Since there isn't a reply yet, I decided to prepare this formal patch.
In v2.6 kernel, it used to be that ip_rt_redirect() calls
arp_bind_neighbour() which returns 0 and then the state of the neigh for
the new_gw is checked. If the state isn't valid then the redirected
route is deleted. This behavior is maintained up to v3.5.7 by
check_peer_redirect() because rt->rt_gateway is assigned to
peer->redirect_learned.a4 before calling ipv4_neigh_lookup().
After the commit, ipv4_neigh_lookup() is performed without the
rt_gateway assigned to the new_gw. In the case when rt_gateway (old_gw)
isn't zero, the function uses it as the key. The neigh is most likely valid
since the old_gw is the one that sends the ICMP redirect message. Then the
new_gw is assigned to fib_nh_exception. The problem is: the new_gw ARP may
never gets resolved and the traffic is blackholed.
Changes from v1:
- use __ipv4_neigh_lookup instead (per Eric Dumazet).
Signed-off-by: Stephen Suryaputra Lin <ssurya@ieee.org>
---
net/ipv4/route.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 62d4d90c1389..2a57566e6e91 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -753,7 +753,9 @@ static void __ip_do_redirect(struct rtable *rt, struct sk_buff *skb, struct flow
goto reject_redirect;
}
- n = ipv4_neigh_lookup(&rt->dst, NULL, &new_gw);
+ n = __ipv4_neigh_lookup(rt->dst.dev, new_gw);
+ if (!n)
+ n = neigh_create(&arp_tbl, &new_gw, rt->dst.dev);
if (!IS_ERR(n)) {
if (!(n->nud_state & NUD_VALID)) {
neigh_event_send(n, NULL);
--
2.7.4
^ permalink raw reply related
* [PATCH v4] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.
From: Chris Roth @ 2016-11-07 22:44 UTC (permalink / raw)
To: linux-usb, netdev, linux-kernel; +Cc: Allan Chou, Artjom Simon
From: Allan Chou <allan@asix.com.tw>
Add support for Cypress GX3 SuperSpeed to Gigabit Ethernet
Bridge Controller (Vendor=04b4 ProdID=3610).
Patch verified on x64 linux kernel 4.7.4, 4.8.6, 4.9-rc4 systems
with the Kensington SD4600P USB-C Universal Dock with Power,
which uses the Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge
Controller.
A similar patch was signed-off and tested-by Allan Chou
<allan@asix.com.tw> on 2015-12-01.
Allan verified his similar patch on x86 Linux kernel 4.1.6 system
with Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge Controller.
Tested-by: Allan Chou <allan@asix.com.tw>
Tested-by: Chris Roth <chris.roth@usask.ca>
Tested-by: Artjom Simon <artjom.simon@gmail.com>
Signed-off-by: Allan Chou <allan@asix.com.tw>
Signed-off-by: Chris Roth <chris.roth@usask.ca>
---
drivers/net/usb/ax88179_178a.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index e6338c1..8a6675d 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1656,6 +1656,19 @@ static const struct driver_info ax88178a_info = {
.tx_fixup = ax88179_tx_fixup,
};
+static const struct driver_info cypress_GX3_info = {
+ .description = "Cypress GX3 SuperSpeed to Gigabit Ethernet Controller",
+ .bind = ax88179_bind,
+ .unbind = ax88179_unbind,
+ .status = ax88179_status,
+ .link_reset = ax88179_link_reset,
+ .reset = ax88179_reset,
+ .stop = ax88179_stop,
+ .flags = FLAG_ETHER | FLAG_FRAMING_AX,
+ .rx_fixup = ax88179_rx_fixup,
+ .tx_fixup = ax88179_tx_fixup,
+};
+
static const struct driver_info dlink_dub1312_info = {
.description = "D-Link DUB-1312 USB 3.0 to Gigabit Ethernet Adapter",
.bind = ax88179_bind,
@@ -1718,6 +1731,10 @@ static const struct usb_device_id products[] = {
, USB_DEVICE(0x0b95, 0x178a),
.driver_info = (unsigned long)&ax88178a_info,
}, {
+ /* Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge Controller */
+ USB_DEVICE(0x04b4, 0x3610),
+ .driver_info = (unsigned long)&cypress_GX3_info,
+}, {
/* D-Link DUB-1312 USB 3.0 to Gigabit Ethernet Adapter */
USB_DEVICE(0x2001, 0x4a00),
.driver_info = (unsigned long)&dlink_dub1312_info,
--
2.7.4
^ permalink raw reply related
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