* [PATCH] net: wireless: mediatek: fix mt76 LEDS build error
From: Randy Dunlap @ 2018-09-06 22:28 UTC (permalink / raw)
To: linux-wireless, Kalle Valo; +Cc: Felix Fietkau, netdev@vger.kernel.org
From: Randy Dunlap <rdunlap@infradead.org>
All of the mt76 driver options use its mac80211.o component,
which uses led interfaces, so each of them should depend on
LEDS_CLASS.
Fixes this build error:
drivers/net/wireless/mediatek/mt76/mac80211.o: In function `mt76_led_init':
drivers/net/wireless/mediatek/mt76/mac80211.c:119: undefined reference to `devm_of_led_classdev_register'
Fixes: 17f1de56df05 ("mt76: add common code shared between multiple chipsets")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Felix Fietkau <nbd@nbd.name>
Cc: Kalle Valo <kvalo@codeaurora.org>
---
drivers/net/wireless/mediatek/mt76/Kconfig | 3 +++
1 file changed, 3 insertions(+)
--- linux-next-20180906.orig/drivers/net/wireless/mediatek/mt76/Kconfig
+++ linux-next-20180906/drivers/net/wireless/mediatek/mt76/Kconfig
@@ -18,6 +18,7 @@ config MT76x0U
tristate "MediaTek MT76x0U (USB) support"
select MT76_CORE
depends on MAC80211
+ depends on LEDS_CLASS
depends on USB
select MT76x02_LIB
help
@@ -28,6 +29,7 @@ config MT76x2E
select MT76_CORE
select MT76x2_COMMON
depends on MAC80211
+ depends on LEDS_CLASS
depends on PCI
---help---
This adds support for MT7612/MT7602/MT7662-based wireless PCIe devices.
@@ -38,6 +40,7 @@ config MT76x2U
select MT76_USB
select MT76x2_COMMON
depends on MAC80211
+ depends on LEDS_CLASS
depends on USB
help
This adds support for MT7612U-based wireless USB dongles.
^ permalink raw reply
* Re: [PATCH net-next 01/11] net: sock: introduce SOCK_XDP
From: Jason Wang @ 2018-09-07 3:07 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20180906125615-mutt-send-email-mst@kernel.org>
On 2018年09月07日 00:56, Michael S. Tsirkin wrote:
> On Thu, Sep 06, 2018 at 12:05:16PM +0800, Jason Wang wrote:
>> This patch introduces a new sock flag - SOCK_XDP. This will be used
>> for notifying the upper layer that XDP program is attached on the
>> lower socket, and requires for extra headroom.
>>
>> TUN will be the first user.
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
> In fact vhost is the 1st user, right? So this can be
> pushed out to become patch 10/11.
Better with an independent patch, since patch 10/11 can work without XDP.
Thanks
>
>> ---
>> drivers/net/tun.c | 19 +++++++++++++++++++
>> include/net/sock.h | 1 +
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index ebd07ad82431..2c548bd20393 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -869,6 +869,9 @@ static int tun_attach(struct tun_struct *tun, struct file *file,
>> tun_napi_init(tun, tfile, napi);
>> }
>>
>> + if (rtnl_dereference(tun->xdp_prog))
>> + sock_set_flag(&tfile->sk, SOCK_XDP);
>> +
>> tun_set_real_num_queues(tun);
>>
>> /* device is allowed to go away first, so no need to hold extra
>> @@ -1241,13 +1244,29 @@ static int tun_xdp_set(struct net_device *dev, struct bpf_prog *prog,
>> struct netlink_ext_ack *extack)
>> {
>> struct tun_struct *tun = netdev_priv(dev);
>> + struct tun_file *tfile;
>> struct bpf_prog *old_prog;
>> + int i;
>>
>> old_prog = rtnl_dereference(tun->xdp_prog);
>> rcu_assign_pointer(tun->xdp_prog, prog);
>> if (old_prog)
>> bpf_prog_put(old_prog);
>>
>> + for (i = 0; i < tun->numqueues; i++) {
>> + tfile = rtnl_dereference(tun->tfiles[i]);
>> + if (prog)
>> + sock_set_flag(&tfile->sk, SOCK_XDP);
>> + else
>> + sock_reset_flag(&tfile->sk, SOCK_XDP);
>> + }
>> + list_for_each_entry(tfile, &tun->disabled, next) {
>> + if (prog)
>> + sock_set_flag(&tfile->sk, SOCK_XDP);
>> + else
>> + sock_reset_flag(&tfile->sk, SOCK_XDP);
>> + }
>> +
>> return 0;
>> }
>>
>> diff --git a/include/net/sock.h b/include/net/sock.h
>> index 433f45fc2d68..38cae35f6e16 100644
>> --- a/include/net/sock.h
>> +++ b/include/net/sock.h
>> @@ -800,6 +800,7 @@ enum sock_flags {
>> SOCK_SELECT_ERR_QUEUE, /* Wake select on error queue */
>> SOCK_RCU_FREE, /* wait rcu grace period in sk_destruct() */
>> SOCK_TXTIME,
>> + SOCK_XDP, /* XDP is attached */
>> };
>>
>> #define SK_FLAGS_TIMESTAMP ((1UL << SOCK_TIMESTAMP) | (1UL << SOCK_TIMESTAMPING_RX_SOFTWARE))
>> --
>> 2.17.1
^ permalink raw reply
* Re: [PATCH net-next 02/11] tuntap: switch to use XDP_PACKET_HEADROOM
From: Jason Wang @ 2018-09-07 3:12 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20180906125718-mutt-send-email-mst@kernel.org>
On 2018年09月07日 00:57, Michael S. Tsirkin wrote:
> On Thu, Sep 06, 2018 at 12:05:17PM +0800, Jason Wang wrote:
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
> any idea why didn't we do this straight away?
Dunno, but git grep told me not all XDP capable driver use this (e.g
virtio_net has its own value).
Anyway, I think it's ok for driver to have their specific value if they
can make sure the value is equal or greater than XDP_PACKET_HEADROOM.
Thanks
>
>> ---
>> drivers/net/tun.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index 2c548bd20393..d3677a544b56 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -113,7 +113,6 @@ do { \
>> } while (0)
>> #endif
>>
>> -#define TUN_HEADROOM 256
>> #define TUN_RX_PAD (NET_IP_ALIGN + NET_SKB_PAD)
>>
>> /* TUN device flags */
>> @@ -1654,7 +1653,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
>> rcu_read_lock();
>> xdp_prog = rcu_dereference(tun->xdp_prog);
>> if (xdp_prog)
>> - pad += TUN_HEADROOM;
>> + pad += XDP_PACKET_HEADROOM;
>> buflen += SKB_DATA_ALIGN(len + pad);
>> rcu_read_unlock();
>>
>> --
>> 2.17.1
^ permalink raw reply
* Re: [PATCH net-next 04/11] tuntap: simplify error handling in tun_build_skb()
From: Jason Wang @ 2018-09-07 3:22 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20180906130425-mutt-send-email-mst@kernel.org>
On 2018年09月07日 01:14, Michael S. Tsirkin wrote:
> On Thu, Sep 06, 2018 at 12:05:19PM +0800, Jason Wang wrote:
>> There's no need to duplicate page get logic in each action. So this
>> patch tries to get page and calculate the offset before processing XDP
>> actions, and undo them when meet errors (we don't care the performance
>> on errors). This will be used for factoring out XDP logic.
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
> I see some issues with this one.
>
>> ---
>> drivers/net/tun.c | 37 ++++++++++++++++---------------------
>> 1 file changed, 16 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index 372caf7d67d9..f8cdcfa392c3 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -1642,7 +1642,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
>> int len, int *skb_xdp)
>> {
>> struct page_frag *alloc_frag = ¤t->task_frag;
>> - struct sk_buff *skb;
>> + struct sk_buff *skb = NULL;
>> struct bpf_prog *xdp_prog;
>> int buflen = SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>> unsigned int delta = 0;
>> @@ -1668,6 +1668,9 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
>> if (copied != len)
>> return ERR_PTR(-EFAULT);
>>
>> + get_page(alloc_frag->page);
>> + alloc_frag->offset += buflen;
>> +
> This adds an atomic op on XDP_DROP which is a data path
> operation for some workloads.
Yes, I have patch on top to amortize this, the idea is to have a very
big refcount once after the frag was allocated and maintain a bias and
decrease them all when allocating new frags.'
>
>> /* There's a small window that XDP may be set after the check
>> * of xdp_prog above, this should be rare and for simplicity
>> * we do XDP on skb in case the headroom is not enough.
>> @@ -1695,23 +1698,15 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
>>
>> switch (act) {
>> case XDP_REDIRECT:
>> - get_page(alloc_frag->page);
>> - alloc_frag->offset += buflen;
>> err = xdp_do_redirect(tun->dev, &xdp, xdp_prog);
>> xdp_do_flush_map();
>> if (err)
>> - goto err_redirect;
>> - rcu_read_unlock();
>> - local_bh_enable();
>> - return NULL;
>> + goto err_xdp;
>> + goto out;
>> case XDP_TX:
>> - get_page(alloc_frag->page);
>> - alloc_frag->offset += buflen;
>> if (tun_xdp_tx(tun->dev, &xdp) < 0)
>> - goto err_redirect;
>> - rcu_read_unlock();
>> - local_bh_enable();
>> - return NULL;
>> + goto err_xdp;
>> + goto out;
>> case XDP_PASS:
>> delta = orig_data - xdp.data;
>> len = xdp.data_end - xdp.data;
>> @@ -1730,23 +1725,23 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
>> local_bh_enable();
>>
>> skb = build_skb(buf, buflen);
>> - if (!skb)
>> - return ERR_PTR(-ENOMEM);
>> + if (!skb) {
>> + skb = ERR_PTR(-ENOMEM);
>> + goto out;
> So goto out will skip put_page, and we did
> do get_page above. Seems wrong. You should
> goto err_skb or something like this.
Yes, looks like err_xdp.
>
>
>> + }
>>
>> skb_reserve(skb, pad - delta);
>> skb_put(skb, len);
>> - get_page(alloc_frag->page);
>> - alloc_frag->offset += buflen;
>>
>> return skb;
>>
>> -err_redirect:
>> - put_page(alloc_frag->page);
>> err_xdp:
>> + alloc_frag->offset -= buflen;
>> + put_page(alloc_frag->page);
>> +out:
> Out here isn't an error at all, is it? You should not mix return and
> error handling IMHO.
If you mean the name, I can rename the label to "drop".
>
>
>
>> rcu_read_unlock();
>> local_bh_enable();
>> - this_cpu_inc(tun->pcpu_stats->rx_dropped);
> Doesn't this break rx_dropped accounting?
Let me fix this.
Thanks
>> - return NULL;
>> + return skb;
>> }
>>
>> /* Get packet from user space buffer */
>> --
>> 2.17.1
^ permalink raw reply
* Re: [PATCH net-next 05/11] tuntap: tweak on the path of non-xdp case in tun_build_skb()
From: Jason Wang @ 2018-09-07 3:24 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20180906131509-mutt-send-email-mst@kernel.org>
On 2018年09月07日 01:16, Michael S. Tsirkin wrote:
> On Thu, Sep 06, 2018 at 12:05:20PM +0800, Jason Wang wrote:
>> If we're sure not to go native XDP, there's no need for several things
>> like bh and rcu stuffs.
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
> True...
>
>> ---
>> drivers/net/tun.c | 9 ++++++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index f8cdcfa392c3..389aa0727cc6 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -1675,10 +1675,12 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
>> * of xdp_prog above, this should be rare and for simplicity
>> * we do XDP on skb in case the headroom is not enough.
>> */
>> - if (hdr->gso_type || !xdp_prog)
>> + if (hdr->gso_type || !xdp_prog) {
>> *skb_xdp = 1;
>> - else
>> - *skb_xdp = 0;
>> + goto build;
>> + }
>> +
>> + *skb_xdp = 0;
>>
>> local_bh_disable();
>> rcu_read_lock();
>> @@ -1724,6 +1726,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
>> rcu_read_unlock();
>> local_bh_enable();
>>
>> +build:
> But this is spaghetti code. Please just put common
> code into functions and call them, don't goto.
Ok, will do this.
Thanks
>
>> skb = build_skb(buf, buflen);
>> if (!skb) {
>> skb = ERR_PTR(-ENOMEM);
>> --
>> 2.17.1
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [pull request][net-next 0/9] Mellanox, mlx5 ethernet updates 2018-09-05
From: David Miller @ 2018-09-06 22:50 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20180906043331.31958-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Wed, 5 Sep 2018 21:33:22 -0700
> This pull request provides some updates to mlx5 ethernet driver.
>
> For more information please see tag log below.
>
> Please pull and let me know if there's any problem.
Pulled, thank you.
^ permalink raw reply
* Re: [PATCH net-next 06/11] tuntap: split out XDP logic
From: Jason Wang @ 2018-09-07 3:29 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20180906131703-mutt-send-email-mst@kernel.org>
On 2018年09月07日 01:21, Michael S. Tsirkin wrote:
> On Thu, Sep 06, 2018 at 12:05:21PM +0800, Jason Wang wrote:
>> This patch split out XDP logic into a single function. This make it to
>> be reused by XDP batching path in the following patch.
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> drivers/net/tun.c | 84 ++++++++++++++++++++++++++++-------------------
>> 1 file changed, 51 insertions(+), 33 deletions(-)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index 389aa0727cc6..21b125020b3b 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -1635,6 +1635,44 @@ static bool tun_can_build_skb(struct tun_struct *tun, struct tun_file *tfile,
>> return true;
>> }
>>
>> +static u32 tun_do_xdp(struct tun_struct *tun,
>> + struct tun_file *tfile,
>> + struct bpf_prog *xdp_prog,
>> + struct xdp_buff *xdp,
>> + int *err)
>> +{
>> + u32 act = bpf_prog_run_xdp(xdp_prog, xdp);
>> +
>> + switch (act) {
>> + case XDP_REDIRECT:
>> + *err = xdp_do_redirect(tun->dev, xdp, xdp_prog);
>> + xdp_do_flush_map();
>> + if (*err)
>> + break;
>> + goto out;
>> + case XDP_TX:
>> + *err = tun_xdp_tx(tun->dev, xdp);
>> + if (*err < 0)
>> + break;
>> + *err = 0;
>> + goto out;
>> + case XDP_PASS:
>> + goto out;
> Do we need goto? why not just return?
I don't see any difference.
>
>> + default:
>> + bpf_warn_invalid_xdp_action(act);
>> + /* fall through */
>> + case XDP_ABORTED:
>> + trace_xdp_exception(tun->dev, xdp_prog, act);
>> + /* fall through */
>> + case XDP_DROP:
>> + break;
>> + }
>> +
>> + put_page(virt_to_head_page(xdp->data_hard_start));
> put here because caller does get_page :( Not pretty.
> I'd move this out to the caller.
Then we need a switch in the caller, not sure it's better.
>
>> +out:
>> + return act;
> How about combining err and act? err is < 0 XDP_PASS is > 0.
> No need for pointers then.
Ok.
>
>> +}
>> +
>> static struct sk_buff *tun_build_skb(struct tun_struct *tun,
>> struct tun_file *tfile,
>> struct iov_iter *from,
>> @@ -1645,10 +1683,10 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
>> struct sk_buff *skb = NULL;
>> struct bpf_prog *xdp_prog;
>> int buflen = SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>> - unsigned int delta = 0;
>> char *buf;
>> size_t copied;
>> - int err, pad = TUN_RX_PAD;
>> + int pad = TUN_RX_PAD;
>> + int err = 0;
>>
>> rcu_read_lock();
>> xdp_prog = rcu_dereference(tun->xdp_prog);
>> @@ -1685,9 +1723,8 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
>> local_bh_disable();
>> rcu_read_lock();
>> xdp_prog = rcu_dereference(tun->xdp_prog);
>> - if (xdp_prog && !*skb_xdp) {
>> + if (xdp_prog) {
>> struct xdp_buff xdp;
>> - void *orig_data;
>> u32 act;
>>
>> xdp.data_hard_start = buf;
>> @@ -1695,33 +1732,14 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
>> xdp_set_data_meta_invalid(&xdp);
>> xdp.data_end = xdp.data + len;
>> xdp.rxq = &tfile->xdp_rxq;
>> - orig_data = xdp.data;
>> - act = bpf_prog_run_xdp(xdp_prog, &xdp);
>> -
>> - switch (act) {
>> - case XDP_REDIRECT:
>> - err = xdp_do_redirect(tun->dev, &xdp, xdp_prog);
>> - xdp_do_flush_map();
>> - if (err)
>> - goto err_xdp;
>> - goto out;
>> - case XDP_TX:
>> - if (tun_xdp_tx(tun->dev, &xdp) < 0)
>> - goto err_xdp;
>> - goto out;
>> - case XDP_PASS:
>> - delta = orig_data - xdp.data;
>> - len = xdp.data_end - xdp.data;
>> - break;
>> - default:
>> - bpf_warn_invalid_xdp_action(act);
>> - /* fall through */
>> - case XDP_ABORTED:
>> - trace_xdp_exception(tun->dev, xdp_prog, act);
>> - /* fall through */
>> - case XDP_DROP:
>> + act = tun_do_xdp(tun, tfile, xdp_prog, &xdp, &err);
>> + if (err)
>> goto err_xdp;
>> - }
>> + if (act != XDP_PASS)
>> + goto out;
> likely?
It depends on the XDP program, so I tend not to use it.
>
>> +
>> + pad = xdp.data - xdp.data_hard_start;
>> + len = xdp.data_end - xdp.data;
>> }
>> rcu_read_unlock();
>> local_bh_enable();
>> @@ -1729,18 +1747,18 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
>> build:
>> skb = build_skb(buf, buflen);
>> if (!skb) {
>> + put_page(alloc_frag->page);
>> skb = ERR_PTR(-ENOMEM);
>> goto out;
>> }
>>
>> - skb_reserve(skb, pad - delta);
>> + skb_reserve(skb, pad);
>> skb_put(skb, len);
>>
>> return skb;
>>
>> err_xdp:
>> - alloc_frag->offset -= buflen;
>> - put_page(alloc_frag->page);
>> + this_cpu_inc(tun->pcpu_stats->rx_dropped);
>
> This fixes bug in previous patch which dropped it. OK :)
Yes, but let me move this to the buggy patch.
Thanks
>> out:
>> rcu_read_unlock();
>> local_bh_enable();
>> --
>> 2.17.1
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH net-next] liquidio: Add spoof checking on a VF MAC address
From: David Miller @ 2018-09-06 22:52 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
weilin.chang
In-Reply-To: <20180906014056.GA2159@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Wed, 5 Sep 2018 18:40:56 -0700
> From: Weilin Chang <weilin.chang@cavium.com>
>
> 1. Provide the API to set/unset the spoof checking feature.
> 2. Add a function to periodically provide the count of found
> packets with spoof VF MAC address.
> 3. Prevent VF MAC address changing while the spoofchk of the VF is
> on unless the changing MAC address is issued from PF.
>
> Signed-off-by: Weilin Chang <weilin.chang@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] liquidio CN23XX: Remove set but not used variable 'ring_flag'
From: David Miller @ 2018-09-06 22:54 UTC (permalink / raw)
To: yuehaibing
Cc: derek.chickles, satananda.burla, felix.manlunas, raghu.vatsavayi,
netdev, kernel-janitors
In-Reply-To: <1536232929-117243-1-git-send-email-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 6 Sep 2018 11:22:09 +0000
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c: In function 'cn23xx_setup_octeon_vf_device':
> drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c:619:20: warning:
> variable 'ring_flag' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net/sock: move memory_allocated over to percpu_counter variables
From: Herbert Xu @ 2018-09-07 3:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: Olof Johansson, David Miller, Neil Horman,
Marcelo Ricardo Leitner, Vladislav Yasevich, Alexey Kuznetsov,
Hideaki YOSHIFUJI, linux-crypto, LKML, linux-sctp, netdev,
linux-decnet-user, kernel-team
In-Reply-To: <CANn89i+akEWrHELBkZJQOxok-ZfYy+FNPUWdPEfB6c4YyWLqJA@mail.gmail.com>
On Thu, Sep 06, 2018 at 12:33:58PM -0700, Eric Dumazet wrote:
> On Thu, Sep 6, 2018 at 12:21 PM Olof Johansson <olof@lixom.net> wrote:
> >
> > Today these are all global shared variables per protocol, and in
> > particular tcp_memory_allocated can get hot on a system with
> > large number of CPUs and a substantial number of connections.
> >
> > Moving it over to a per-cpu variable makes it significantly cheaper,
> > and the added overhead when summing up the percpu copies is still smaller
> > than the cost of having a hot cacheline bouncing around.
>
> I am curious. We never noticed contention on this variable, at least for TCP.
Yes these variables are heavily amortised so I'm surprised that
they would cause much contention.
> Please share some numbers with us.
Indeed.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH net-next 08/11] tun: switch to new type of msg_control
From: Jason Wang @ 2018-09-07 3:35 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20180906125051-mutt-send-email-mst@kernel.org>
On 2018年09月07日 00:54, Michael S. Tsirkin wrote:
> On Thu, Sep 06, 2018 at 12:05:23PM +0800, Jason Wang wrote:
>> This patch introduces to a new tun/tap specific msg_control:
>>
>> #define TUN_MSG_UBUF 1
>> #define TUN_MSG_PTR 2
>> struct tun_msg_ctl {
>> int type;
>> void *ptr;
>> };
>>
>> This allows us to pass different kinds of msg_control through
>> sendmsg(). The first supported type is ubuf (TUN_MSG_UBUF) which will
>> be used by the existed vhost_net zerocopy code. The second is XDP
>> buff, which allows vhost_net to pass XDP buff to TUN. This could be
>> used to implement accepting an array of XDP buffs from vhost_net in
>> the following patches.
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
> At this point, do we want to just add a new sock opt for tap's
> benefit? Seems cleaner than (ab)using sendmsg.
I think it won't be much difference, we still need a void pointer.
>> ---
>> drivers/net/tap.c | 18 ++++++++++++------
>> drivers/net/tun.c | 6 +++++-
>> drivers/vhost/net.c | 7 +++++--
>> include/linux/if_tun.h | 7 +++++++
>> 4 files changed, 29 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/net/tap.c b/drivers/net/tap.c
>> index f0f7cd977667..7996ed7cbf18 100644
>> --- a/drivers/net/tap.c
>> +++ b/drivers/net/tap.c
>> @@ -619,7 +619,7 @@ static inline struct sk_buff *tap_alloc_skb(struct sock *sk, size_t prepad,
>> #define TAP_RESERVE HH_DATA_OFF(ETH_HLEN)
>>
>> /* Get packet from user space buffer */
>> -static ssize_t tap_get_user(struct tap_queue *q, struct msghdr *m,
>> +static ssize_t tap_get_user(struct tap_queue *q, void *msg_control,
>> struct iov_iter *from, int noblock)
>> {
>> int good_linear = SKB_MAX_HEAD(TAP_RESERVE);
>> @@ -663,7 +663,7 @@ static ssize_t tap_get_user(struct tap_queue *q, struct msghdr *m,
>> if (unlikely(len < ETH_HLEN))
>> goto err;
>>
>> - if (m && m->msg_control && sock_flag(&q->sk, SOCK_ZEROCOPY)) {
>> + if (msg_control && sock_flag(&q->sk, SOCK_ZEROCOPY)) {
>> struct iov_iter i;
>>
>> copylen = vnet_hdr.hdr_len ?
>> @@ -724,11 +724,11 @@ static ssize_t tap_get_user(struct tap_queue *q, struct msghdr *m,
>> tap = rcu_dereference(q->tap);
>> /* copy skb_ubuf_info for callback when skb has no error */
>> if (zerocopy) {
>> - skb_shinfo(skb)->destructor_arg = m->msg_control;
>> + skb_shinfo(skb)->destructor_arg = msg_control;
>> skb_shinfo(skb)->tx_flags |= SKBTX_DEV_ZEROCOPY;
>> skb_shinfo(skb)->tx_flags |= SKBTX_SHARED_FRAG;
>> - } else if (m && m->msg_control) {
>> - struct ubuf_info *uarg = m->msg_control;
>> + } else if (msg_control) {
>> + struct ubuf_info *uarg = msg_control;
>> uarg->callback(uarg, false);
>> }
>>
>> @@ -1150,7 +1150,13 @@ static int tap_sendmsg(struct socket *sock, struct msghdr *m,
>> size_t total_len)
>> {
>> struct tap_queue *q = container_of(sock, struct tap_queue, sock);
>> - return tap_get_user(q, m, &m->msg_iter, m->msg_flags & MSG_DONTWAIT);
>> + struct tun_msg_ctl *ctl = m->msg_control;
>> +
>> + if (ctl && ctl->type != TUN_MSG_UBUF)
>> + return -EINVAL;
>> +
>> + return tap_get_user(q, ctl ? ctl->ptr : NULL, &m->msg_iter,
>> + m->msg_flags & MSG_DONTWAIT);
>> }
>>
>> static int tap_recvmsg(struct socket *sock, struct msghdr *m,
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index ff1cbf3ebd50..c839a4bdcbd9 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -2429,11 +2429,15 @@ static int tun_sendmsg(struct socket *sock, struct msghdr *m, size_t total_len)
>> int ret;
>> struct tun_file *tfile = container_of(sock, struct tun_file, socket);
>> struct tun_struct *tun = tun_get(tfile);
>> + struct tun_msg_ctl *ctl = m->msg_control;
>>
>> if (!tun)
>> return -EBADFD;
>>
>> - ret = tun_get_user(tun, tfile, m->msg_control, &m->msg_iter,
>> + if (ctl && ctl->type != TUN_MSG_UBUF)
>> + return -EINVAL;
>> +
>> + ret = tun_get_user(tun, tfile, ctl ? ctl->ptr : NULL, &m->msg_iter,
>> m->msg_flags & MSG_DONTWAIT,
>> m->msg_flags & MSG_MORE);
>> tun_put(tun);
>> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
>> index 4e656f89cb22..fb01ce6d981c 100644
>> --- a/drivers/vhost/net.c
>> +++ b/drivers/vhost/net.c
>> @@ -620,6 +620,7 @@ static void handle_tx_zerocopy(struct vhost_net *net, struct socket *sock)
>> .msg_controllen = 0,
>> .msg_flags = MSG_DONTWAIT,
>> };
>> + struct tun_msg_ctl ctl;
>> size_t len, total_len = 0;
>> int err;
>> struct vhost_net_ubuf_ref *uninitialized_var(ubufs);
>> @@ -664,8 +665,10 @@ static void handle_tx_zerocopy(struct vhost_net *net, struct socket *sock)
>> ubuf->ctx = nvq->ubufs;
>> ubuf->desc = nvq->upend_idx;
>> refcount_set(&ubuf->refcnt, 1);
>> - msg.msg_control = ubuf;
>> - msg.msg_controllen = sizeof(ubuf);
>> + msg.msg_control = &ctl;
>> + ctl.type = TUN_MSG_UBUF;
>> + ctl.ptr = ubuf;
>> + msg.msg_controllen = sizeof(ctl);
>> ubufs = nvq->ubufs;
>> atomic_inc(&ubufs->refcount);
>> nvq->upend_idx = (nvq->upend_idx + 1) % UIO_MAXIOV;
>> diff --git a/include/linux/if_tun.h b/include/linux/if_tun.h
>> index 3d2996dc7d85..ba46dced1f38 100644
>> --- a/include/linux/if_tun.h
>> +++ b/include/linux/if_tun.h
>> @@ -19,6 +19,13 @@
>>
>> #define TUN_XDP_FLAG 0x1UL
>>
>> +#define TUN_MSG_UBUF 1
>> +#define TUN_MSG_PTR 2
> Looks like TUN_MSG_PTR should be pushed out to a follow-up patch?
Ok.
>
>> +struct tun_msg_ctl {
>> + int type;
>> + void *ptr;
>> +};
>> +
> type actually includes a size. Why not two short fields then?
Yes, this sounds better.
Thanks
>
>> #if defined(CONFIG_TUN) || defined(CONFIG_TUN_MODULE)
>> struct socket *tun_get_socket(struct file *);
>> struct ptr_ring *tun_get_tx_ring(struct file *file);
>> --
>> 2.17.1
^ permalink raw reply
* [PATCH net-next] ixgbe: remove redundant function ixgbe_fw_recovery_mode()
From: YueHaibing @ 2018-09-07 3:38 UTC (permalink / raw)
To: davem, jeffrey.t.kirsher
Cc: linux-kernel, netdev, intel-wired-lan, YueHaibing
There are no in-tree callers.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 970f71d..0bd1294 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -3485,17 +3485,6 @@ void ixgbe_set_vlan_anti_spoofing(struct ixgbe_hw *hw, bool enable, int vf)
}
/**
- * ixgbe_fw_recovery_mode - Check if in FW NVM recovery mode
- * @hw: pointer to hardware structure
- */
-bool ixgbe_fw_recovery_mode(struct ixgbe_hw *hw)
-{
- if (hw->mac.ops.fw_recovery_mode)
- return hw->mac.ops.fw_recovery_mode(hw);
- return false;
-}
-
-/**
* ixgbe_get_device_caps_generic - Get additional device capabilities
* @hw: pointer to hardware structure
* @device_caps: the EEPROM word with the extra device capabilities
--
2.7.0
^ permalink raw reply related
* Re: [PATCH net-next 10/11] tap: accept an array of XDP buffs through sendmsg()
From: Jason Wang @ 2018-09-07 3:41 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20180906135450-mutt-send-email-mst@kernel.org>
On 2018年09月07日 02:00, Michael S. Tsirkin wrote:
> On Thu, Sep 06, 2018 at 12:05:25PM +0800, Jason Wang wrote:
>> This patch implement TUN_MSG_PTR msg_control type. This type allows
>> the caller to pass an array of XDP buffs to tuntap through ptr field
>> of the tun_msg_control. Tap will build skb through those XDP buffers.
>>
>> This will avoid lots of indirect calls thus improves the icache
>> utilization and allows to do XDP batched flushing when doing XDP
>> redirection.
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> drivers/net/tap.c | 73 +++++++++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 71 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/tap.c b/drivers/net/tap.c
>> index 7996ed7cbf18..50eb7bf22225 100644
>> --- a/drivers/net/tap.c
>> +++ b/drivers/net/tap.c
>> @@ -1146,14 +1146,83 @@ static const struct file_operations tap_fops = {
>> #endif
>> };
>>
>> +static int tap_get_user_xdp(struct tap_queue *q, struct xdp_buff *xdp)
>> +{
>> + struct virtio_net_hdr *gso = xdp->data_hard_start + sizeof(int);
>> + int buflen = *(int *)xdp->data_hard_start;
>> + int vnet_hdr_len = 0;
>> + struct tap_dev *tap;
>> + struct sk_buff *skb;
>> + int err, depth;
>> +
>> + if (q->flags & IFF_VNET_HDR)
>> + vnet_hdr_len = READ_ONCE(q->vnet_hdr_sz);
>> +
>> + skb = build_skb(xdp->data_hard_start, buflen);
>> + if (!skb) {
>> + err = -ENOMEM;
>> + goto err;
>> + }
> So fundamentally why is it called XDP?
> We just build and skb, don't we?
The reason is that the function accepts a pointer to XDP. And also the
for the future development, I think the name is ok:
- we will probably do XDP offloading in this function.
- we may have a chance to call lower device's ndo_xdp_xmit() in the future.
Thanks
>
>> +
>> + skb_reserve(skb, xdp->data - xdp->data_hard_start);
>> + skb_put(skb, xdp->data_end - xdp->data);
>> +
>> + skb_set_network_header(skb, ETH_HLEN);
>> + skb_reset_mac_header(skb);
>> + skb->protocol = eth_hdr(skb)->h_proto;
>> +
>> + if (vnet_hdr_len) {
>> + err = virtio_net_hdr_to_skb(skb, gso, tap_is_little_endian(q));
>> + if (err)
>> + goto err_kfree;
>> + }
>> +
>> + skb_probe_transport_header(skb, ETH_HLEN);
>> +
>> + /* Move network header to the right position for VLAN tagged packets */
>> + if ((skb->protocol == htons(ETH_P_8021Q) ||
>> + skb->protocol == htons(ETH_P_8021AD)) &&
>> + __vlan_get_protocol(skb, skb->protocol, &depth) != 0)
>> + skb_set_network_header(skb, depth);
>> +
>> + rcu_read_lock();
>> + tap = rcu_dereference(q->tap);
>> + if (tap) {
>> + skb->dev = tap->dev;
>> + dev_queue_xmit(skb);
>> + } else {
>> + kfree_skb(skb);
>> + }
>> + rcu_read_unlock();
>> +
>> + return 0;
>> +
>> +err_kfree:
>> + kfree_skb(skb);
>> +err:
>> + rcu_read_lock();
>> + tap = rcu_dereference(q->tap);
>> + if (tap && tap->count_tx_dropped)
>> + tap->count_tx_dropped(tap);
>> + rcu_read_unlock();
>> + return err;
>> +}
>> +
>> static int tap_sendmsg(struct socket *sock, struct msghdr *m,
>> size_t total_len)
>> {
>> struct tap_queue *q = container_of(sock, struct tap_queue, sock);
>> struct tun_msg_ctl *ctl = m->msg_control;
>> + struct xdp_buff *xdp;
>> + int i;
>>
>> - if (ctl && ctl->type != TUN_MSG_UBUF)
>> - return -EINVAL;
>> + if (ctl && ((ctl->type & 0xF) == TUN_MSG_PTR)) {
>> + for (i = 0; i < ctl->type >> 16; i++) {
>> + xdp = &((struct xdp_buff *)ctl->ptr)[i];
>> + tap_get_user_xdp(q, xdp);
>> + }
>> + return 0;
>> + }
>>
>> return tap_get_user(q, ctl ? ctl->ptr : NULL, &m->msg_iter,
>> m->msg_flags & MSG_DONTWAIT);
>> --
>> 2.17.1
^ permalink raw reply
* Re: [RFC PATCH bpf-next v2 0/4] Implement bpf queue/stack maps
From: Alexei Starovoitov @ 2018-09-07 0:13 UTC (permalink / raw)
To: Mauricio Vasquez B; +Cc: Alexei Starovoitov, Daniel Borkmann, netdev, joe
In-Reply-To: <153575074884.30050.17670029209466860207.stgit@kernel>
On Fri, Aug 31, 2018 at 11:25:48PM +0200, Mauricio Vasquez B wrote:
> In some applications this is needed have a pool of free elements, like for
> example the list of free L4 ports in a SNAT. None of the current maps allow
> to do it as it is not possibleto get an any element without having they key
> it is associated to.
>
> This patchset implements two new kind of eBPF maps: queue and stack.
> Those maps provide to eBPF programs the peek, push and pop operations, and for
> userspace applications a new bpf_map_lookup_and_delete_elem() is added.
>
> Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>
>
> ---
>
> I am sending this as an RFC because there is still an issue I am not sure how
> to solve.
>
> The queue/stack maps have a linked list for saving the nodes, and a
> preallocation schema based on the pcpu_freelist already implemented and used
> in the htabmap. Each time an element is pushed into the map, a node from the
> pcpu_freelist is taken and then added to the linked list.
>
> The pop operation takes and *removes* the first node from the linked list, then
> it uses *call_rcu* to postpose freeing the node, i.e, the node is only returned
> to the pcpu_freelist when the rcu callback is executed. This is needed because
> an element returned by the pop() operation should remain valid for the whole
> duration of the eBPF program.
>
> The problem is that elements are not immediately returned to the free list, so
> in some cases the push operation could fail because there are not free nodes
> in the pcpu_freelist.
>
> The following code snippet exposes that problem.
>
> ...
> /* Push MAP_SIZE elements */
> for (i = 0; i < MAP_SIZE; i++)
> assert(bpf_map_update_elem(fd, NULL, &vals[i], 0) == 0);
>
> /* Pop all elements */
> for (i = 0; i < MAP_SIZE; i++)
> assert(bpf_map_lookup_and_delete_elem(fd, NULL, &val) == 0 &&
> val == vals[i]);
>
> // sleep(1) <-- If I put this sleep, everything works.
> /* Push MAP_SIZE elements */
> for (i = 0; i < MAP_SIZE; i++)
> assert(bpf_map_update_elem(fd, NULL, &vals[i], 0) == 0);
> ^^^
> This fails because there are not available elements in pcpu_freelist
> ...
>
> I think a possible solution is to oversize the pcpu_freelist (no idea by how
> much, maybe double or, or make it 1.5 time the max elements in the map?)
> I also have concerns about it, it would waste that memory in many cases and
> this is also probably that it doesn't solve the issue because that code snippet
> is puhsing and popping elements too fast, so even if the pcpu_freelist is much
> large a certain time instant all the elements could be used.
>
> Is this really an important issue?
> Any idea of how to solve it?
It is important issue indeed and a difficult one to solve.
We have the same issue with hash map.
If the prog is doing:
value = lookup(key);
delete(key);
// here the prog shouldn't be accessing the value anymore, since the memory
// could have been reused, but value pointer is still valid and points to
// allocated memory
bpf_map_pop_elem() is trying to do lookup_and_delete and preserve
validity of value without races.
With pcpu_freelist I don't think there is a solution.
We can have this queue/stack map without prealloc and use kmalloc/kfree
back and forth. Performance will not be as great, but for your use case,
I suspect, it will be good enough.
The key issue with kmalloc/kfree is unbounded time of rcu callbacks.
If somebody starts doing push/pop for every packet, the rcu subsystem
will struggle and nothing we can do about it.
The only way I could think of to resolve this problem is to reuse
the logic that Joe is working on for socket lookups inside the program.
Joe,
how is that going? Could you repost the latest patches?
In such case the api for stack map will look like:
elem = bpf_map_pop_elem(stack);
// access elem
bpf_map_free_elem(elem);
// here prog is not allowed to access elem and verifier will catch that
elem = bpf_map_alloc_elem(stack);
// populate elem
bpf_map_push_elem(elem);
// here prog is not allowed to access elem and verifier will catch that
Then both pre-allocated elems and kmalloc/kfree will work fine
and no unbounded rcu issues in both cases.
^ permalink raw reply
* Re: [PATCH iproute2] bridge/mdb: fix missing new line when show bridge mdb
From: Hangbin Liu @ 2018-09-07 0:14 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, David Ahern
In-Reply-To: <20180906140053.0778cee3@shemminger-XPS-13-9360>
Hi Stephen,
On Thu, Sep 06, 2018 at 02:00:53PM +0100, Stephen Hemminger wrote:
> > @@ -164,6 +168,10 @@ static void print_mdb_entry(FILE *f, int ifindex, const struct br_mdb_entry *e,
> > print_string(PRINT_ANY, "timer", " %s",
> > format_timer(timer));
> > }
> > +
> > + if (!is_json_context())
> > + fprintf(f, "\n");
> > +
> > close_json_object();
> > }
> >
>
> Thanks for catching this.
>
> Now that there is a json print library, the preferred pattern for
> this is:
> print_string(PRINT_FP, NULL, "\n", NULL);
Are we going to replace all printf() by json print library, even not in
json context? If yes, I can post a v2 patch. Becuase there are still a
lot fprintf() in mdb.c.
>
> I plan to introduce a helper
> print_fp(...)
>
> and it would be easier if all places were consistent.
cool, that would be more clear.
Thanks
Hangbin
^ permalink raw reply
* Re: [bpf-next 1/3] flow_dissector: implements flow dissector BPF hook
From: Petar Penkov @ 2018-09-07 0:18 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Petar Penkov, Networking, David S . Miller, Alexei Starovoitov,
simon.horman, ecree, songliubraving, Tom Herbert,
Willem de Bruijn
In-Reply-To: <CAG4SDVVJZwsqzkc3SCmtsSX41L6yv5nncVWwQSw0Qo7EnFV7Tg@mail.gmail.com>
On Mon, Sep 3, 2018 at 1:54 PM, Petar Penkov <ppenkov@google.com> wrote:
>
> On Sun, Sep 2, 2018 at 2:03 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> > On 08/30/2018 08:22 PM, Petar Penkov wrote:
> >> From: Petar Penkov <ppenkov@google.com>
> >>
> >> Adds a hook for programs of type BPF_PROG_TYPE_FLOW_DISSECTOR and
> >> attach type BPF_FLOW_DISSECTOR that is executed in the flow dissector
> >> path. The BPF program is per-network namespace.
> >>
> >> Signed-off-by: Petar Penkov <ppenkov@google.com>
> >> Signed-off-by: Willem de Bruijn <willemb@google.com>
> > [...]
> >> + err = check_flow_keys_access(env, off, size);
> >> + if (!err && t == BPF_READ && value_regno >= 0)
> >> + mark_reg_unknown(env, regs, value_regno);
> >> } else {
> >> verbose(env, "R%d invalid mem access '%s'\n", regno,
> >> reg_type_str[reg->type]);
> >> @@ -1925,6 +1954,8 @@ static int check_helper_mem_access(struct bpf_verifier_env *env, int regno,
> >> case PTR_TO_PACKET_META:
> >> return check_packet_access(env, regno, reg->off, access_size,
> >> zero_size_allowed);
> >> + case PTR_TO_FLOW_KEYS:
> >> + return check_flow_keys_access(env, reg->off, access_size);
> >> case PTR_TO_MAP_VALUE:
> >> return check_map_access(env, regno, reg->off, access_size,
> >> zero_size_allowed);
> >> @@ -3976,6 +4007,7 @@ static bool may_access_skb(enum bpf_prog_type type)
> >> case BPF_PROG_TYPE_SOCKET_FILTER:
> >> case BPF_PROG_TYPE_SCHED_CLS:
> >> case BPF_PROG_TYPE_SCHED_ACT:
> >> + case BPF_PROG_TYPE_FLOW_DISSECTOR:
> >> return true;
> >
> > This one should not be added here. It would allow for LD_ABS to be used, but
> > you already have direct packet access as well as bpf_skb_load_bytes() helper
> > enabled. Downside on LD_ABS is that error path will exit the BPF prog with
> > return 0 for historical reasons w/o user realizing (here: to BPF_OK mapping).
> > So we should not encourage use of LD_ABS/IND anymore in eBPF context and
> > avoid surprises.
> >
> >> default:
> >> return false;
> >> @@ -4451,6 +4483,7 @@ static bool regsafe(struct bpf_reg_state *rold, struct bpf_reg_state *rcur,
> >> case PTR_TO_CTX:
> >> case CONST_PTR_TO_MAP:
> >> case PTR_TO_PACKET_END:
> >> + case PTR_TO_FLOW_KEYS:
> >> /* Only valid matches are exact, which memcmp() above
> >> * would have accepted
> >> */
> >> diff --git a/net/core/filter.c b/net/core/filter.c
> >> index c25eb36f1320..0143b9c0c67e 100644
> >> --- a/net/core/filter.c
> >> +++ b/net/core/filter.c
> >> @@ -5092,6 +5092,17 @@ sk_skb_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
> >> }
> >> }
> >>
> >> +static const struct bpf_func_proto *
> >> +flow_dissector_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
> >> +{
> >> + switch (func_id) {
> >> + case BPF_FUNC_skb_load_bytes:
> >> + return &bpf_skb_load_bytes_proto;
> >
> > Probably makes sense to also enable bpf_skb_pull_data helper for direct packet
> > access use to fetch non-linear data from here once.
On closer look, it turns out that __skb_flow_dissect takes a const skb
pointer, which conflicts with the realloc in bpf_skb_pull_data. But,
we also don't need it if I change bpf_flow_dissect_get_header to try
bpf_skb_load_bytes when direct packet access fails. This is very
similar to the existing use of __skb_header_pointer. See the below
snippet:
static __always_inline void *bpf_flow_dissect_get_header(struct __sk_buff *skb,
__u16 hdr_size,
void *buffer)
{
struct bpf_dissect_cb *cb = (struct bpf_dissect_cb *)(skb->cb);
void *data_end = (__u8 *)(long)skb->data_end;
void *data = (__u8 *)(long)skb->data;
__u8 *hdr;
/* Verifies this variable offset does not overflow */
if (cb->nhoff > (USHRT_MAX - hdr_size))
return NULL;
hdr = data + cb->nhoff;
if (hdr + hdr_size <= data_end)
return hdr;
if (bpf_skb_load_bytes(skb, cb->nhoff, buffer, hdr_size))
return NULL;
return buffer;
}
> >
> >> + default:
> >> + return bpf_base_func_proto(func_id);
> >> + }
> >> +}
> >> +
> >> static const struct bpf_func_proto *
> >> lwt_out_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
> >> {
> >> @@ -5207,6 +5218,7 @@ static bool bpf_skb_is_valid_access(int off, int size, enum bpf_access_type type
> >> case bpf_ctx_range(struct __sk_buff, data):
> >> case bpf_ctx_range(struct __sk_buff, data_meta):
> >> case bpf_ctx_range(struct __sk_buff, data_end):
> >> + case bpf_ctx_range(struct __sk_buff, flow_keys):
> >> if (size != size_default)
> >> return false;
> >> break;
> >> @@ -5235,6 +5247,7 @@ static bool sk_filter_is_valid_access(int off, int size,
> >> case bpf_ctx_range(struct __sk_buff, data):
> >> case bpf_ctx_range(struct __sk_buff, data_meta):
> >> case bpf_ctx_range(struct __sk_buff, data_end):
> >> + case bpf_ctx_range(struct __sk_buff, flow_keys):
> >> case bpf_ctx_range_till(struct __sk_buff, family, local_port):
> > [...]
> > Thanks,
> > Daniel
>
> Thank you for your feedback, Daniel! I'll make these changes and submit a v2.
> Petar
^ permalink raw reply
* [PATCH bpf-next 0/2] bpf: add bpffs/bpftool dump for prog_array and map_in_map maps
From: Yonghong Song @ 2018-09-07 0:26 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team
The support to dump program array and map_in_map maps
for bpffs and bpftool is added. Patch #1 added bpffs support
and Patch #2 added bpftool support. Please see
individual patches for example output.
Yonghong Song (2):
bpf: add bpffs pretty print for program array map
tools/bpf: bpftool: support prog array map and map of maps
kernel/bpf/arraymap.c | 25 ++++++++++++++++++++++++-
tools/bpf/bpftool/map.c | 11 +++--------
2 files changed, 27 insertions(+), 9 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH bpf-next 2/2] tools/bpf: bpftool: support prog array map and map of maps
From: Yonghong Song @ 2018-09-07 0:26 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team
In-Reply-To: <20180907002605.1408960-1-yhs@fb.com>
Currently, prog array map and map of maps are not supported
in bpftool. This patch added the support.
Different from other map types, for prog array map and
map of maps, the key returned bpf_get_next_key() may not
point to a valid value. So for these two map types,
no error will be printed out when such a scenario happens.
The following is the plain and json dump if btf is not available:
$ ./bpftool map dump id 10
key: 08 00 00 00 value: 5c 01 00 00
Found 1 element
$ ./bpftool -jp map dump id 10
[{
"key": ["0x08","0x00","0x00","0x00"
],
"value": ["0x5c","0x01","0x00","0x00"
]
}]
If the BTF is available, the dump looks below:
$ ./bpftool map dump id 2
[{
"key": 0,
"value": 7
}
]
$ ./bpftool -jp map dump id 2
[{
"key": ["0x00","0x00","0x00","0x00"
],
"value": ["0x07","0x00","0x00","0x00"
],
"formatted": {
"key": 0,
"value": 7
}
}]
Signed-off-by: Yonghong Song <yhs@fb.com>
---
tools/bpf/bpftool/map.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index 9c55077ca5dd..af8ad32fa6e9 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -673,12 +673,6 @@ static int do_dump(int argc, char **argv)
if (fd < 0)
return -1;
- if (map_is_map_of_maps(info.type) || map_is_map_of_progs(info.type)) {
- p_err("Dumping maps of maps and program maps not supported");
- close(fd);
- return -1;
- }
-
key = malloc(info.key_size);
value = alloc_value(&info);
if (!key || !value) {
@@ -732,7 +726,9 @@ static int do_dump(int argc, char **argv)
} else {
print_entry_plain(&info, key, value);
}
- } else {
+ num_elems++;
+ } else if (!map_is_map_of_maps(info.type) &&
+ !map_is_map_of_progs(info.type)) {
if (json_output) {
jsonw_name(json_wtr, "key");
print_hex_data_json(key, info.key_size);
@@ -749,7 +745,6 @@ static int do_dump(int argc, char **argv)
}
prev_key = key;
- num_elems++;
}
if (json_output)
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 1/2] bpf: add bpffs pretty print for program array map
From: Yonghong Song @ 2018-09-07 0:26 UTC (permalink / raw)
To: ast, daniel, netdev; +Cc: kernel-team
In-Reply-To: <20180907002605.1408960-1-yhs@fb.com>
Added bpffs pretty print for program array map. For a particular
array index, if the program array points to a valid program,
the "<index>: <prog_id>" will be printed out like
0: 6
which means bpf program with id "6" is installed at index "0".
Signed-off-by: Yonghong Song <yhs@fb.com>
---
kernel/bpf/arraymap.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index f9d24121be99..dded84cbe814 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -553,6 +553,29 @@ static void bpf_fd_array_map_clear(struct bpf_map *map)
fd_array_map_delete_elem(map, &i);
}
+static void prog_array_map_seq_show_elem(struct bpf_map *map, void *key,
+ struct seq_file *m)
+{
+ void **elem, *ptr;
+ u32 prog_id;
+
+ rcu_read_lock();
+
+ elem = array_map_lookup_elem(map, key);
+ if (elem) {
+ ptr = READ_ONCE(*elem);
+ if (ptr) {
+ seq_printf(m, "%u: ", *(u32 *)key);
+ prog_id = prog_fd_array_sys_lookup_elem(ptr);
+ btf_type_seq_show(map->btf, map->btf_value_type_id,
+ &prog_id, m);
+ seq_puts(m, "\n");
+ }
+ }
+
+ rcu_read_unlock();
+}
+
const struct bpf_map_ops prog_array_map_ops = {
.map_alloc_check = fd_array_map_alloc_check,
.map_alloc = array_map_alloc,
@@ -564,7 +587,7 @@ const struct bpf_map_ops prog_array_map_ops = {
.map_fd_put_ptr = prog_fd_array_put_ptr,
.map_fd_sys_lookup_elem = prog_fd_array_sys_lookup_elem,
.map_release_uref = bpf_fd_array_map_clear,
- .map_check_btf = map_check_no_btf,
+ .map_seq_show_elem = prog_array_map_seq_show_elem,
};
static struct bpf_event_entry *bpf_event_entry_gen(struct file *perf_file,
--
2.17.1
^ permalink raw reply related
* Re: [**EXTERNAL**] Re: VRF with enslaved L3 enabled bridge
From: David Ahern @ 2018-09-07 0:26 UTC (permalink / raw)
To: D'Souza, Nelson, netdev@vger.kernel.org
In-Reply-To: <870CEE3F-48B1-448A-B986-FF0EF5140980@ciena.com>
On 9/5/18 12:00 PM, D'Souza, Nelson wrote:
> Just following up.... would you be able to confirm that this is a Linux VRF issue?
I can confirm that I can reproduce the problem. Need to find time to dig
into it.
^ permalink raw reply
* Re: linux-next: build failure after merge of the bpf-next tree
From: Björn Töpel @ 2018-09-07 5:21 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: sfr, Daniel Borkmann, ast, Netdev, linux-next, LKML,
Björn Töpel
In-Reply-To: <20180907002223.tpizglyhrwn26oox@ast-mbp.dhcp.thefacebook.com>
Den fre 7 sep. 2018 kl 02:23 skrev Alexei Starovoitov
<alexei.starovoitov@gmail.com>:
>
> On Fri, Sep 07, 2018 at 10:19:23AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the bpf-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > ERROR: ".xsk_reuseq_swap" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
> > ERROR: ".xsk_reuseq_free" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
> > ERROR: ".xsk_reuseq_prepare" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined
> >
> > Caused by commit
> >
> > 9654bd10da60 ("i40e: clean zero-copy XDP Rx ring on shutdown/reset")
> >
> > CONFIG_XDP_SOCKETS is not set for this build.
> >
> > I have used the version of the bfp-next tree from next-20180906 for today.
>
> merge conflict and build error...
> Bjorn, I'm thinking to toss the patches out of bpf-next and reapply
> cleaned up version of the patches...
> what do you think?
>
Yes, do that. I'll get back with a cleaned up v2.
Thanks,
Björn
^ permalink raw reply
* [PATCH] PCI: Reprogram bridge prefetch registers on resume
From: Daniel Drake @ 2018-09-07 5:36 UTC (permalink / raw)
To: bhelgaas-hpIqsD4AKlfQT0dZR+AlfA
Cc: mika.westerberg-VuQAYsv1563Yd54FQh9/CA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, linux-pci-u79uwXL29TY76Z2rM5mHXA,
rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w,
nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
keith.busch-ral2JQCrhuEAvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
linux-6IF/jdPJHihWk0Htik3J/w, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
jonathan.derrick-ral2JQCrhuEAvxtiuMwx3w,
hkallweit1-Re5JQEeQqe8AvxtiuMwx3w
On 38+ Intel-based Asus products, the nvidia GPU becomes unusable
after S3 suspend/resume. The affected products include multiple
generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs
many errors such as:
fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04 [HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown]
DRM: failed to idle channel 0 [DRM]
Similarly, the nvidia proprietary driver also fails after resume
(black screen, 100% CPU usage in Xorg process). We shipped a sample
to Nvidia for diagnosis, and their response indicated that it's a
problem with the parent PCI bridge (on the Intel SoC), not the GPU.
Runtime suspend/resume works fine, only S3 suspend is affected.
We found a workaround: on resume, rewrite the Intel PCI bridge
'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32). In
the cases that I checked, this register has value 0 and we just have to
rewrite that value.
It's very strange that rewriting the exact same register value
makes a difference, but it definitely makes the issue go away.
It's not just acting as some kind of memory barrier, because rewriting
other bridge registers does not work around the issue. There's something
magic in this particular register. We have confirmed this on all
the affected models we have in-hands (X542UQ, UX533FD, X530UN, V272UN).
Additionally, this workaround solves an issue where r8169 MSI-X
interrupts were broken after S3 suspend/resume on Asus X441UAR. This
issue was recently worked around in commit 7bb05b85bc2d ("r8169:
don't use MSI-X on RTL8106e"). It also fixes the same issue on
RTL6186evl/8111evl on an Aimfor-tech laptop that we had not yet
patched. I suspect it will also fix the issue that was worked around in
commit 7c53a722459c ("r8169: don't use MSI-X on RTL8168g").
Thomas Martitz reports that this workaround also solves an issue where
the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive
after S3 suspend/resume.
From our testing, the affected Intel PCI bridges are:
Intel Skylake PCIe Controller (x16) [8086:1901] (rev 05)
Intel Skylake PCIe Controller (x16) [8086:1901] (rev 07)
Intel Device [8086:31d8] (rev f3)
Intel Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port B #1 [8086:5ad6] (rev fb)
Intel Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #1 [8086:5ad8] (rev fb)
Intel Sunrise Point-LP PCI Express Root Port [8086:9d10] (rev f1)
Intel Sunrise Point-LP PCI Express Root Port #5 [8086:9d14] (rev f1)
Intel Device [8086:9dbc] (rev f0)
On resume, reprogram the PCI bridge prefetch registers, including the
magic register mentioned above.
This matches Win10 behaviour, which also rewrites these registers
during S3 resume (checked with qemu tracing).
Link: https://marc.info/?i=CAD8Lp46Y2eOR7WE28xToUL8s-aYiqPa0nS=1GSD0AxkddXq6+A@mail.gmail.com
Link: https://bugs.freedesktop.org/show_bug.cgi?id=105760
Signed-off-by: Daniel Drake <drake@endlessm.com>
---
Notes:
Replaces patch:
PCI: add prefetch quirk to work around Asus/Nvidia suspend issues
Below is the list of Asus products with Intel/Nvidia that we
believe are affected by the GPU resume issue.
I revised my counting method from my last patch to eliminate duplicate
platforms that had multiple SKUs with the same DMI/GPU/bridge, that's why
the product count reduced from 43 to 38.
sys_vendor: ASUSTeK COMPUTER INC.
board_name: FX502VD
product_name: FX502VD
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev ff) (prog-if ff)
!!! Unknown header type 7f
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901] (rev 05) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: FX570UD
product_name: ASUS Gaming FX570UD
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev a1)
Subsystem: ASUSTeK Computer Inc. Device [1043:1f40]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: GL553VD
product_name: GL553VD
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev a1)
Subsystem: ASUSTeK Computer Inc. Device [1043:15e0]
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901] (rev 05) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: GL753VD
product_name: GL753VD
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev a1)
Subsystem: ASUSTeK Computer Inc. Device [1043:1590]
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901] (rev 05) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: K401UQK
product_name: K401UQK
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134d] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:14b0]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: P1440UF
product_name: ASUSPRO P1440UF
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:174d] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:1f10]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: P2440UQ
product_name: P2440UQ
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134d] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:13ce]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: P2540NV
product_name: P2540NV
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134f] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:17f0]
00:13.0 PCI bridge [0604]: Intel Corporation Device [8086:5ad8] (rev fb) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: P2540UV
product_name: P2540UV
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134f] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:132e]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: P4540UQ
product_name: P4540UQ
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134d] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:1650]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: UX331UN
product_name: UX331UN
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1d12] (rev a1)
Subsystem: ASUSTeK Computer Inc. Device [1043:15de]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: UX410UQK
product_name: UX410UQK
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134d] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:138e]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: UX430UQ
product_name: UX430UQ
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134d] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:139e]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: UX533FD
product_name: ZenBook UX533FD_UX533FD
02:00.0 3D controller [0302]: NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] [10de:1c8d] (rev a1)
Subsystem: ASUSTeK Computer Inc. GP107M [GeForce GTX 1050 Mobile] [1043:14a1]
00:1c.4 PCI bridge [0604]: Intel Corporation Device [8086:9dbc] (rev f0) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: V221ID
product_name: V221ID
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134f] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:15f0]
00:13.0 PCI bridge [0604]: Intel Corporation Device [8086:5ad8] (rev fb) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: V272UN
product_name: Vivo AIO 27 V272UN
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1d10] (rev a1)
Subsystem: ASUSTeK Computer Inc. Device [1043:17be]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X430UN
product_name: VivoBook S14 X430UN
01:00.0 3D controller [0302]: NVIDIA Corporation GP108M [GeForce MX150] [10de:1d10] (rev a1)
Subsystem: ASUSTeK Computer Inc. GP108M [GeForce MX150] [1043:199e]
00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X441MB
product_name: X441MB
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:174e] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:171e]
00:13.0 PCI bridge [0604]: Intel Corporation Device [8086:31d8] (rev f3) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X456UF
product_name: X456UF
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1346] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:245a]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X510UQ
product_name: X510UQ
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134d] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:145e]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X530UN
product_name: VivoBook S15 X530UN
01:00.0 3D controller [0302]: NVIDIA Corporation GP108M [GeForce MX150] [10de:1d10] (rev a1)
Subsystem: ASUSTeK Computer Inc. GP108M [GeForce MX150] [1043:18ce]
00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X541UV
product_name: X541UV
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134f] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:11ee]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X542UN
product_name: X542UN
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1d10] (rev a1)
Subsystem: ASUSTeK Computer Inc. Device [1043:1b10]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X542UQ
product_name: X542UQ
01:00.0 3D controller [0302]: NVIDIA Corporation GM108M [GeForce 940MX] [10de:134d] (rev a2)
Subsystem: ASUSTeK Computer Inc. GM108M [GeForce 940MX] [1043:142e]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X555UB
product_name: X555UB
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1347] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:246a]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X555UQ
product_name: X555UQ
01:00.0 3D controller [0302]: NVIDIA Corporation GM108M [GeForce 940MX] [10de:134d] (rev a2)
Subsystem: ASUSTeK Computer Inc. GM108M [GeForce 940MX] [1043:246a]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X556URK
product_name: X556URK
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134e] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:1490]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X570ZD
product_name: VivoBook_ASUS Laptop X570ZD
01:00.0 3D controller [0302]: NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] [10de:1c8d] (rev a1)
Subsystem: ASUSTeK Computer Inc. GP107M [GeForce GTX 1050 Mobile] [1043:11d1]
00:01.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:15d3] (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X580GD
product_name: VivoBook_ASUSLaptop X580GD_X580GD
01:00.0 3D controller [0302]: NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] [10de:1c8d] (rev a1)
Subsystem: ASUSTeK Computer Inc. GP107M [GeForce GTX 1050 Mobile] [1043:1fc0]
00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe Controller (x16) [8086:1901] (rev 07) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X580VD
product_name: X580VD
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev a1)
Subsystem: ASUSTeK Computer Inc. Device [1043:1a10]
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901] (rev 05) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X705FD
product_name: VivoBook Pro 17 X705FD_X705FD
02:00.0 3D controller [0302]: NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] [10de:1c8d] (rev a1)
Subsystem: ASUSTeK Computer Inc. GP107M [GeForce GTX 1050 Mobile] [1043:1431]
00:1c.4 PCI bridge [0604]: Intel Corporation Device [8086:9dbc] (rev f0) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X705UD
product_name: X705UD
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev a1)
Subsystem: ASUSTeK Computer Inc. Device [1043:1b30]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X705UQ
product_name: X705UQ
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134d] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:148e]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: X751NV
product_name: X751NV
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134f] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:13be]
00:13.0 PCI bridge [0604]: Intel Corporation Device [8086:5ad8] (rev fb) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: Z240IE
product_name: Z240IE
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1c8d] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device [1043:1750]
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901] (rev 05) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: ZN220IC-K
product_name: ZN220IC-K
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134e] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:117e]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: ZN241IC
product_name: ZN241IC
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134d] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:1900]
00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode])
sys_vendor: ASUSTeK COMPUTER INC.
board_name: ZN270IE
product_name: ZN270IE
01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134d] (rev a2)
Subsystem: ASUSTeK Computer Inc. Device [1043:1720]
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901] (rev 05) (prog-if 00 [Normal decode])
drivers/pci/pci-driver.c | 14 ++++++++++++++
drivers/pci/setup-bus.c | 2 +-
include/linux/pci.h | 1 +
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index bef17c3fca67..034f816570ad 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -524,6 +524,20 @@ static void pci_pm_default_resume_early(struct pci_dev *pci_dev)
pci_power_up(pci_dev);
pci_restore_state(pci_dev);
pci_pme_restore(pci_dev);
+
+ /*
+ * Redo the PCI bridge prefetch register setup.
+ *
+ * This works around an Intel PCI bridge issue seen on Asus and HP
+ * laptops, where the GPU is not usable after S3 resume.
+ * Even though PCI bridge register contents appear to be intact
+ * at resume time, rewriting the value of PREF_BASE_UPPER32 is
+ * required to make the GPU work.
+ * Windows 10 also reprograms these registers during S3 resume.
+ */
+ if (pci_dev->class == PCI_CLASS_BRIDGE_PCI << 8)
+ pci_setup_bridge_mmio_pref(pci_dev);
+
pci_fixup_device(pci_fixup_resume_early, pci_dev);
}
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 79b1824e83b4..cb88288d2a69 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -630,7 +630,7 @@ static void pci_setup_bridge_mmio(struct pci_dev *bridge)
pci_write_config_dword(bridge, PCI_MEMORY_BASE, l);
}
-static void pci_setup_bridge_mmio_pref(struct pci_dev *bridge)
+void pci_setup_bridge_mmio_pref(struct pci_dev *bridge)
{
struct resource *res;
struct pci_bus_region region;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index e72ca8dd6241..b15828fc26a4 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -934,6 +934,7 @@ struct pci_dev *pci_scan_single_device(struct pci_bus *bus, int devfn);
void pci_device_add(struct pci_dev *dev, struct pci_bus *bus);
unsigned int pci_scan_child_bus(struct pci_bus *bus);
void pci_bus_add_device(struct pci_dev *dev);
+void pci_setup_bridge_mmio_pref(struct pci_dev *bridge);
void pci_read_bridge_bases(struct pci_bus *child);
struct resource *pci_find_parent_resource(const struct pci_dev *dev,
struct resource *res);
--
2.17.1
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: marvell,prestera: Add common compatible string
From: Chris Packham @ 2018-09-07 0:59 UTC (permalink / raw)
To: robh+dt, gregory.clement
Cc: jason, davem, andrew, sebastian.hesselbarth, devicetree,
linux-arm-kernel, linux-kernel, netdev, Chris Packham,
Mark Rutland
In-Reply-To: <20180907005926.27134-1-chris.packham@alliedtelesis.co.nz>
Add "marvell,prestera" as a compatible string so that drivers can be
written to account for any prestera variant without needing to
specialise to the more specific values.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
Documentation/devicetree/bindings/net/marvell,prestera.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/marvell,prestera.txt b/Documentation/devicetree/bindings/net/marvell,prestera.txt
index c329608fa887..83370ebf5b89 100644
--- a/Documentation/devicetree/bindings/net/marvell,prestera.txt
+++ b/Documentation/devicetree/bindings/net/marvell,prestera.txt
@@ -2,7 +2,7 @@ Marvell Prestera Switch Chip bindings
-------------------------------------
Required properties:
-- compatible: one of the following
+- compatible: must be "marvell,prestera" and one of the following
"marvell,prestera-98dx3236",
"marvell,prestera-98dx3336",
"marvell,prestera-98dx4251",
@@ -21,7 +21,7 @@ switch {
ranges = <0 MBUS_ID(0x03, 0x00) 0 0x100000>;
packet-processor@0 {
- compatible = "marvell,prestera-98dx3236";
+ compatible = "marvell,prestera-98dx3236", "marvell,prestera";
reg = <0 0x4000000>;
interrupts = <33>, <34>, <35>;
dfx = <&dfx>;
--
2.18.0
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: mvebu: add "marvell,prestera" to PP nodes
From: Chris Packham @ 2018-09-07 0:59 UTC (permalink / raw)
To: robh+dt, gregory.clement
Cc: jason, davem, andrew, sebastian.hesselbarth, devicetree,
linux-arm-kernel, linux-kernel, netdev, Chris Packham,
Mark Rutland
In-Reply-To: <20180907005926.27134-1-chris.packham@alliedtelesis.co.nz>
The compatible string "marvell,prestera" allows drivers to have code
common to any prestera variant.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-98dx3336.dtsi | 2 +-
arch/arm/boot/dts/armada-xp-98dx4251.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
index 8d708cc22495..2185ea58abfe 100644
--- a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
+++ b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
@@ -243,7 +243,7 @@
ranges = <0 MBUS_ID(0x03, 0x00) 0 0x100000>;
pp0: packet-processor@0 {
- compatible = "marvell,prestera-98dx3236";
+ compatible = "marvell,prestera-98dx3236", "marvell,prestera";
reg = <0 0x4000000>;
interrupts = <33>, <34>, <35>;
dfx = <&dfx>;
diff --git a/arch/arm/boot/dts/armada-xp-98dx3336.dtsi b/arch/arm/boot/dts/armada-xp-98dx3336.dtsi
index 2f5fc67dd6dc..1d9d8a8ea60c 100644
--- a/arch/arm/boot/dts/armada-xp-98dx3336.dtsi
+++ b/arch/arm/boot/dts/armada-xp-98dx3336.dtsi
@@ -35,5 +35,5 @@
};
&pp0 {
- compatible = "marvell,prestera-98dx3336";
+ compatible = "marvell,prestera-98dx3336", "marvell,prestera";
};
diff --git a/arch/arm/boot/dts/armada-xp-98dx4251.dtsi b/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
index 7a9e8839880b..48ffdc72bfc7 100644
--- a/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
+++ b/arch/arm/boot/dts/armada-xp-98dx4251.dtsi
@@ -49,6 +49,6 @@
};
&pp0 {
- compatible = "marvell,prestera-98dx4251";
+ compatible = "marvell,prestera-98dx4251", "marvell,prestera";
interrupts = <33>, <34>, <35>, <36>;
};
--
2.18.0
^ permalink raw reply related
* Re: linux-next: build failure after merge of the bpf-next tree
From: Alexei Starovoitov @ 2018-09-07 5:45 UTC (permalink / raw)
To: Björn Töpel
Cc: sfr, Daniel Borkmann, ast, Netdev, linux-next, LKML,
Björn Töpel
In-Reply-To: <CAJ+HfNgRd5ztzwJ9HtgnrDyf8F0ykODY_EGC91d9KiAfDbhcXA@mail.gmail.com>
On Fri, Sep 07, 2018 at 07:21:05AM +0200, Björn Töpel wrote:
> Den fre 7 sep. 2018 kl 02:23 skrev Alexei Starovoitov
> <alexei.starovoitov@gmail.com>:
> >
> > On Fri, Sep 07, 2018 at 10:19:23AM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the bpf-next tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> > >
> > > ERROR: ".xsk_reuseq_swap" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
> > > ERROR: ".xsk_reuseq_free" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined!
> > > ERROR: ".xsk_reuseq_prepare" [drivers/net/ethernet/intel/i40e/i40e.ko] undefined
> > >
> > > Caused by commit
> > >
> > > 9654bd10da60 ("i40e: clean zero-copy XDP Rx ring on shutdown/reset")
> > >
> > > CONFIG_XDP_SOCKETS is not set for this build.
> > >
> > > I have used the version of the bfp-next tree from next-20180906 for today.
> >
> > merge conflict and build error...
> > Bjorn, I'm thinking to toss the patches out of bpf-next and reapply
> > cleaned up version of the patches...
> > what do you think?
> >
>
> Yes, do that. I'll get back with a cleaned up v2.
Done.
Unfortunately during interactive rebase that removed your commits git didn't
preserve merge commits that came after yours,
so Jesper's and Yonghong's cover letters are not in the git history.
Yet all patches are in the same order.
Explicit revert with trail in the git history would have been worse.
patchworks + git isn't the most convenient workflow. sigh.
^ 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