* Re: [PATCH net-next 4/6] net: dsa: Don't program the VLAN as pvid on the upstream port
From: Florian Fainelli @ 2019-08-20 3:15 UTC (permalink / raw)
To: Vladimir Oltean, vivien.didelot, andrew, idosch, roopa, nikolay,
davem
Cc: netdev
In-Reply-To: <20190820000002.9776-5-olteanv@gmail.com>
On 8/19/2019 5:00 PM, Vladimir Oltean wrote:
> Commit b2f81d304cee ("net: dsa: add CPU and DSA ports as VLAN members")
> programs the VLAN from the bridge into the specified port as well as the
> upstream port, with the same set of flags.
>
> Consider the typical case of installing pvid 1 on user port 1, pvid 2 on
> user port 2, etc. The upstream port would end up having a pvid equal to
> the last user port whose pvid was programmed from the bridge. Less than
> useful.
>
> So just don't change the pvid of the upstream port and let it be
> whatever the driver set it internally to be.
This patch should allow removing the !dsa_is_cpu_port() checks from
b53_common.c:b53_vlan_add, about time :)
It seems to me that the fundamental issue here is that because we do not
have a user visible network device that 1:1 maps with the CPU (or DSA)
ports for that matter (and for valid reasons, they would represent two
ends of the same pipe), we do not have a good way to control the CPU
port VLAN attributes.
There was a prior attempt at allowing using the bridge master device to
program the CPU port's VLAN attributes, see [1], but I did not follow up
with that until [2] and then life caught me. If you can/want, that would
be great (not asking for TPS reports).
[1]:
https://lists.linuxfoundation.org/pipermail/bridge/2016-November/010112.html
[2]:
https://lore.kernel.org/lkml/20180624153339.13572-1-f.fainelli@gmail.com/T/
>
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
> ---
> net/dsa/switch.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/net/dsa/switch.c b/net/dsa/switch.c
> index 84ab2336131e..02ccc53f1926 100644
> --- a/net/dsa/switch.c
> +++ b/net/dsa/switch.c
> @@ -239,17 +239,21 @@ dsa_switch_vlan_prepare_bitmap(struct dsa_switch *ds,
> const struct switchdev_obj_port_vlan *vlan,
> const unsigned long *bitmap)
> {
> + struct switchdev_obj_port_vlan v = *vlan;
> int port, err;
>
> if (!ds->ops->port_vlan_prepare || !ds->ops->port_vlan_add)
> return -EOPNOTSUPP;
>
> for_each_set_bit(port, bitmap, ds->num_ports) {
> - err = dsa_port_vlan_check(ds, port, vlan);
> + if (dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port))
> + v.flags &= ~BRIDGE_VLAN_INFO_PVID;
> +
> + err = dsa_port_vlan_check(ds, port, &v);
> if (err)
> return err;
>
> - err = ds->ops->port_vlan_prepare(ds, port, vlan);
> + err = ds->ops->port_vlan_prepare(ds, port, &v);
> if (err)
> return err;
> }
> @@ -262,10 +266,14 @@ dsa_switch_vlan_add_bitmap(struct dsa_switch *ds,
> const struct switchdev_obj_port_vlan *vlan,
> const unsigned long *bitmap)
> {
> + struct switchdev_obj_port_vlan v = *vlan;
> int port;
>
> - for_each_set_bit(port, bitmap, ds->num_ports)
> - ds->ops->port_vlan_add(ds, port, vlan);
> + for_each_set_bit(port, bitmap, ds->num_ports) {
> + if (dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port))
> + v.flags &= ~BRIDGE_VLAN_INFO_PVID;
> + ds->ops->port_vlan_add(ds, port, &v);
> + }
> }
>
> static int dsa_switch_vlan_add(struct dsa_switch *ds,
>
--
Florian
^ permalink raw reply
* [PATCH] vsock: Fix a lockdep warning in __vsock_release()
From: Dexuan Cui @ 2019-08-20 3:14 UTC (permalink / raw)
To: jhansen@vmware.com, davem@davemloft.net, stefanha@redhat.com,
sgarzare@redhat.com, netdev@vger.kernel.org, Stephen Hemminger,
Sasha Levin, sashal@kernel.org, Haiyang Zhang, KY Srinivasan,
Michael Kelley
Cc: linux-hyperv@vger.kernel.org, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, Dexuan Cui
Lockdep is unhappy if two locks from the same class are held.
Fix the below warning by making __vsock_release() non-recursive -- this
patch is kind of ugly, but it looks to me there is not a better way to
deal with the problem here.
============================================
WARNING: possible recursive locking detected
5.2.0+ #6 Not tainted
--------------------------------------------
a.out/1020 is trying to acquire lock:
0000000074731a98 (sk_lock-AF_VSOCK){+.+.}, at: hvs_release+0x10/0x120 [hv_sock]
but task is already holding lock:
0000000014ff8397 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x2e/0xf0 [vsock]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(sk_lock-AF_VSOCK);
lock(sk_lock-AF_VSOCK);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by a.out/1020:
#0: 00000000f8bceaa7 (&sb->s_type->i_mutex_key#10){+.+.}, at: __sock_release+0x2d/0xa0
#1: 0000000014ff8397 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x2e/0xf0 [vsock]
stack backtrace:
CPU: 7 PID: 1020 Comm: a.out Not tainted 5.2.0+ #6
Call Trace:
dump_stack+0x67/0x90
__lock_acquire.cold.66+0x14d/0x1f8
lock_acquire+0xb5/0x1c0
lock_sock_nested+0x6d/0x90
hvs_release+0x10/0x120 [hv_sock]
__vsock_release+0x24/0xf0 [vsock]
__vsock_release+0xa0/0xf0 [vsock]
vsock_release+0x12/0x30 [vsock]
__sock_release+0x37/0xa0
sock_close+0x14/0x20
__fput+0xc1/0x250
task_work_run+0x98/0xc0
do_exit+0x3dd/0xc60
do_group_exit+0x47/0xc0
get_signal+0x169/0xc60
do_signal+0x30/0x710
exit_to_usermode_loop+0x50/0xa0
do_syscall_64+0x1fc/0x220
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Signed-off-by: Dexuan Cui <decui@microsoft.com>
---
net/vmw_vsock/af_vsock.c | 33 ++++++++++++++++++++++++++++++++-
net/vmw_vsock/hyperv_transport.c | 2 +-
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index ab47bf3..420f605 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -638,6 +638,37 @@ struct sock *__vsock_create(struct net *net,
}
EXPORT_SYMBOL_GPL(__vsock_create);
+static void __vsock_release2(struct sock *sk)
+{
+ if (sk) {
+ struct sk_buff *skb;
+ struct vsock_sock *vsk;
+
+ vsk = vsock_sk(sk);
+
+ /* The release call is supposed to use lock_sock_nested()
+ * rather than lock_sock(), if a lock should be acquired.
+ */
+ transport->release(vsk);
+
+ /* Use the nested version to avoid the warning
+ * "possible recursive locking detected".
+ */
+ lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
+ sock_orphan(sk);
+ sk->sk_shutdown = SHUTDOWN_MASK;
+
+ while ((skb = skb_dequeue(&sk->sk_receive_queue)))
+ kfree_skb(skb);
+
+ /* This sk can not be a listener, so it's unnecessary
+ * to call vsock_dequeue_accept().
+ */
+ release_sock(sk);
+ sock_put(sk);
+ }
+}
+
static void __vsock_release(struct sock *sk)
{
if (sk) {
@@ -659,7 +690,7 @@ static void __vsock_release(struct sock *sk)
/* Clean up any sockets that never were accepted. */
while ((pending = vsock_dequeue_accept(sk)) != NULL) {
- __vsock_release(pending);
+ __vsock_release2(pending);
sock_put(pending);
}
diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index 9d864eb..4b126b2 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -559,7 +559,7 @@ static void hvs_release(struct vsock_sock *vsk)
struct sock *sk = sk_vsock(vsk);
bool remove_sock;
- lock_sock(sk);
+ lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
remove_sock = hvs_close_lock_held(vsk);
release_sock(sk);
if (remove_sock)
--
1.8.3.1
^ permalink raw reply related
* Re: regression in ath10k dma allocation
From: Christoph Hellwig @ 2019-08-20 3:05 UTC (permalink / raw)
To: Tobias Klausmann
Cc: Hillf Danton, Nicolin Chen, Christoph Hellwig, kvalo, davem,
ath10k, linux-wireless, netdev, linux-kernel, m.szyprowski,
robin.murphy, iommu, tobias.klausmann
In-Reply-To: <acd7a4b0-fde8-1aa2-af07-2b469e5d5ca7@mni.thm.de>
Tobias, plase try this patch:
--
From 88c590a2ecafc8279388f25bfbe1ead8ea3507a6 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <hch@lst.de>
Date: Tue, 20 Aug 2019 11:45:49 +0900
Subject: dma-direct: fix zone selection after an unaddressable CMA allocation
The new dma_alloc_contiguous hides if we allocate CMA or regular
pages, and thus fails to retry a ZONE_NORMAL allocation if the CMA
allocation succeeds but isn't addressable. That means we either fail
outright or dip into a small zone that might not succeed either.
Thanks to Hillf Danton for debugging this issue.
Fixes: b1d2dc009dec ("dma-contiguous: add dma_{alloc,free}_contiguous() helpers")
Reported-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/iommu/dma-iommu.c | 3 +++
include/linux/dma-contiguous.h | 5 +----
kernel/dma/contiguous.c | 9 +++------
kernel/dma/direct.c | 7 ++++++-
4 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index d991d40f797f..f68a62c3c32b 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -965,10 +965,13 @@ static void *iommu_dma_alloc_pages(struct device *dev, size_t size,
{
bool coherent = dev_is_dma_coherent(dev);
size_t alloc_size = PAGE_ALIGN(size);
+ int node = dev_to_node(dev);
struct page *page = NULL;
void *cpu_addr;
page = dma_alloc_contiguous(dev, alloc_size, gfp);
+ if (!page)
+ page = alloc_pages_node(node, gfp, get_order(alloc_size));
if (!page)
return NULL;
diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index c05d4e661489..03f8e98e3bcc 100644
--- a/include/linux/dma-contiguous.h
+++ b/include/linux/dma-contiguous.h
@@ -160,10 +160,7 @@ bool dma_release_from_contiguous(struct device *dev, struct page *pages,
static inline struct page *dma_alloc_contiguous(struct device *dev, size_t size,
gfp_t gfp)
{
- int node = dev ? dev_to_node(dev) : NUMA_NO_NODE;
- size_t align = get_order(PAGE_ALIGN(size));
-
- return alloc_pages_node(node, gfp, align);
+ return NULL;
}
static inline void dma_free_contiguous(struct device *dev, struct page *page,
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index 2bd410f934b3..e6b450fdbeb6 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -230,9 +230,7 @@ bool dma_release_from_contiguous(struct device *dev, struct page *pages,
*/
struct page *dma_alloc_contiguous(struct device *dev, size_t size, gfp_t gfp)
{
- int node = dev ? dev_to_node(dev) : NUMA_NO_NODE;
- size_t count = PAGE_ALIGN(size) >> PAGE_SHIFT;
- size_t align = get_order(PAGE_ALIGN(size));
+ size_t count = size >> PAGE_SHIFT;
struct page *page = NULL;
struct cma *cma = NULL;
@@ -243,14 +241,12 @@ struct page *dma_alloc_contiguous(struct device *dev, size_t size, gfp_t gfp)
/* CMA can be used only in the context which permits sleeping */
if (cma && gfpflags_allow_blocking(gfp)) {
+ size_t align = get_order(size);
size_t cma_align = min_t(size_t, align, CONFIG_CMA_ALIGNMENT);
page = cma_alloc(cma, count, cma_align, gfp & __GFP_NOWARN);
}
- /* Fallback allocation of normal pages */
- if (!page)
- page = alloc_pages_node(node, gfp, align);
return page;
}
@@ -258,6 +254,7 @@ struct page *dma_alloc_contiguous(struct device *dev, size_t size, gfp_t gfp)
* dma_free_contiguous() - release allocated pages
* @dev: Pointer to device for which the pages were allocated.
* @page: Pointer to the allocated pages.
+ int node = dev ? dev_to_node(dev) : NUMA_NO_NODE;
* @size: Size of allocated pages.
*
* This function releases memory allocated by dma_alloc_contiguous(). As the
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 795c9b095d75..d82d184463ce 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -85,6 +85,8 @@ static bool dma_coherent_ok(struct device *dev, phys_addr_t phys, size_t size)
struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
{
+ size_t alloc_size = PAGE_ALIGN(size);
+ int node = dev_to_node(dev);
struct page *page = NULL;
u64 phys_mask;
@@ -95,8 +97,11 @@ struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
gfp &= ~__GFP_ZERO;
gfp |= __dma_direct_optimal_gfp_mask(dev, dev->coherent_dma_mask,
&phys_mask);
+ page = dma_alloc_contiguous(dev, alloc_size, gfp);
+ if (page && dma_coherent_ok(dev, page_to_phys(page), size))
+ return page;
again:
- page = dma_alloc_contiguous(dev, size, gfp);
+ page = alloc_pages_node(node, gfp, get_order(alloc_size));
if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
dma_free_contiguous(dev, page, size);
page = NULL;
--
2.20.1
^ permalink raw reply related
* [PATCH] net: fix icmp_socket_deliver argument 2 input
From: Li RongQing @ 2019-08-20 2:46 UTC (permalink / raw)
To: netdev
it expects a unsigned int, but got a __be32
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
---
net/ipv4/icmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 1510e951f451..bf7b5d45de99 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -902,7 +902,7 @@ static bool icmp_redirect(struct sk_buff *skb)
return false;
}
- icmp_socket_deliver(skb, icmp_hdr(skb)->un.gateway);
+ icmp_socket_deliver(skb, ntohl(icmp_hdr(skb)->un.gateway));
return true;
}
--
2.16.2
^ permalink raw reply related
* Re: [PATCHv2 net] ipv6/addrconf: allow adding multicast addr if IFA_F_MCAUTOJOIN is set
From: David Ahern @ 2019-08-20 2:33 UTC (permalink / raw)
To: Hangbin Liu, netdev; +Cc: Madhu Challa, David S . Miller, Jianlin Shi
In-Reply-To: <20190820021947.22718-1-liuhangbin@gmail.com>
On 8/19/19 10:19 PM, Hangbin Liu wrote:
> But in ipv6_add_addr() it will check the address type and reject multicast
> address directly. So this feature is never worked for IPv6.
If true, that is really disappointing.
We need to get a functional test script started for various address cases.
^ permalink raw reply
* RE: [EXT] Re: [PATCH net-next 0/1] net: fec: add C45 MDIO read/write support
From: Andy Duan @ 2019-08-20 2:32 UTC (permalink / raw)
To: Andrew Lunn, Marco Hartmann
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Christian Herber
In-Reply-To: <20190819225422.GD29991@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
> On Mon, Aug 19, 2019 at 05:11:14PM +0000, Marco Hartmann wrote:
> > As of yet, the Fast Ethernet Controller (FEC) driver only supports
> > Clause 22 conform MDIO transactions. IEEE 802.3ae Clause 45 defines a
> > modified MDIO protocol that uses a two staged access model in order to
> > increase the address space.
> >
> > This patch adds support for Clause 45 conform MDIO read and write
> > operations to the FEC driver.
>
> Hi Marco
>
> Do all versions of the FEC hardware support C45? Or do we need to make use
> of the quirk support in this driver to just enable it for some revisions of FEC?
>
> Thanks
> Andrew
i.MX legacy platforms like i.MX6/7 series, they doesn't support Write & Read Increment.
But for i.MX8MQ/MM series, it support C45 full features like Write & Read Increment.
For the patch itself, it doesn't support Write & Read Increment, so I think the patch doesn't
need to add quirk support.
Andy
^ permalink raw reply
* Re: [PATCH V5 0/9] Fixes for vhost metadata acceleration
From: Jason Wang @ 2019-08-20 2:29 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, virtualization, netdev, linux-kernel, linux-mm, jgg
In-Reply-To: <20190819162733-mutt-send-email-mst@kernel.org>
On 2019/8/20 上午5:08, Michael S. Tsirkin wrote:
> On Tue, Aug 13, 2019 at 04:12:49PM +0800, Jason Wang wrote:
>> On 2019/8/12 下午5:49, Michael S. Tsirkin wrote:
>>> On Mon, Aug 12, 2019 at 10:44:51AM +0800, Jason Wang wrote:
>>>> On 2019/8/11 上午1:52, Michael S. Tsirkin wrote:
>>>>> On Fri, Aug 09, 2019 at 01:48:42AM -0400, Jason Wang wrote:
>>>>>> Hi all:
>>>>>>
>>>>>> This series try to fix several issues introduced by meta data
>>>>>> accelreation series. Please review.
>>>>>>
>>>>>> Changes from V4:
>>>>>> - switch to use spinlock synchronize MMU notifier with accessors
>>>>>>
>>>>>> Changes from V3:
>>>>>> - remove the unnecessary patch
>>>>>>
>>>>>> Changes from V2:
>>>>>> - use seqlck helper to synchronize MMU notifier with vhost worker
>>>>>>
>>>>>> Changes from V1:
>>>>>> - try not use RCU to syncrhonize MMU notifier with vhost worker
>>>>>> - set dirty pages after no readers
>>>>>> - return -EAGAIN only when we find the range is overlapped with
>>>>>> metadata
>>>>>>
>>>>>> Jason Wang (9):
>>>>>> vhost: don't set uaddr for invalid address
>>>>>> vhost: validate MMU notifier registration
>>>>>> vhost: fix vhost map leak
>>>>>> vhost: reset invalidate_count in vhost_set_vring_num_addr()
>>>>>> vhost: mark dirty pages during map uninit
>>>>>> vhost: don't do synchronize_rcu() in vhost_uninit_vq_maps()
>>>>>> vhost: do not use RCU to synchronize MMU notifier with worker
>>>>>> vhost: correctly set dirty pages in MMU notifiers callback
>>>>>> vhost: do not return -EAGAIN for non blocking invalidation too early
>>>>>>
>>>>>> drivers/vhost/vhost.c | 202 +++++++++++++++++++++++++-----------------
>>>>>> drivers/vhost/vhost.h | 6 +-
>>>>>> 2 files changed, 122 insertions(+), 86 deletions(-)
>>>>> This generally looks more solid.
>>>>>
>>>>> But this amounts to a significant overhaul of the code.
>>>>>
>>>>> At this point how about we revert 7f466032dc9e5a61217f22ea34b2df932786bbfc
>>>>> for this release, and then re-apply a corrected version
>>>>> for the next one?
>>>> If possible, consider we've actually disabled the feature. How about just
>>>> queued those patches for next release?
>>>>
>>>> Thanks
>>> Sorry if I was unclear. My idea is that
>>> 1. I revert the disabled code
>>> 2. You send a patch readding it with all the fixes squashed
>>> 3. Maybe optimizations on top right away?
>>> 4. We queue *that* for next and see what happens.
>>>
>>> And the advantage over the patchy approach is that the current patches
>>> are hard to review. E.g. it's not reasonable to ask RCU guys to review
>>> the whole of vhost for RCU usage but it's much more reasonable to ask
>>> about a specific patch.
>>
>> Ok. Then I agree to revert.
>>
>> Thanks
> Great, so please send the following:
> - revert
> - squashed and fixed patch
Just to confirm, do you want me to send a single series or two?
Thanks
^ permalink raw reply
* Re: [PATCH v3] tun: fix use-after-free when register netdev failed
From: Jason Wang @ 2019-08-20 2:28 UTC (permalink / raw)
To: David Miller, yangyingliang
Cc: netdev, eric.dumazet, xiyou.wangcong, weiyongjun1
In-Reply-To: <20190819.182522.414877916903078544.davem@davemloft.net>
On 2019/8/20 上午9:25, David Miller wrote:
> From: Yang Yingliang <yangyingliang@huawei.com>
> Date: Mon, 19 Aug 2019 21:31:19 +0800
>
>> Call tun_attach() after register_netdevice() to make sure tfile->tun
>> is not published until the netdevice is registered. So the read/write
>> thread can not use the tun pointer that may freed by free_netdev().
>> (The tun and dev pointer are allocated by alloc_netdev_mqs(), they can
>> be freed by netdev_freemem().)
> register_netdevice() must always be the last operation in the order of
> network device setup.
>
> At the point register_netdevice() is called, the device is visible globally
> and therefore all of it's software state must be fully initialized and
> ready for us.
>
> You're going to have to find another solution to these problems.
The device is loosely coupled with sockets/queues. Each side is allowed
to be go away without caring the other side. So in this case, there's a
small window that network stack think the device has one queue but
actually not, the code can then safely drop them. Maybe it's ok here
with some comments?
Or if not, we can try to hold the device before tun_attach and drop it
after register_netdevice().
Thanks
^ permalink raw reply
* [PATCH] net: Fix __ip_mc_inc_group argument 3 input
From: Li RongQing @ 2019-08-20 2:25 UTC (permalink / raw)
To: netdev
It expects gfp_t, but got unsigned int mode
Fixes: 6e2059b53f98 ("ipv4/igmp: init group mode as INCLUDE when join source group")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
---
net/ipv4/igmp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 180f6896b98b..b8352d716253 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1475,7 +1475,7 @@ EXPORT_SYMBOL(__ip_mc_inc_group);
void ip_mc_inc_group(struct in_device *in_dev, __be32 addr)
{
- __ip_mc_inc_group(in_dev, addr, MCAST_EXCLUDE);
+ __ip_mc_inc_group(in_dev, addr, GFP_KERNEL);
}
EXPORT_SYMBOL(ip_mc_inc_group);
@@ -2197,7 +2197,7 @@ static int __ip_mc_join_group(struct sock *sk, struct ip_mreqn *imr,
iml->sflist = NULL;
iml->sfmode = mode;
rcu_assign_pointer(inet->mc_list, iml);
- __ip_mc_inc_group(in_dev, addr, mode);
+ __ip_mc_inc_group(in_dev, addr, GFP_KERNEL);
err = 0;
done:
return err;
--
2.16.2
^ permalink raw reply related
* [PATCHv2 net] ipv6/addrconf: allow adding multicast addr if IFA_F_MCAUTOJOIN is set
From: Hangbin Liu @ 2019-08-20 2:19 UTC (permalink / raw)
To: netdev
Cc: Madhu Challa, David Ahern, David S . Miller, Jianlin Shi,
Hangbin Liu
In-Reply-To: <20190813135232.27146-1-liuhangbin@gmail.com>
In commit 93a714d6b53d ("multicast: Extend ip address command to enable
multicast group join/leave on") we added a new flag IFA_F_MCAUTOJOIN
to make user able to add multicast address on ethernet interface.
This works for IPv4, but not for IPv6. See the inet6_addr_add code.
static int inet6_addr_add()
{
...
if (cfg->ifa_flags & IFA_F_MCAUTOJOIN) {
ipv6_mc_config(net->ipv6.mc_autojoin_sk, true...)
}
ifp = ipv6_add_addr(idev, cfg, true, extack); <- always fail with maddr
if (!IS_ERR(ifp)) {
...
} else if (cfg->ifa_flags & IFA_F_MCAUTOJOIN) {
ipv6_mc_config(net->ipv6.mc_autojoin_sk, false...)
}
}
But in ipv6_add_addr() it will check the address type and reject multicast
address directly. So this feature is never worked for IPv6.
We should not remove the multicast address check totally in ipv6_add_addr(),
but could accept multicast address only when IFA_F_MCAUTOJOIN flag supplied.
v2: update commit description
Reported-by: Jianlin Shi <jishi@redhat.com>
Fixes: 93a714d6b53d ("multicast: Extend ip address command to enable multicast group join/leave on")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/ipv6/addrconf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index dc73888c7859..ced995f3fec4 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1045,7 +1045,8 @@ ipv6_add_addr(struct inet6_dev *idev, struct ifa6_config *cfg,
int err = 0;
if (addr_type == IPV6_ADDR_ANY ||
- addr_type & IPV6_ADDR_MULTICAST ||
+ (addr_type & IPV6_ADDR_MULTICAST &&
+ !(cfg->ifa_flags & IFA_F_MCAUTOJOIN)) ||
(!(idev->dev->flags & IFF_LOOPBACK) &&
!netif_is_l3_master(idev->dev) &&
addr_type & IPV6_ADDR_LOOPBACK))
--
2.19.2
^ permalink raw reply related
* Re: regression in ath10k dma allocation
From: Christoph Hellwig @ 2019-08-20 2:14 UTC (permalink / raw)
To: Nicolin Chen
Cc: Hillf Danton, Tobias Klausmann, Christoph Hellwig, kvalo, davem,
ath10k, linux-wireless, netdev, linux-kernel, m.szyprowski,
robin.murphy, iommu, tobias.klausmann
In-Reply-To: <20190820015852.GA15830@Asurada-Nvidia.nvidia.com>
On Mon, Aug 19, 2019 at 06:58:52PM -0700, Nicolin Chen wrote:
> Right...the condition was in-between. However, not every caller
> of dma_alloc_contiguous() is supposed to have a coherent check.
> So we either add a 'bool coherent_ok' to the API or revert the
> dma-direct part back to the original. Probably former option is
> better?
>
> Thank you for the debugging. I have been a bit distracted, may
> not be able to submit a fix very soon. Would you like to help?
Yeah, it turns out that while the idea for the dma_alloc_contiguous
helper was neat it didn't work out at all, and me pushing Nicolin
down that route was not a very smart idea. Sorry for causing this
mess.
I think we'll just need to open code it for dma-direct for 5.3.
Hillf do you want to cook up a patch or should I do it?
^ permalink raw reply
* RE: [PATCH net-next 1/1] fec: add C45 MDIO read/write support
From: Andy Duan @ 2019-08-20 2:08 UTC (permalink / raw)
To: Marco Hartmann, davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Christian Herber
In-Reply-To: <1566234659-7164-2-git-send-email-marco.hartmann@nxp.com>
From: Marco Hartmann Sent: Tuesday, August 20, 2019 1:11 AM
> IEEE 802.3ae clause 45 defines a modified MDIO protocol that uses a two
> staged access model in order to increase the address space.
>
> This patch adds support for C45 MDIO read and write accesses, which are
> used whenever the MII_ADDR_C45 flag in the regnum argument is set.
> In case it is not set, C22 accesses are used as before.
>
> Co-developed-by: Christian Herber <christian.herber@nxp.com>
> Signed-off-by: Christian Herber <christian.herber@nxp.com>
> Signed-off-by: Marco Hartmann <marco.hartmann@nxp.com>
> ---
> drivers/net/ethernet/freescale/fec_main.c | 65
> ++++++++++++++++++++++++++++---
> 1 file changed, 59 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index c01d3ec3e9af..73f8f9a149a1 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -208,8 +208,11 @@ MODULE_PARM_DESC(macaddr, "FEC Ethernet
> MAC address");
>
> /* FEC MII MMFR bits definition */
> #define FEC_MMFR_ST (1 << 30)
> +#define FEC_MMFR_ST_C45 (0)
> #define FEC_MMFR_OP_READ (2 << 28)
> +#define FEC_MMFR_OP_READ_C45 (3 << 28)
> #define FEC_MMFR_OP_WRITE (1 << 28)
> +#define FEC_MMFR_OP_ADDR_WRITE (0)
> #define FEC_MMFR_PA(v) ((v & 0x1f) << 23)
> #define FEC_MMFR_RA(v) ((v & 0x1f) << 18)
> #define FEC_MMFR_TA (2 << 16)
> @@ -1767,7 +1770,7 @@ static int fec_enet_mdio_read(struct mii_bus *bus,
> int mii_id, int regnum)
> struct fec_enet_private *fep = bus->priv;
> struct device *dev = &fep->pdev->dev;
> unsigned long time_left;
> - int ret = 0;
> + int ret = 0, frame_start, frame_addr, frame_op;
Add bool variable:
bool is_c45 = !!(regnum & MII_ADDR_C45);
>
> ret = pm_runtime_get_sync(dev);
> if (ret < 0)
> @@ -1775,9 +1778,36 @@ static int fec_enet_mdio_read(struct mii_bus
> *bus, int mii_id, int regnum)
>
> reinit_completion(&fep->mdio_done);
>
> + if (MII_ADDR_C45 & regnum) {
if (is_c45)
> + frame_start = FEC_MMFR_ST_C45;
> +
> + /* write address */
> + frame_addr = (regnum >> 16);
> + writel(frame_start | FEC_MMFR_OP_ADDR_WRITE |
> + FEC_MMFR_PA(mii_id) | FEC_MMFR_RA(frame_addr) |
> + FEC_MMFR_TA | (regnum & 0xFFFF),
> + fep->hwp + FEC_MII_DATA);
> +
> + /* wait for end of transfer */
> + time_left = wait_for_completion_timeout(&fep->mdio_done,
> + usecs_to_jiffies(FEC_MII_TIMEOUT));
> + if (time_left == 0) {
> + netdev_err(fep->netdev, "MDIO address write timeout\n");
> + ret = -ETIMEDOUT;
Should be:
goto out;
> + }
> +
> + frame_op = FEC_MMFR_OP_READ_C45;
> +
> + } else {
> + /* C22 read */
> + frame_op = FEC_MMFR_OP_READ;
> + frame_start = FEC_MMFR_ST;
> + frame_addr = regnum;
> + }
> +
> /* start a read op */
> - writel(FEC_MMFR_ST | FEC_MMFR_OP_READ |
> - FEC_MMFR_PA(mii_id) | FEC_MMFR_RA(regnum) |
> + writel(frame_start | frame_op |
> + FEC_MMFR_PA(mii_id) | FEC_MMFR_RA(frame_addr) |
> FEC_MMFR_TA, fep->hwp + FEC_MII_DATA);
>
> /* wait for end of transfer */
> @@ -1804,7 +1834,7 @@ static int fec_enet_mdio_write(struct mii_bus *bus,
> int mii_id, int regnum,
> struct fec_enet_private *fep = bus->priv;
> struct device *dev = &fep->pdev->dev;
> unsigned long time_left;
> - int ret;
> + int ret, frame_start, frame_addr;
>
> ret = pm_runtime_get_sync(dev);
> if (ret < 0)
> @@ -1814,9 +1844,32 @@ static int fec_enet_mdio_write(struct mii_bus
> *bus, int mii_id, int regnum,
bool is_c45 = !!(regnum & MII_ADDR_C45);
>
> reinit_completion(&fep->mdio_done);
>
> + if (MII_ADDR_C45 & regnum) {
if (!is_c45) {
> + frame_start = FEC_MMFR_ST_C45;
> +
> + /* write address */
> + frame_addr = (regnum >> 16);
> + writel(frame_start | FEC_MMFR_OP_ADDR_WRITE |
> + FEC_MMFR_PA(mii_id) | FEC_MMFR_RA(frame_addr) |
> + FEC_MMFR_TA | (regnum & 0xFFFF),
> + fep->hwp + FEC_MII_DATA);
> +
> + /* wait for end of transfer */
> + time_left = wait_for_completion_timeout(&fep->mdio_done,
> + usecs_to_jiffies(FEC_MII_TIMEOUT));
> + if (time_left == 0) {
> + netdev_err(fep->netdev, "MDIO address write timeout\n");
> + ret = -ETIMEDOUT;
Like mdio read, it should be:
goto out;
> + }
> + } else {
> + /* C22 write */
> + frame_start = FEC_MMFR_ST;
> + frame_addr = regnum;
> + }
> +
> /* start a write op */
> - writel(FEC_MMFR_ST | FEC_MMFR_OP_WRITE |
> - FEC_MMFR_PA(mii_id) | FEC_MMFR_RA(regnum) |
> + writel(frame_start | FEC_MMFR_OP_WRITE |
> + FEC_MMFR_PA(mii_id) | FEC_MMFR_RA(frame_addr) |
> FEC_MMFR_TA | FEC_MMFR_DATA(value),
> fep->hwp + FEC_MII_DATA);
>
> --
> 2.7.4
^ permalink raw reply
* Re: regression in ath10k dma allocation
From: Nicolin Chen @ 2019-08-20 1:58 UTC (permalink / raw)
To: Hillf Danton, Tobias Klausmann
Cc: Christoph Hellwig, kvalo, davem, ath10k, linux-wireless, netdev,
linux-kernel, m.szyprowski, robin.murphy, iommu, tobias.klausmann
In-Reply-To: <acd7a4b0-fde8-1aa2-af07-2b469e5d5ca7@mni.thm.de>
Hello Hillf,
On Mon, Aug 19, 2019 at 12:38:38AM +0200, Tobias Klausmann wrote:
>
> On 18.08.19 05:13, Hillf Danton wrote:
> > On Sat, 17 Aug 2019 00:42:48 +0200 Tobias Klausmann wrote:
> > > Hi Nicolin,
> > >
> > > On 17.08.19 00:25, Nicolin Chen wrote:
> > > > Hi Tobias
> > > >
> > > > On Fri, Aug 16, 2019 at 10:16:45PM +0200, Tobias Klausmann wrote:
> > > > > > do you have CONFIG_DMA_CMA set in your config? If not please make sure
> > > > > > you have this commit in your testing tree, and if the problem still
> > > > > > persists it would be a little odd and we'd have to dig deeper:
> > > > > >
> > > > > > commit dd3dcede9fa0a0b661ac1f24843f4a1b1317fdb6
> > > > > > Author: Nicolin Chen <nicoleotsuka@gmail.com>
> > > > > > Date: Wed May 29 17:54:25 2019 -0700
> > > > > >
> > > > > > dma-contiguous: fix !CONFIG_DMA_CMA version of dma_{alloc, free}_contiguous()
> > > > > yes CONFIG_DMA_CMA is set (=y, see attached config), the commit you mention
> > > > > above is included, if you have any hints how to go forward, please let me
> > > > > know!
> > > > For CONFIG_DMA_CMA=y, by judging the log with error code -12, I
> > > > feel this one should work for you. Would you please check if it
> > > > is included or try it out otherwise?
> > > >
> > > > dma-contiguous: do not overwrite align in dma_alloc_contiguous()
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c6622a425acd1d2f3a443cd39b490a8777b622d7
> > >
> > > Thanks for the hint, yet the commit is included and does not fix the
> > > problem!
> > >
> Hi Hillf,
>
> i just tested you first hunk (which comes from kernel/dma/direct.c if i'm
> not mistaken), it did not compile on its own, yet with a tiny bit of work it
> did, and it does indeed solve the regression. But if using that is the
> "right" way to do it, not sure, but its not on me to decide.
>
> Anyway: Thanks for the hint,
>
> Tobias
>
>
> > Hi Tobias
> >
> > Two minor diffs below in hope that they might make sense.
> >
> > 1, fallback unless dma coherent ok.
> >
> > --- a/kernel/dma/contiguous.c
> > +++ b/kernel/dma/contiguous.c
> > @@ -246,6 +246,10 @@ struct page *dma_alloc_contiguous(struct
> > size_t cma_align = min_t(size_t, align, CONFIG_CMA_ALIGNMENT);
> > page = cma_alloc(cma, count, cma_align, gfp & __GFP_NOWARN);
> > + if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
> > + dma_free_contiguous(dev, page, size);
> > + page = NULL;
> > + }
Right...the condition was in-between. However, not every caller
of dma_alloc_contiguous() is supposed to have a coherent check.
So we either add a 'bool coherent_ok' to the API or revert the
dma-direct part back to the original. Probably former option is
better?
Thank you for the debugging. I have been a bit distracted, may
not be able to submit a fix very soon. Would you like to help?
Thanks!
Nicolin
> > }
> > /* Fallback allocation of normal pages */
> > --
> >
> > 2, cleanup: cma unless contiguous
> >
> > --- a/kernel/dma/contiguous.c
> > +++ b/kernel/dma/contiguous.c
> > @@ -234,18 +234,13 @@ struct page *dma_alloc_contiguous(struct
> > size_t count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> > size_t align = get_order(PAGE_ALIGN(size));
> > struct page *page = NULL;
> > - struct cma *cma = NULL;
> > -
> > - if (dev && dev->cma_area)
> > - cma = dev->cma_area;
> > - else if (count > 1)
> > - cma = dma_contiguous_default_area;
> > /* CMA can be used only in the context which permits sleeping */
> > - if (cma && gfpflags_allow_blocking(gfp)) {
> > + if (count > 1 && gfpflags_allow_blocking(gfp)) {
> > size_t cma_align = min_t(size_t, align, CONFIG_CMA_ALIGNMENT);
> > - page = cma_alloc(cma, count, cma_align, gfp & __GFP_NOWARN);
> > + page = cma_alloc(dev_get_cma_area(dev), count, cma_align,
> > + gfp & __GFP_NOWARN);
> > if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
> > dma_free_contiguous(dev, page, size);
> > page = NULL;
> > --
> >
^ permalink raw reply
* Re: [PATCH 1/2] bpf: fix 'struct pt_reg' typo in documentation
From: Alexei Starovoitov @ 2019-08-20 1:44 UTC (permalink / raw)
To: Peter Wu; +Cc: Alexei Starovoitov, Daniel Borkmann, Network Development, bpf
In-Reply-To: <20190819212122.10286-2-peter@lekensteyn.nl>
On Mon, Aug 19, 2019 at 2:21 PM Peter Wu <peter@lekensteyn.nl> wrote:
>
> There is no 'struct pt_reg'.
>
> Signed-off-by: Peter Wu <peter@lekensteyn.nl>
> ---
> include/uapi/linux/bpf.h | 6 +++---
> tools/include/uapi/linux/bpf.h | 6 +++---
> 2 files changed, 6 insertions(+), 6 deletions(-)
please split it into two patches. One for kernel and one for user.
We need tools/* to be updated separately due to auto-sync
of libbpf into github.
^ permalink raw reply
* Re: [PATCH net-next 1/1] fec: add C45 MDIO read/write support
From: David Miller @ 2019-08-20 1:35 UTC (permalink / raw)
To: marco.hartmann; +Cc: fugang.duan, netdev, linux-kernel, christian.herber
In-Reply-To: <1566234659-7164-2-git-send-email-marco.hartmann@nxp.com>
From: Marco Hartmann <marco.hartmann@nxp.com>
Date: Mon, 19 Aug 2019 17:11:14 +0000
> @@ -1767,7 +1770,7 @@ static int fec_enet_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
> struct fec_enet_private *fep = bus->priv;
> struct device *dev = &fep->pdev->dev;
> unsigned long time_left;
> - int ret = 0;
> + int ret = 0, frame_start, frame_addr, frame_op;
>
Please retain the reverse christmas tree ordering of local variables
here, thank you.
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2019-08-19
From: David Miller @ 2019-08-20 1:34 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87tvad9l1v.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Mon, 19 Aug 2019 19:28:28 +0300
> here's a pull request to net-next for v5.4, more info below. Please let
> me know if there are any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* [PATCH -next] bpf: Use PTR_ERR_OR_ZERO in xsk_map_inc()
From: YueHaibing @ 2019-08-20 1:36 UTC (permalink / raw)
To: bjorn.topel, magnus.karlsson, jonathan.lemon, ast, daniel, kafai,
songliubraving, yhs, john.fastabend
Cc: YueHaibing, netdev, bpf, kernel-janitors
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
kernel/bpf/xskmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/xskmap.c b/kernel/bpf/xskmap.c
index 4cc28e226398..942c662e2eed 100644
--- a/kernel/bpf/xskmap.c
+++ b/kernel/bpf/xskmap.c
@@ -21,7 +21,7 @@ int xsk_map_inc(struct xsk_map *map)
struct bpf_map *m = &map->map;
m = bpf_map_inc(m, false);
- return IS_ERR(m) ? PTR_ERR(m) : 0;
+ return PTR_ERR_OR_ZERO(m);
}
void xsk_map_put(struct xsk_map *map)
^ permalink raw reply related
* Re: [net-next v2 04/14] ice: fix set pause param autoneg check
From: David Miller @ 2019-08-20 1:31 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: paul.greenwalt, netdev, nhorman, sassmann, andrewx.bowers
In-Reply-To: <20190819161708.3763-5-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 19 Aug 2019 09:16:58 -0700
> + /* Get pause param reports configured and negotiated flow control pause
> + * when ETHTOOL_GLINKSETTINGS is defined. Since ETHTOOL_GLINKSETTINGS is
> + * defined get pause param pause->autoneg reports SW configured setting,
> + * so compare pause->autoneg with SW configured to prevent the user from
> + * using set pause param to chance autoneg.
> + */
> + pcaps = devm_kzalloc(&vsi->back->pdev->dev, sizeof(*pcaps),
> + GFP_KERNEL);
Just in case it isn't clear, please use plain kzalloc/kfree in this code.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next 0/8] sctp: support per endpoint auth and asconf flags
From: David Miller @ 2019-08-20 1:27 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <cover.1566223325.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Mon, 19 Aug 2019 22:02:42 +0800
> This patchset mostly does 3 things:
>
> 1. add per endpint asconf flag and use asconf flag properly
> and add SCTP_ASCONF_SUPPORTED sockopt.
> 2. use auth flag properly and add SCTP_AUTH_SUPPORTED sockopt.
> 3. remove the 'global feature switch' to discard chunks.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v3] tun: fix use-after-free when register netdev failed
From: David Miller @ 2019-08-20 1:25 UTC (permalink / raw)
To: yangyingliang; +Cc: netdev, jasowang, eric.dumazet, xiyou.wangcong, weiyongjun1
In-Reply-To: <1566221479-16094-1-git-send-email-yangyingliang@huawei.com>
From: Yang Yingliang <yangyingliang@huawei.com>
Date: Mon, 19 Aug 2019 21:31:19 +0800
> Call tun_attach() after register_netdevice() to make sure tfile->tun
> is not published until the netdevice is registered. So the read/write
> thread can not use the tun pointer that may freed by free_netdev().
> (The tun and dev pointer are allocated by alloc_netdev_mqs(), they can
> be freed by netdev_freemem().)
register_netdevice() must always be the last operation in the order of
network device setup.
At the point register_netdevice() is called, the device is visible globally
and therefore all of it's software state must be fully initialized and
ready for us.
You're going to have to find another solution to these problems.
^ permalink raw reply
* Re: [PATCH][net-next] net: remove empty inet_exit_net
From: David Miller @ 2019-08-20 1:23 UTC (permalink / raw)
To: lirongqing; +Cc: netdev
In-Reply-To: <1566216315-18506-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Mon, 19 Aug 2019 20:05:15 +0800
> Pointer members of an object with static storage duration, if not
> explicitly initialized, will be initialized to a NULL pointer. The
> net namespace API checks if this pointer is not NULL before using it,
> it are safe to remove the function.
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
Applied.
^ permalink raw reply
* Re: [PATCH bpf-next 4/5] libbpf: add bpf_btf_get_next_id() to cycle through BTF objects
From: Alexei Starovoitov @ 2019-08-20 1:21 UTC (permalink / raw)
To: Quentin Monnet
Cc: Alexei Starovoitov, Daniel Borkmann, bpf, netdev, oss-drivers
In-Reply-To: <20190815150019.8523-5-quentin.monnet@netronome.com>
On Thu, Aug 15, 2019 at 04:00:18PM +0100, Quentin Monnet wrote:
> Add an API function taking a BTF object id and providing the id of the
> next BTF object in the kernel. This can be used to list all BTF objects
> loaded on the system.
>
> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
..
> +
> +LIBBPF_0.0.5 {
> + global:
> + bpf_btf_get_next_id;
> +} LIBBPF_0.0.4;
please rebase.
The rest looks great.
^ permalink raw reply
* Re: [PATCH net-next 0/2] Fix problems with using ns plugin
From: David Miller @ 2019-08-20 1:20 UTC (permalink / raw)
To: vladbu
Cc: netdev, jhs, lucasb, mrv, shuah, batuhanosmantaskaya, dcaratti,
marcelo.leitner
In-Reply-To: <20190819075208.12240-1-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Mon, 19 Aug 2019 10:52:06 +0300
> Recent changes to plugin architecture broke some of the tests when running tdc
> without specifying a test group. Fix tests incompatible with ns plugin and
> modify tests to not reuse interface name of ns veth interface for dummy
> interface.
Series applied.
^ permalink raw reply
* general protection fault in xsk_poll
From: syzbot @ 2019-08-20 1:18 UTC (permalink / raw)
To: ast, bjorn.topel, bpf, daniel, davem, hawk, jakub.kicinski,
john.fastabend, jonathan.lemon, kafai, linux-kernel,
magnus.karlsson, netdev, songliubraving, syzkaller-bugs,
xdp-newbies, yhs
Hello,
syzbot found the following crash on:
HEAD commit: da657043 Add linux-next specific files for 20190819
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16af124c600000
kernel config: https://syzkaller.appspot.com/x/.config?x=739a9b3ab3d8c770
dashboard link: https://syzkaller.appspot.com/bug?extid=c82697e3043781e08802
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=109e1922600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1445bf02600000
The bug was bisected to:
commit 77cd0d7b3f257fd0e3096b4fdcff1a7d38e99e10
Author: Magnus Karlsson <magnus.karlsson@intel.com>
Date: Wed Aug 14 07:27:17 2019 +0000
xsk: add support for need_wakeup flag in AF_XDP rings
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15e1ea4c600000
final crash: https://syzkaller.appspot.com/x/report.txt?x=17e1ea4c600000
console output: https://syzkaller.appspot.com/x/log.txt?x=13e1ea4c600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+c82697e3043781e08802@syzkaller.appspotmail.com
Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP
rings")
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 7959 Comm: syz-executor611 Not tainted 5.3.0-rc5-next-20190819
#68
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:xsk_poll+0x95/0x540 net/xdp/xsk.c:386
Code: 80 3c 02 00 0f 85 70 04 00 00 4c 8b a3 88 04 00 00 48 b8 00 00 00 00
00 fc ff df 49 8d bc 24 96 00 00 00 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48
89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 bf 03 00 00
RSP: 0018:ffff8880926f7850 EFLAGS: 00010207
RAX: dffffc0000000000 RBX: ffff88809a141700 RCX: ffffffff859b07aa
RDX: 0000000000000012 RSI: ffffffff859b07c4 RDI: 0000000000000096
RBP: ffff8880926f7880 R08: ffff88809698a580 R09: ffffed1013428329
R10: ffffed1013428328 R11: ffff88809a141947 R12: 0000000000000000
R13: 0000000000000304 R14: ffff888095d4d840 R15: ffff888092bdd020
FS: 0000555557529880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000280 CR3: 0000000098281000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
sock_poll+0x15e/0x480 net/socket.c:1256
vfs_poll include/linux/poll.h:90 [inline]
do_pollfd fs/select.c:859 [inline]
do_poll fs/select.c:907 [inline]
do_sys_poll+0x7c2/0xde0 fs/select.c:1001
__do_sys_ppoll fs/select.c:1101 [inline]
__se_sys_ppoll fs/select.c:1081 [inline]
__x64_sys_ppoll+0x259/0x310 fs/select.c:1081
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x440159
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffd9fbd16e8 EFLAGS: 00000246 ORIG_RAX: 000000000000010f
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440159
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000020000280
RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004019e0
R13: 0000000000401a70 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
---[ end trace da907175426b4065 ]---
RIP: 0010:xsk_poll+0x95/0x540 net/xdp/xsk.c:386
Code: 80 3c 02 00 0f 85 70 04 00 00 4c 8b a3 88 04 00 00 48 b8 00 00 00 00
00 fc ff df 49 8d bc 24 96 00 00 00 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48
89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 bf 03 00 00
RSP: 0018:ffff8880926f7850 EFLAGS: 00010207
RAX: dffffc0000000000 RBX: ffff88809a141700 RCX: ffffffff859b07aa
RDX: 0000000000000012 RSI: ffffffff859b07c4 RDI: 0000000000000096
RBP: ffff8880926f7880 R08: ffff88809698a580 R09: ffffed1013428329
R10: ffffed1013428328 R11: ffff88809a141947 R12: 0000000000000000
R13: 0000000000000304 R14: ffff888095d4d840 R15: ffff888092bdd020
FS: 0000555557529880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000280 CR3: 0000000098281000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH net] nfp: flower: verify that block cb is not busy before binding
From: David Miller @ 2019-08-20 1:16 UTC (permalink / raw)
To: vladbu; +Cc: netdev, jhs, xiyou.wangcong, jiri, jakub.kicinski, pablo
In-Reply-To: <20190819073304.9419-1-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Mon, 19 Aug 2019 10:33:04 +0300
> When processing FLOW_BLOCK_BIND command on indirect block, check that flow
> block cb is not busy.
>
> Fixes: 0d4fd02e7199 ("net: flow_offload: add flow_block_cb_is_busy() and use it")
> Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
Applied.
^ 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