* Re: [PATCH, net-next] net/mlx5e: fix TLS dependency
From: Saeed Mahameed @ 2018-05-25 23:18 UTC (permalink / raw)
To: davem@davemloft.net, arnd@arndb.de, leon@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
Boris Pismenny, Or Gerlitz, Feras Daoud, Ilan Tayari,
netdev@vger.kernel.org, Ilya Lesokhin
In-Reply-To: <20180525213630.2119214-1-arnd@arndb.de>
On Fri, 2018-05-25 at 23:36 +0200, Arnd Bergmann wrote:
> With CONFIG_TLS=m and MLX5_CORE_EN=y, we get a link failure:
>
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls_rxtx.o: In
> function `mlx5e_tls_handle_ooo':
> tls_rxtx.c:(.text+0x24c): undefined reference to `tls_get_record'
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls_rxtx.o: In
> function `mlx5e_tls_handle_tx_skb':
> tls_rxtx.c:(.text+0x9a8): undefined reference to
> `tls_device_sk_destruct'
>
> This narrows down the dependency to only allow the configurations
> that will actually work. The existing dependency on TLS_DEVICE is
> not sufficient here since MLX5_EN_TLS is a 'bool' symbol.
>
> Fixes: c83294b9efa5 ("net/mlx5e: TLS, Add Innova TLS TX support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
LGTM
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
Thank you Arnd!
> drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> index ee6684779d11..2545296a0c08 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> @@ -91,6 +91,7 @@ config MLX5_EN_TLS
> bool "TLS cryptography-offload accelaration"
> depends on MLX5_CORE_EN
> depends on TLS_DEVICE
> + depends on TLS=y || MLX5_CORE=m
> depends on MLX5_ACCEL
> default n
> ---help---
^ permalink raw reply
* Re: mmotm 2018-05-25-14-52 uploaded (drivers/net/ethernet/ti/davinci_mdio.c)
From: Randy Dunlap @ 2018-05-25 23:15 UTC (permalink / raw)
To: akpm, broonie, mhocko, sfr, linux-next, linux-kernel, mm-commits
Cc: Anant Gole, Chaithrika U S, netdev@vger.kernel.org
In-Reply-To: <26483e60-ab26-494c-b923-86c267cfdac0@infradead.org>
[forgot to add netdev]
On 05/25/2018 04:14 PM, Randy Dunlap wrote:
> On 05/25/2018 02:52 PM, akpm@linux-foundation.org wrote:
>> The mm-of-the-moment snapshot 2018-05-25-14-52 has been uploaded to
>>
>> http://www.ozlabs.org/~akpm/mmotm/
>>
>> mmotm-readme.txt says
>>
>> README for mm-of-the-moment:
>>
>> http://www.ozlabs.org/~akpm/mmotm/
>>
>> This is a snapshot of my -mm patch queue. Uploaded at random hopefully
>> more than once a week.
>
> on x86_64:
> # CONFIG_OF is not set
>
> CC drivers/net/ethernet/ti/davinci_cpdma.o
> ../drivers/net/ethernet/ti/davinci_mdio.c: In function 'davinci_mdio_probe':
> ../drivers/net/ethernet/ti/davinci_mdio.c:380:3: error: implicit declaration of function 'davinci_mdio_probe_dt' [-Werror=implicit-function-declaration]
> ret = davinci_mdio_probe_dt(&data->pdata, pdev);
>
>
>
>>
>> You will need quilt to apply these patches to the latest Linus release (4.x
>> or 4.x-rcY). The series file is in broken-out.tar.gz and is duplicated in
>> http://ozlabs.org/~akpm/mmotm/series
>>
>> The file broken-out.tar.gz contains two datestamp files: .DATE and
>> .DATE-yyyy-mm-dd-hh-mm-ss. Both contain the string yyyy-mm-dd-hh-mm-ss,
>> followed by the base kernel version against which this patch series is to
>> be applied.
>>
>> This tree is partially included in linux-next. To see which patches are
>> included in linux-next, consult the `series' file. Only the patches
>> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
>> linux-next.
>>
>> A git tree which contains the memory management portion of this tree is
>> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
>> by Michal Hocko. It contains the patches which are between the
>> "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
>> file, http://www.ozlabs.org/~akpm/mmotm/series.
>>
>>
>> A full copy of the full kernel tree with the linux-next and mmotm patches
>> already applied is available through git within an hour of the mmotm
>> release. Individual mmotm releases are tagged. The master branch always
>> points to the latest release, so it's constantly rebasing.
>>
>> http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/
>>
>> To develop on top of mmotm git:
>>
>> $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
>> $ git remote update mmotm
>> $ git checkout -b topic mmotm/master
>> <make changes, commit>
>> $ git send-email mmotm/master.. [...]
>>
>> To rebase a branch with older patches to a new mmotm release:
>>
>> $ git remote update mmotm
>> $ git rebase --onto mmotm/master <topic base> topic
>>
>>
>>
>>
>> The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
>> contains daily snapshots of the -mm tree. It is updated more frequently
>> than mmotm, and is untested.
>>
>> A git copy of this tree is available at
>>
>> http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/
>>
>> and use of this tree is similar to
>> http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.
>>
>>
>> This mmotm tree contains the following patches against 4.17-rc6:
>> (patches marked "*" will be included in linux-next)
>>
>
>
--
~Randy
^ permalink raw reply
* Re: [PATCH net-next v12 2/5] netvsc: refactor notifier/event handling code to use the failover framework
From: Samudrala, Sridhar @ 2018-05-25 23:11 UTC (permalink / raw)
To: Stephen Hemminger
Cc: alexander.h.duyck, virtio-dev, jiri, mst, kubakici, netdev,
virtualization, loseweigh, anjali.singhai, aaron.f.brown, davem
In-Reply-To: <20180525153456.28b44c7c@xeon-e3>
On 5/25/2018 3:34 PM, Stephen Hemminger wrote:
> On Thu, 24 May 2018 09:55:14 -0700
> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>
>> --- a/drivers/net/hyperv/Kconfig
>> +++ b/drivers/net/hyperv/Kconfig
>> @@ -2,5 +2,6 @@ config HYPERV_NET
>> tristate "Microsoft Hyper-V virtual network driver"
>> depends on HYPERV
>> select UCS2_STRING
>> + select FAILOVER
> When I take a working kernel config, add the patches then do
> make oldconfig
>
> It is not autoselecting FAILOVER, it prompts me for it. This means
> if user says no then a non-working netvsc device is made.
I see
Generic failover module (FAILOVER) [M/y/?] (NEW)
So the user is given an option to either build as a Module or part of the
kernel. 'n' is not an option.
^ permalink raw reply
* Re: [PATCH net-next v12 1/5] net: Introduce generic failover module
From: Samudrala, Sridhar @ 2018-05-25 23:06 UTC (permalink / raw)
To: Stephen Hemminger
Cc: mst, davem, netdev, virtualization, virtio-dev, jesse.brandeburg,
alexander.h.duyck, kubakici, jasowang, loseweigh, jiri,
aaron.f.brown, anjali.singhai
In-Reply-To: <20180525153843.503ee052@xeon-e3>
On 5/25/2018 3:38 PM, Stephen Hemminger wrote:
> On Thu, 24 May 2018 09:55:13 -0700
> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index 03ed492c4e14..0f4ba52b641d 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -1421,6 +1421,8 @@ struct net_device_ops {
>> * entity (i.e. the master device for bridged veth)
>> * @IFF_MACSEC: device is a MACsec device
>> * @IFF_NO_RX_HANDLER: device doesn't support the rx_handler hook
>> + * @IFF_FAILOVER: device is a failover master device
>> + * @IFF_FAILOVER_SLAVE: device is lower dev of a failover master device
>> */
>> enum netdev_priv_flags {
>> IFF_802_1Q_VLAN = 1<<0,
>> @@ -1450,6 +1452,8 @@ enum netdev_priv_flags {
>> IFF_PHONY_HEADROOM = 1<<24,
>> IFF_MACSEC = 1<<25,
>> IFF_NO_RX_HANDLER = 1<<26,
>> + IFF_FAILOVER = 1<<27,
>> + IFF_FAILOVER_SLAVE = 1<<28,
>> };
> Why is FAILOVER any different than other master/slave relationships.
> I don't think you need to take up precious netdev flag bits for this.
These are netdev priv flags.
Jiri says that IFF_MASTER/IFF_SLAVE are bonding specific flags and cannot be used
with other failover mechanisms. Team also doesn't use this flags and it has its own
priv_flags.
^ permalink raw reply
* Re: [PATCH net-next v12 1/5] net: Introduce generic failover module
From: Samudrala, Sridhar @ 2018-05-25 23:04 UTC (permalink / raw)
To: Stephen Hemminger
Cc: alexander.h.duyck, virtio-dev, jiri, mst, kubakici, netdev,
virtualization, loseweigh, anjali.singhai, aaron.f.brown, davem
In-Reply-To: <20180525153744.2b53c449@xeon-e3>
[-- Attachment #1.1: Type: text/plain, Size: 967 bytes --]
On 5/25/2018 3:37 PM, Stephen Hemminger wrote:
> On Thu, 24 May 2018 09:55:13 -0700
> Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
>
>
>> + spin_lock(&failover_lock);
> Since register is not in fast path, this should be a mutex?
This is Jiri's comment which made me to switch to spinlock from mutex
>> Why mutex? Apparently you don't need to sleep while holding a lock.
>> Simple spinlock would do.
>
>
>> +int failover_slave_unregister(struct net_device *slave_dev)
>> +{
>> + struct net_device *failover_dev;
>> + struct failover_ops *fops;
>> +
>> + if (!netif_is_failover_slave(slave_dev))
>> + goto done;
>> +
>> + ASSERT_RTNL();
>> +
>> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &fops);
>> + if (!failover_dev)
>> + goto done;
> Since the slave device must have a master device set already, why not use
> that instead of searching by MAC address on unregister or link change.
>
We also need to get the fops(failover_ops)
[-- Attachment #1.2: Type: text/html, Size: 36732 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH net-next v12 1/5] net: Introduce generic failover module
From: Stephen Hemminger @ 2018-05-25 22:38 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: mst, davem, netdev, virtualization, virtio-dev, jesse.brandeburg,
alexander.h.duyck, kubakici, jasowang, loseweigh, jiri,
aaron.f.brown, anjali.singhai
In-Reply-To: <1527180917-39737-2-git-send-email-sridhar.samudrala@intel.com>
On Thu, 24 May 2018 09:55:13 -0700
Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 03ed492c4e14..0f4ba52b641d 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1421,6 +1421,8 @@ struct net_device_ops {
> * entity (i.e. the master device for bridged veth)
> * @IFF_MACSEC: device is a MACsec device
> * @IFF_NO_RX_HANDLER: device doesn't support the rx_handler hook
> + * @IFF_FAILOVER: device is a failover master device
> + * @IFF_FAILOVER_SLAVE: device is lower dev of a failover master device
> */
> enum netdev_priv_flags {
> IFF_802_1Q_VLAN = 1<<0,
> @@ -1450,6 +1452,8 @@ enum netdev_priv_flags {
> IFF_PHONY_HEADROOM = 1<<24,
> IFF_MACSEC = 1<<25,
> IFF_NO_RX_HANDLER = 1<<26,
> + IFF_FAILOVER = 1<<27,
> + IFF_FAILOVER_SLAVE = 1<<28,
> };
Why is FAILOVER any different than other master/slave relationships.
I don't think you need to take up precious netdev flag bits for this.
^ permalink raw reply
* Re: [PATCH net-next v12 1/5] net: Introduce generic failover module
From: Stephen Hemminger @ 2018-05-25 22:37 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: mst, davem, netdev, virtualization, virtio-dev, jesse.brandeburg,
alexander.h.duyck, kubakici, jasowang, loseweigh, jiri,
aaron.f.brown, anjali.singhai
In-Reply-To: <1527180917-39737-2-git-send-email-sridhar.samudrala@intel.com>
On Thu, 24 May 2018 09:55:13 -0700
Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
> + spin_lock(&failover_lock);
Since register is not in fast path, this should be a mutex?
> +int failover_slave_unregister(struct net_device *slave_dev)
> +{
> + struct net_device *failover_dev;
> + struct failover_ops *fops;
> +
> + if (!netif_is_failover_slave(slave_dev))
> + goto done;
> +
> + ASSERT_RTNL();
> +
> + failover_dev = failover_get_bymac(slave_dev->perm_addr, &fops);
> + if (!failover_dev)
> + goto done;
Since the slave device must have a master device set already, why not use
that instead of searching by MAC address on unregister or link change.
^ permalink raw reply
* Re: [PATCH net-next v12 2/5] netvsc: refactor notifier/event handling code to use the failover framework
From: Stephen Hemminger @ 2018-05-25 22:34 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: alexander.h.duyck, virtio-dev, jiri, mst, kubakici, netdev,
virtualization, loseweigh, anjali.singhai, aaron.f.brown, davem
In-Reply-To: <1527180917-39737-3-git-send-email-sridhar.samudrala@intel.com>
On Thu, 24 May 2018 09:55:14 -0700
Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
> --- a/drivers/net/hyperv/Kconfig
> +++ b/drivers/net/hyperv/Kconfig
> @@ -2,5 +2,6 @@ config HYPERV_NET
> tristate "Microsoft Hyper-V virtual network driver"
> depends on HYPERV
> select UCS2_STRING
> + select FAILOVER
When I take a working kernel config, add the patches then do
make oldconfig
It is not autoselecting FAILOVER, it prompts me for it. This means
if user says no then a non-working netvsc device is made.
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: use data length instead of skb->len in tcp_probe
From: Song Liu @ 2018-05-25 21:59 UTC (permalink / raw)
To: Yafang Shao
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1527243245-29582-1-git-send-email-laoar.shao@gmail.com>
> On May 25, 2018, at 3:14 AM, Yafang Shao <laoar.shao@gmail.com> wrote:
>
> skb->len is meaningless to user.
> data length could be more helpful, with which we can easily filter out
> the packet without payload.
>
> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
Acked-by: Song Liu <songliubraving@fb.com>
> ---
> include/trace/events/tcp.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/trace/events/tcp.h b/include/trace/events/tcp.h
> index c1a5284..703abb6 100644
> --- a/include/trace/events/tcp.h
> +++ b/include/trace/events/tcp.h
> @@ -236,7 +236,7 @@
> __field(__u16, sport)
> __field(__u16, dport)
> __field(__u32, mark)
> - __field(__u16, length)
> + __field(__u16, data_len)
> __field(__u32, snd_nxt)
> __field(__u32, snd_una)
> __field(__u32, snd_cwnd)
> @@ -261,7 +261,7 @@
> __entry->dport = ntohs(inet->inet_dport);
> __entry->mark = skb->mark;
>
> - __entry->length = skb->len;
> + __entry->data_len = skb->len - tcp_hdrlen(skb);
> __entry->snd_nxt = tp->snd_nxt;
> __entry->snd_una = tp->snd_una;
> __entry->snd_cwnd = tp->snd_cwnd;
> @@ -272,9 +272,9 @@
> __entry->sock_cookie = sock_gen_cookie(sk);
> ),
>
> - TP_printk("src=%pISpc dest=%pISpc mark=%#x length=%d snd_nxt=%#x snd_una=%#x snd_cwnd=%u ssthresh=%u snd_wnd=%u srtt=%u rcv_wnd=%u sock_cookie=%llx",
> + TP_printk("src=%pISpc dest=%pISpc mark=%#x data_len=%d snd_nxt=%#x snd_una=%#x snd_cwnd=%u ssthresh=%u snd_wnd=%u srtt=%u rcv_wnd=%u sock_cookie=%llx",
> __entry->saddr, __entry->daddr, __entry->mark,
> - __entry->length, __entry->snd_nxt, __entry->snd_una,
> + __entry->data_len, __entry->snd_nxt, __entry->snd_una,
> __entry->snd_cwnd, __entry->ssthresh, __entry->snd_wnd,
> __entry->srtt, __entry->rcv_wnd, __entry->sock_cookie)
> );
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH bpf-next] libbpf: Install btf.h with libbpf
From: Song Liu @ 2018-05-25 21:57 UTC (permalink / raw)
To: Martin KaFai Lau; +Cc: Andrey Ignatov, netdev, ast, daniel, kernel-team
In-Reply-To: <20180525173341.yqpy3nhe4whtfm62@kafai-mbp>
On Fri, May 25, 2018 at 10:33 AM, Martin KaFai Lau <kafai@fb.com> wrote:
> On Fri, May 25, 2018 at 10:23:13AM -0700, Andrey Ignatov wrote:
>> install_headers target should contain all headers that are part of
>> libbpf. Add missing btf.h
>>
>> Signed-off-by: Andrey Ignatov <rdna@fb.com>
> Acked-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Song Liu <songliubraving@fb.com>
^ permalink raw reply
* Re: [PATCH, net-next 2/2] bpf: avoid -Wmaybe-uninitialized warning
From: Song Liu @ 2018-05-25 21:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
David S. Miller, Martin Lau, Chenbo Feng, Jakub Kicinski,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20180525213331.2115471-2-arnd@arndb.de>
> On May 25, 2018, at 2:33 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> The stack_map_get_build_id_offset() function is too long for gcc to track
> whether 'work' may or may not be initialized at the end of it, leading
> to a false-positive warning:
>
> kernel/bpf/stackmap.c: In function 'stack_map_get_build_id_offset':
> kernel/bpf/stackmap.c:334:13: error: 'work' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> This removes the 'in_nmi_ctx' flag and uses the state of that variable
> itself to see if it got initialized.
>
> Fixes: bae77c5eb5b2 ("bpf: enable stackmap with build_id in nmi context")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> kernel/bpf/stackmap.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> index b59ace0f0f09..b675a3f3d141 100644
> --- a/kernel/bpf/stackmap.c
> +++ b/kernel/bpf/stackmap.c
> @@ -285,11 +285,10 @@ static void stack_map_get_build_id_offset(struct bpf_stack_build_id *id_offs,
> {
> int i;
> struct vm_area_struct *vma;
> - bool in_nmi_ctx = in_nmi();
> bool irq_work_busy = false;
> - struct stack_map_irq_work *work;
> + struct stack_map_irq_work *work = NULL;
>
> - if (in_nmi_ctx) {
> + if (in_nmi()) {
> work = this_cpu_ptr(&up_read_work);
> if (work->irq_work.flags & IRQ_WORK_BUSY)
> /* cannot queue more up_read, fallback */
> @@ -328,7 +327,7 @@ static void stack_map_get_build_id_offset(struct bpf_stack_build_id *id_offs,
> id_offs[i].status = BPF_STACK_BUILD_ID_VALID;
> }
>
> - if (!in_nmi_ctx) {
> + if (!work) {
> up_read(¤t->mm->mmap_sem);
> } else {
> work->sem = ¤t->mm->mmap_sem;
> --
> 2.9.0
>
Acked-by: Song Liu <songliubraving@fb.com>
^ permalink raw reply
* Re: [PATCH, net-next 1/2] bpf: btf: avoid -Wreturn-type warning
From: Song Liu @ 2018-05-25 21:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alexei Starovoitov, Daniel Borkmann, Martin Lau,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20180525213331.2115471-1-arnd@arndb.de>
> On May 25, 2018, at 2:33 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> gcc warns about a noreturn function possibly returning in
> some configurations:
>
> kernel/bpf/btf.c: In function 'env_type_is_resolve_sink':
> kernel/bpf/btf.c:729:1: error: control reaches end of non-void function [-Werror=return-type]
>
> Using BUG() instead of BUG_ON() avoids that warning and otherwise
> does the exact same thing.
>
> Fixes: eb3f595dab40 ("bpf: btf: Validate type reference")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> kernel/bpf/btf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 9cbeabb5aca3..2822a0cf4f48 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -749,7 +749,7 @@ static bool env_type_is_resolve_sink(const struct btf_verifier_env *env,
> !btf_type_is_array(next_type) &&
> !btf_type_is_struct(next_type);
> default:
> - BUG_ON(1);
> + BUG();
> }
> }
>
> --
> 2.9.0
>
Acked-by: Song Liu <songliubraving@fb.com>
^ permalink raw reply
* Re: [PATCH] PCI: allow drivers to limit the number of VFs to 0
From: Bjorn Helgaas @ 2018-05-25 21:45 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Bjorn Helgaas, linux-pci, netdev, Sathya Perla, Felix Manlunas,
alexander.duyck, john.fastabend, Jacob Keller, Donald Dutile,
oss-drivers, Christoph Hellwig
In-Reply-To: <20180525140521.662a9c96@cakuba>
On Fri, May 25, 2018 at 02:05:21PM -0700, Jakub Kicinski wrote:
> On Fri, 25 May 2018 09:02:23 -0500, Bjorn Helgaas wrote:
> > On Thu, May 24, 2018 at 06:20:15PM -0700, Jakub Kicinski wrote:
> > > On Thu, 24 May 2018 18:57:48 -0500, Bjorn Helgaas wrote:
> > > > On Mon, Apr 02, 2018 at 03:46:52PM -0700, Jakub Kicinski wrote:
> > > > > Some user space depends on enabling sriov_totalvfs number of VFs
> > > > > to not fail, e.g.:
> > > > >
> > > > > $ cat .../sriov_totalvfs > .../sriov_numvfs
> > > > >
> > > > > For devices which VF support depends on loaded FW we have the
> > > > > pci_sriov_{g,s}et_totalvfs() API. However, this API uses 0 as
> > > > > a special "unset" value, meaning drivers can't limit sriov_totalvfs
> > > > > to 0. Remove the special values completely and simply initialize
> > > > > driver_max_VFs to total_VFs. Then always use driver_max_VFs.
> > > > > Add a helper for drivers to reset the VF limit back to total.
> > > >
> > > > I still can't really make sense out of the changelog.
> > > >
> > > > I think part of the reason it's confusing is because there are two
> > > > things going on:
> > > >
> > > > 1) You want this:
> > > >
> > > > pci_sriov_set_totalvfs(dev, 0);
> > > > x = pci_sriov_get_totalvfs(dev)
> > > >
> > > > to return 0 instead of total_VFs. That seems to connect with
> > > > your subject line. It means "sriov_totalvfs" in sysfs could be
> > > > 0, but I don't know how that is useful (I'm sure it is; just
> > > > educate me :))
> > >
> > > Let me just quote the bug report that got filed on our internal bug
> > > tracker :)
> > >
> > > When testing Juju Openstack with Ubuntu 18.04, enabling SR-IOV causes
> > > errors because Juju gets the sriov_totalvfs for SR-IOV-capable device
> > > then tries to set that as the sriov_numvfs parameter.
> > >
> > > For SR-IOV incapable FW, the sriov_totalvfs parameter should be 0,
> > > but it's set to max. When FW is switched to flower*, the correct
> > > sriov_totalvfs value is presented.
> > >
> > > * flower is a project name
> >
> > From the point of view of the PCI core (which knows nothing about
> > device firmware and relies on the architected config space described
> > by the PCIe spec), this sounds like an erratum: with some firmware
> > installed, the device is not capable of SR-IOV, but still advertises
> > an SR-IOV capability with "TotalVFs > 0".
> >
> > Regardless of whether that's an erratum, we do allow PF drivers to use
> > pci_sriov_set_totalvfs() to limit the number of VFs that may be
> > enabled by writing to the PF's "sriov_numvfs" sysfs file.
>
> Think more of an FPGA which can be reprogrammed at runtime to have
> different capabilities than an erratum. Some FWs simply have no use
> for VFs and save resources (and validation time) by not supporting it.
This is a bit of a gray area. Reloading firmware or reprogramming an
FPGA has the potential to create a new and different device than we
had before, but the PCI core doesn't know that. The typical sequence
is:
- PCI core enumerates device
- driver binds to device (we call .probe())
- driver loads new firmware to device
- driver resets device with pci_reset_function() or similar
- pci_reset_function() saves config space
- pci_reset_function() resets device
- device uses new firmware when it comes out of reset
- pci_reset_function() restores config space
Loading the new firmware might change what the device looks like in
config space -- it could change the number or size of BARs, the
capabilities advertised, etc. We currently sweep that under the rug
and blindly restore the old config space.
It looks like your driver does the reset differently, so maybe it
keeps the original config space setup.
But all that said, I agree that we should allow a PF driver to prevent
VF enablement, whether because the firmware doesn't support it or the
PF driver just wants to prevent use of VFs for whatever reason (maybe
we don't have enough MMIO resources, we don't need the VFs, etc.)
> Okay, perfect. That makes sense. The patch below certainly fixes the
> first issue for us. Thank you!
>
> As far as the second issue goes - agreed, having the core reset the
> number of VFs to total_VFs definitely makes sense. It doesn't cater to
> the case where FW is reloaded without reprobing, but we don't do this
> today anyway.
>
> Should I try to come up with a patch to reset total_VFs after detach?
Yes, please.
Bjorn
^ permalink raw reply
* [RFC PATCH 0/2] net: macb: Disable TX checksum offloading on all Zynq
From: Jennifer Dahm @ 2018-05-25 21:44 UTC (permalink / raw)
To: netdev, David S . Miller, Nicolas Ferre; +Cc: Nathan Sullivan, Jennifer Dahm
During testing, I discovered that the Zynq GEM hardware overwrites all
outgoing UDP packet checksums, which is illegal in packet forwarding
cases. This happens both with and without the checksum-zeroing
behavior introduced in 007e4ba3ee137f4700f39aa6dbaf01a71047c5f6
("net: macb: initialize checksum when using checksum offloading"). The
only solution to both the small packet bug and the packet forwarding
bug that I can find is to disable TX checksum offloading entirely.
There's still the possibility that these bugs are actually with the
driver software and not with the hardware. I've found several places
where the checksum is set to 0xFFFF (the incorrect checksum found in
small packets) when something goes wrong, and I can imagine a buggy
driver writing over the checksum blindly when TX checksum offloading
is enabled.
I would like feedback on two things:
1. Is it possible that the two bugs described above are caused by the
driver and not by the hardware? If so, where should I look to
implicate the driver?
2. Is this a problem we care enough about to completely disable TX
checksum offloading?
Here is the testing procedure I used to reproduce these bugs on my
machine. Specifically, without this patchset, step 9 fails. Without
007e4ba3ee, step 8 also fails.
1. Set up the test environment:
a. Acquire a Zynq device with two ethernet ports. This is the DUT.
b. Acquire a USB-Ethernet adapter.
c. Acquire two ethernet cables.
d. Connect one Ethernet port on the DUT to your computer's network
switch.
e. Connect the other Ethernet port to the USB-Ethernet adapter and
plug that adapter into your computer.
f. Set up a Linux VM to send packets through the DUT. I recommend
using a VM here so that you can easily detach it from the primary
network to force outgoing traffic through the DUT.
g. Set up a computer with a packet inspecting program to receive and
inspect packets. This doesn't need to be a VM. For the purposes
of this test, I'll be using a Windows instance with WireShark.
2. Load the kernel you want to test onto the DUT, making sure to
include the `bridge` module.
3. Set up a bridge on the DUT. The following commands on the DUT
should work, replacing `eth0` and `eth1` with the two ethernet
interfaces on the DUT:
```
brctl addbr test
brctl addif test eth0 eth1
ifconfig eth0 0.0.0.0
ifconfig eth1 0.0.0.0
dhclient test -v
```
4. Disconnect the Linux VM from your host computer's network and
connect it to the USB-Ethernet adapter in order to force outgoing
network traffic through the DUT. If necessary, run dhclient on the
Linux VM to acquire an IP address.
5. Ensure that you can reach your Windows instance from your Linux VM
through the DUT (e.g. ping).
6. Start WireShark on your Windows instance and start monitoring
traffic on a specific, unused port (e.g. 61557).
7. Using netcat, send a few not-tiny UDP packets from your Linux VM to
your Windows instance to ensure that valid UDP packets are properly
forwarded. Ex:
```
echo "hello world" | netcat -u <WindowsIP> 61557
```
Inspect these packets to ensure that the data arrived intact and
that the checksum looks reasonable (i.e. not 0x0000 or 0xFFFF).
8. Using netcat, send a few tiny UDP packets (2 bytes or fewer) from
Linux VM to your Windows instance to ensure that the checksum is
reasonable. Ex:
```
echo "h" | netcat -u <WindowsIP> 61557
```
9. Using a custom program, send UDP packets with broken checksums
(e.g. 0xABCD) from your Linux VM to your Windows instance. Inspect
these packets with WireShark and make sure that the packet arrived
with the same checksum you sent it with.
For step 9, I wrote a C program using the Linux socket API that will
send a properly formatted UDP packet with the payload "Hello!" and a
(broken) checksum of 0xABCD to port 61557 on the host provided at the
command line. I can send the full program if you would like, but here
is the important part of it:
```
struct custom_udp {
int16_t s_port;
int16_t d_port;
int16_t length;
int16_t check;
char data[];
};
int send_message(int sockfd, in_port_t port, const char *message) {
struct custom_udp *frame;
int16_t message_len;
int16_t frame_len;
int ret;
message_len = strlen(message) * sizeof(char);
frame_len = sizeof(struct custom_udp) + message_len;
frame = malloc(frame_len);
frame->s_port = htons(0);
frame->d_port = htons(port);
frame->length = htons(frame_len);
frame->check = htons(0xABCD);
memmove(frame->data, message, message_len);
ret = write(sockfd, frame, frame_len);
free(frame);
return ret;
}
```
Jennifer Dahm (1):
net/macb: Disable TX checksum offloading on all Zynq-7000
drivers/net/ethernet/cadence/macb.h | 1 +
drivers/net/ethernet/cadence/macb_main.c | 11 ++++++++---
2 files changed, 9 insertions(+), 3 deletions(-)
--
2.7.4
^ permalink raw reply
* [RFC PATCH 2/2] net: macb: Disable TX checksum offloading on all Zynq
From: Jennifer Dahm @ 2018-05-25 21:44 UTC (permalink / raw)
To: netdev, David S . Miller, Nicolas Ferre; +Cc: Nathan Sullivan, Jennifer Dahm
In-Reply-To: <1527284654-24835-1-git-send-email-jennifer.dahm@ni.com>
The Zynq ethernet hardware has checksum offloading bugs that cause
small UDP packets (<= 2 bytes) to be sent with an incorrect checksum
(0xffff) and forwarded UDP packets to be re-checksummed, which is
illegal behavior. The best solution we have right now is to disable
hardware TX checksum offloading entirely.
Signed-off-by: Jennifer Dahm <jennifer.dahm@ni.com>
---
drivers/net/ethernet/cadence/macb_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index a5d564b..e8cc68a 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -3807,7 +3807,8 @@ static const struct macb_config zynqmp_config = {
};
static const struct macb_config zynq_config = {
- .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_NO_GIGABIT_HALF,
+ .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_NO_GIGABIT_HALF
+ | MACB_CAPS_DISABLE_TX_HW_CSUM,
.dma_burst_length = 16,
.clk_init = macb_clk_init,
.init = macb_init,
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 1/2] net: macb: Add CAP to disable hardware TX checksum offloading
From: Jennifer Dahm @ 2018-05-25 21:44 UTC (permalink / raw)
To: netdev, David S . Miller, Nicolas Ferre; +Cc: Nathan Sullivan, Jennifer Dahm
In-Reply-To: <1527284654-24835-1-git-send-email-jennifer.dahm@ni.com>
Certain PHYs have significant bugs in their TX checksum offloading
that cannot be solved in software. In order to accommodate these PHYS,
add a CAP to disable this hardware.
Signed-off-by: Jennifer Dahm <jennifer.dahm@ni.com>
---
drivers/net/ethernet/cadence/macb.h | 1 +
drivers/net/ethernet/cadence/macb_main.c | 8 ++++++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 8665982..6b85e97 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -635,6 +635,7 @@
#define MACB_CAPS_USRIO_DISABLED 0x00000010
#define MACB_CAPS_JUMBO 0x00000020
#define MACB_CAPS_GEM_HAS_PTP 0x00000040
+#define MACB_CAPS_DISABLE_TX_HW_CSUM 0x00000080
#define MACB_CAPS_FIFO_MODE 0x10000000
#define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x20000000
#define MACB_CAPS_SG_DISABLED 0x40000000
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 3e93df5..a5d564b 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -3360,8 +3360,12 @@ static int macb_init(struct platform_device *pdev)
dev->hw_features |= MACB_NETIF_LSO;
/* Checksum offload is only available on gem with packet buffer */
- if (macb_is_gem(bp) && !(bp->caps & MACB_CAPS_FIFO_MODE))
- dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_RXCSUM;
+ if (macb_is_gem(bp) && !(bp->caps & MACB_CAPS_FIFO_MODE)) {
+ if (!(bp->caps & MACB_CAPS_DISABLE_TX_HW_CSUM))
+ dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_RXCSUM;
+ else
+ dev->hw_features |= NETIF_F_RXCSUM;
+ }
if (bp->caps & MACB_CAPS_SG_DISABLED)
dev->hw_features &= ~NETIF_F_SG;
dev->features = dev->hw_features;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 00/14] Modify action API for implementing lockless actions
From: Cong Wang @ 2018-05-25 21:40 UTC (permalink / raw)
To: Vlad Buslov
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Jiri Pirko, Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
Alexei Starovoitov, Daniel Borkmann, Eric Dumazet, Kees Cook,
LKML, NetFilter, coreteam, kliteyn
In-Reply-To: <vbfo9h3zd01.fsf@reg-r-vrt-018-180.mtr.labs.mlnx>
On Fri, May 25, 2018 at 1:39 PM, Vlad Buslov <vladbu@mellanox.com> wrote:
>
> On Thu 24 May 2018 at 23:34, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> On Mon, May 14, 2018 at 7:27 AM, Vlad Buslov <vladbu@mellanox.com> wrote:
>>> Currently, all netlink protocol handlers for updating rules, actions and
>>> qdiscs are protected with single global rtnl lock which removes any
>>> possibility for parallelism. This patch set is a first step to remove
>>> rtnl lock dependency from TC rules update path. It updates act API to
>>> use atomic operations, rcu and spinlocks for fine-grained locking. It
>>> also extend API with functions that are needed to update existing
>>> actions for parallel execution.
>>
>> Can you give a summary here for what and how it is achieved?
>
> Got it, will expand cover letter in V2 with summary.
>>
>> You said this is the first step, what do you want to achieve in this
>> very first step? And how do you achieve it? Do you break the RTNL
>
> But aren't this questions answered in paragraph you quoted?
Obviously not, you said to remove it, but never explains why it can
be removed and how it is removed. This is crucial for review.
"use atomic operations, rcu and spinlocks for fine-grained locking"
is literately nothing, why atomic/rcu makes RTNL unnecessary?
How RCU is used? What spinlocks are you talking about? What
do these spinlocks protect after removing RTNL? Why are they
safe with other netdevice and netns operations?
You explain _nothing_ here. Really. Please don't force people to
read 14 patches to understand how it works. In fact, no one wants
to read the code unless there is some high-level explanation that
makes basic sense.
> What: Change act API to not rely on one-big-global-RTNL-lock and to use
> more fine-grained synchronization methods to allow safe concurrent
> execution.
Sure, how fine-grained it is after your patchset? Why this fine-grained
lock could safely replace RTNL?
Could you stop letting us guess your puzzle words? It would save your
time from exchanging emails with me, it would save my time from
guessing you too. It is a win-win.
> How: Refactor act API code to use atomics, rcu and spinlocks, etc. for
> protecting shared data structures, add new functions required to update
What shared data structures? The per-netns idr which is already protected
by a spinlock? The TC hierarchy? The shared standalone actions? Hey,
why do I have to guess? :-/
> specific actions implementation for parallel execution. (step 2)
Claim is easy, prove is hard. I can easily claim I break RTNL down
to a per-netns lock, but I can't prove it really works. :-D
>
> If you feel that this cover letter is too terse, I will add outline of
> changes in V2.
It is not my rule, it is how you have to help people to review your
14 patches. I think it is a fair game: you help people like me to
review your patches, we help you to get them reviewed and merged
if they all make sense.
>
>> lock down to, for a quick example, a per-device lock? Or perhaps you
>> completely remove it because of what reason?
>
> I want to remove RTNL _dependency_ from act API data structures and
> code. I probably should me more specific in this case:
>
> Florian recently made a change that allows registering netlink protocol
> handlers with flag RTNL_FLAG_DOIT_UNLOCKED. Handlers registered with
> this flag are called without RTNL taken. My end goal is to have rule
> update handlers(RTM_NEWTFILTER, RTM_DELTFILTER, etc.) to be registered
> with UNLOCKED flag to allow parallel execution.
Please add this paragraph in your cover letter, it is very important for review.
>
> I do not intend to globally remove or break RTNL.
>
>>
>> I go through all the descriptions of your 14 patches (but not any code),
>> I still have no clue how you successfully avoid RTNL. Please don't
>> let me read into your code to understand that, there must be some
>> high-level justification on how it works. Without it, I don't event want
>> to read into the code.
>
> On internal code review I've been asked not to duplicate info from
> commit messages in cover letter, but I guess I can expand it with some
> high level outline in V2.
In cover letter, you should put a high-level overview of "why" and "how".
If, in the worst case, on high-level it doesn't make sense, why should
we bother to read the code? In short, you have to convince people to
read your code here.
In each patch description, you should explain what a single patch does.
I don't see any duplication.
^ permalink raw reply
* [PATCH] mwifiex: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2018-05-25 21:38 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
Kalle Valo, David S. Miller
Cc: linux-wireless, netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 ++++
drivers/net/wireless/marvell/mwifiex/scan.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 54a2297..16a705d 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -1158,6 +1158,7 @@ mwifiex_cfg80211_change_virtual_intf(struct wiphy *wiphy,
case NL80211_IFTYPE_UNSPECIFIED:
mwifiex_dbg(priv->adapter, INFO,
"%s: kept type as IBSS\n", dev->name);
+ /* fall through */
case NL80211_IFTYPE_ADHOC: /* This shouldn't happen */
return 0;
default:
@@ -1188,6 +1189,7 @@ mwifiex_cfg80211_change_virtual_intf(struct wiphy *wiphy,
case NL80211_IFTYPE_UNSPECIFIED:
mwifiex_dbg(priv->adapter, INFO,
"%s: kept type as STA\n", dev->name);
+ /* fall through */
case NL80211_IFTYPE_STATION: /* This shouldn't happen */
return 0;
default:
@@ -1210,6 +1212,7 @@ mwifiex_cfg80211_change_virtual_intf(struct wiphy *wiphy,
case NL80211_IFTYPE_UNSPECIFIED:
mwifiex_dbg(priv->adapter, INFO,
"%s: kept type as AP\n", dev->name);
+ /* fall through */
case NL80211_IFTYPE_AP: /* This shouldn't happen */
return 0;
default:
@@ -1249,6 +1252,7 @@ mwifiex_cfg80211_change_virtual_intf(struct wiphy *wiphy,
case NL80211_IFTYPE_UNSPECIFIED:
mwifiex_dbg(priv->adapter, INFO,
"%s: kept type as P2P\n", dev->name);
+ /* fall through */
case NL80211_IFTYPE_P2P_CLIENT:
case NL80211_IFTYPE_P2P_GO:
return 0;
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c
index d7ce7f7..19df92b 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -1308,6 +1308,7 @@ int mwifiex_update_bss_desc_with_ie(struct mwifiex_adapter *adapter,
case WLAN_EID_CHANNEL_SWITCH:
bss_entry->chan_sw_ie_present = true;
+ /* fall through */
case WLAN_EID_PWR_CAPABILITY:
case WLAN_EID_TPC_REPORT:
case WLAN_EID_QUIET:
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] IB: Revert "remove redundant INFINIBAND kconfig dependencies"
From: Leon Romanovsky @ 2018-05-25 21:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Doug Ledford, Jason Gunthorpe, Keith Busch, Jens Axboe,
Christoph Hellwig, Sagi Grimberg, Oleg Drokin, Andreas Dilger,
James Simmons, Greg Kroah-Hartman, Steve French,
Eric Van Hensbergen, Ron Minnich, Latchesar Ionkov,
David S. Miller, Santosh Shilimkar, Trond Myklebust,
Anna Schumaker, J. Bruce Fields, Jeff Layton <jlayto
In-Reply-To: <20180525213123.2113748-1-arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]
On Fri, May 25, 2018 at 11:29:59PM +0200, Arnd Bergmann wrote:
> Several subsystems depend on INFINIBAND_ADDR_TRANS, which in turn depends
> on INFINIBAND. However, when with CONFIG_INIFIBAND=m, this leads to a
> link error when another driver using it is built-in. The
> INFINIBAND_ADDR_TRANS dependency is insufficient here as this is
> a 'bool' symbol that does not force anything to be a module in turn.
>
> fs/cifs/smbdirect.o: In function `smbd_disconnect_rdma_work':
> smbdirect.c:(.text+0x1e4): undefined reference to `rdma_disconnect'
> net/9p/trans_rdma.o: In function `rdma_request':
> trans_rdma.c:(.text+0x7bc): undefined reference to `rdma_disconnect'
> net/9p/trans_rdma.o: In function `rdma_destroy_trans':
> trans_rdma.c:(.text+0x830): undefined reference to `ib_destroy_qp'
> trans_rdma.c:(.text+0x858): undefined reference to `ib_dealloc_pd'
>
> Fixes: 9533b292a7ac ("IB: remove redundant INFINIBAND kconfig dependencies")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> The patch that introduced the problem has been queued in the
> rdma-fixes/for-rc tree. Please revert the patch before sending
> the branch to Linus.
> ---
It was already sent to Linus.
https://marc.info/?l=linux-rdma&m=152719509803047&w=2
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH, net-next] qcom-emag: hide ACPI specific functions
From: Arnd Bergmann @ 2018-05-25 21:37 UTC (permalink / raw)
To: Timur Tabi, David S. Miller
Cc: Arnd Bergmann, Hemanth Puranik, netdev, linux-kernel
A couple of functions in this file are only used when building with
ACPI enabled, leading to a build warning on most architectures:
drivers/net/ethernet/qualcomm/emac/emac-sgmii.c:284:25: error: 'qdf2400_ops' defined but not used [-Werror=unused-variable]
static struct sgmii_ops qdf2400_ops = {
^~~~~~~~~~~
drivers/net/ethernet/qualcomm/emac/emac-sgmii.c:276:25: error: 'qdf2432_ops' defined but not used [-Werror=unused-variable]
static struct sgmii_ops qdf2432_ops = {
This hides all the unused functions by putting them into the
corresponding #ifdef.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
index 562420b834df..01b80e0a5367 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
@@ -108,6 +108,7 @@ static void emac_sgmii_link_init(struct emac_adapter *adpt)
writel(val, phy->base + EMAC_SGMII_PHY_AUTONEG_CFG2);
}
+#ifdef CONFIG_ACPI
static int emac_sgmii_irq_clear(struct emac_adapter *adpt, u8 irq_bits)
{
struct emac_sgmii *phy = &adpt->phy;
@@ -288,6 +289,7 @@ static struct sgmii_ops qdf2400_ops = {
.link_change = emac_sgmii_common_link_change,
.reset = emac_sgmii_common_reset,
};
+#endif
static int emac_sgmii_acpi_match(struct device *dev, void *data)
{
--
2.9.0
^ permalink raw reply related
* [PATCH, net-next] net/mlx5e: fix TLS dependency
From: Arnd Bergmann @ 2018-05-25 21:36 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky, David S. Miller
Cc: Arnd Bergmann, Boris Pismenny, Ilan Tayari, Or Gerlitz,
Ilya Lesokhin, Feras Daoud, netdev, linux-rdma, linux-kernel
With CONFIG_TLS=m and MLX5_CORE_EN=y, we get a link failure:
drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls_rxtx.o: In function `mlx5e_tls_handle_ooo':
tls_rxtx.c:(.text+0x24c): undefined reference to `tls_get_record'
drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls_rxtx.o: In function `mlx5e_tls_handle_tx_skb':
tls_rxtx.c:(.text+0x9a8): undefined reference to `tls_device_sk_destruct'
This narrows down the dependency to only allow the configurations
that will actually work. The existing dependency on TLS_DEVICE is
not sufficient here since MLX5_EN_TLS is a 'bool' symbol.
Fixes: c83294b9efa5 ("net/mlx5e: TLS, Add Innova TLS TX support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
index ee6684779d11..2545296a0c08 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
@@ -91,6 +91,7 @@ config MLX5_EN_TLS
bool "TLS cryptography-offload accelaration"
depends on MLX5_CORE_EN
depends on TLS_DEVICE
+ depends on TLS=y || MLX5_CORE=m
depends on MLX5_ACCEL
default n
---help---
--
2.9.0
^ permalink raw reply related
* [PATCH, net-next 2/2] bpf: avoid -Wmaybe-uninitialized warning
From: Arnd Bergmann @ 2018-05-25 21:33 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: Arnd Bergmann, Yonghong Song, David S. Miller, Song Liu,
Martin KaFai Lau, Chenbo Feng, Jakub Kicinski, netdev,
linux-kernel
In-Reply-To: <20180525213331.2115471-1-arnd@arndb.de>
The stack_map_get_build_id_offset() function is too long for gcc to track
whether 'work' may or may not be initialized at the end of it, leading
to a false-positive warning:
kernel/bpf/stackmap.c: In function 'stack_map_get_build_id_offset':
kernel/bpf/stackmap.c:334:13: error: 'work' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This removes the 'in_nmi_ctx' flag and uses the state of that variable
itself to see if it got initialized.
Fixes: bae77c5eb5b2 ("bpf: enable stackmap with build_id in nmi context")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
kernel/bpf/stackmap.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index b59ace0f0f09..b675a3f3d141 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -285,11 +285,10 @@ static void stack_map_get_build_id_offset(struct bpf_stack_build_id *id_offs,
{
int i;
struct vm_area_struct *vma;
- bool in_nmi_ctx = in_nmi();
bool irq_work_busy = false;
- struct stack_map_irq_work *work;
+ struct stack_map_irq_work *work = NULL;
- if (in_nmi_ctx) {
+ if (in_nmi()) {
work = this_cpu_ptr(&up_read_work);
if (work->irq_work.flags & IRQ_WORK_BUSY)
/* cannot queue more up_read, fallback */
@@ -328,7 +327,7 @@ static void stack_map_get_build_id_offset(struct bpf_stack_build_id *id_offs,
id_offs[i].status = BPF_STACK_BUILD_ID_VALID;
}
- if (!in_nmi_ctx) {
+ if (!work) {
up_read(¤t->mm->mmap_sem);
} else {
work->sem = ¤t->mm->mmap_sem;
--
2.9.0
^ permalink raw reply related
* [PATCH, net-next 1/2] bpf: btf: avoid -Wreturn-type warning
From: Arnd Bergmann @ 2018-05-25 21:33 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: Arnd Bergmann, Martin KaFai Lau, Song Liu, netdev, linux-kernel
gcc warns about a noreturn function possibly returning in
some configurations:
kernel/bpf/btf.c: In function 'env_type_is_resolve_sink':
kernel/bpf/btf.c:729:1: error: control reaches end of non-void function [-Werror=return-type]
Using BUG() instead of BUG_ON() avoids that warning and otherwise
does the exact same thing.
Fixes: eb3f595dab40 ("bpf: btf: Validate type reference")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
kernel/bpf/btf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 9cbeabb5aca3..2822a0cf4f48 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -749,7 +749,7 @@ static bool env_type_is_resolve_sink(const struct btf_verifier_env *env,
!btf_type_is_array(next_type) &&
!btf_type_is_struct(next_type);
default:
- BUG_ON(1);
+ BUG();
}
}
--
2.9.0
^ permalink raw reply related
* [PATCH] IB: Revert "remove redundant INFINIBAND kconfig dependencies"
From: Arnd Bergmann @ 2018-05-25 21:29 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Latchesar Ionkov, samba-technical-w/Ol4Ecudpl8XjKLYN78aQ,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Keith Busch,
Christoph Hellwig, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-cifs-u79uwXL29TY76Z2rM5mHXA,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g, Sagi Grimberg,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, J. Bruce Fields,
Bart Van Assche, Greg Thelen, Arnd Bergmann, Eric Van Hensbergen,
Santosh Shilimkar, Jens Axboe,
v9fs-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Trond Myklebust,
Oleg Drokin, linux-nfs-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Jeff Layton, linux-kernel-u79uwXL29TY76Z2rM5mHXA, David S. Miller
Several subsystems depend on INFINIBAND_ADDR_TRANS, which in turn depends
on INFINIBAND. However, when with CONFIG_INIFIBAND=m, this leads to a
link error when another driver using it is built-in. The
INFINIBAND_ADDR_TRANS dependency is insufficient here as this is
a 'bool' symbol that does not force anything to be a module in turn.
fs/cifs/smbdirect.o: In function `smbd_disconnect_rdma_work':
smbdirect.c:(.text+0x1e4): undefined reference to `rdma_disconnect'
net/9p/trans_rdma.o: In function `rdma_request':
trans_rdma.c:(.text+0x7bc): undefined reference to `rdma_disconnect'
net/9p/trans_rdma.o: In function `rdma_destroy_trans':
trans_rdma.c:(.text+0x830): undefined reference to `ib_destroy_qp'
trans_rdma.c:(.text+0x858): undefined reference to `ib_dealloc_pd'
Fixes: 9533b292a7ac ("IB: remove redundant INFINIBAND kconfig dependencies")
Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
---
The patch that introduced the problem has been queued in the
rdma-fixes/for-rc tree. Please revert the patch before sending
the branch to Linus.
---
drivers/infiniband/ulp/srpt/Kconfig | 2 +-
drivers/nvme/host/Kconfig | 2 +-
drivers/nvme/target/Kconfig | 2 +-
drivers/staging/lustre/lnet/Kconfig | 2 +-
fs/cifs/Kconfig | 2 +-
net/9p/Kconfig | 2 +-
net/rds/Kconfig | 2 +-
net/sunrpc/Kconfig | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/infiniband/ulp/srpt/Kconfig b/drivers/infiniband/ulp/srpt/Kconfig
index 25bf6955b6d0..fb8b7182f05e 100644
--- a/drivers/infiniband/ulp/srpt/Kconfig
+++ b/drivers/infiniband/ulp/srpt/Kconfig
@@ -1,6 +1,6 @@
config INFINIBAND_SRPT
tristate "InfiniBand SCSI RDMA Protocol target support"
- depends on INFINIBAND_ADDR_TRANS && TARGET_CORE
+ depends on INFINIBAND && INFINIBAND_ADDR_TRANS && TARGET_CORE
---help---
Support for the SCSI RDMA Protocol (SRP) Target driver. The
diff --git a/drivers/nvme/host/Kconfig b/drivers/nvme/host/Kconfig
index dbb7464c018c..88a8b5916624 100644
--- a/drivers/nvme/host/Kconfig
+++ b/drivers/nvme/host/Kconfig
@@ -27,7 +27,7 @@ config NVME_FABRICS
config NVME_RDMA
tristate "NVM Express over Fabrics RDMA host driver"
- depends on INFINIBAND_ADDR_TRANS && BLOCK
+ depends on INFINIBAND && INFINIBAND_ADDR_TRANS && BLOCK
select NVME_CORE
select NVME_FABRICS
select SG_POOL
diff --git a/drivers/nvme/target/Kconfig b/drivers/nvme/target/Kconfig
index 7595664ee753..3c7b61ddb0d1 100644
--- a/drivers/nvme/target/Kconfig
+++ b/drivers/nvme/target/Kconfig
@@ -27,7 +27,7 @@ config NVME_TARGET_LOOP
config NVME_TARGET_RDMA
tristate "NVMe over Fabrics RDMA target support"
- depends on INFINIBAND_ADDR_TRANS
+ depends on INFINIBAND && INFINIBAND_ADDR_TRANS
depends on NVME_TARGET
select SGL_ALLOC
help
diff --git a/drivers/staging/lustre/lnet/Kconfig b/drivers/staging/lustre/lnet/Kconfig
index f3b1ad4bd3dc..ad049e6f24e4 100644
--- a/drivers/staging/lustre/lnet/Kconfig
+++ b/drivers/staging/lustre/lnet/Kconfig
@@ -34,7 +34,7 @@ config LNET_SELFTEST
config LNET_XPRT_IB
tristate "LNET infiniband support"
- depends on LNET && PCI && INFINIBAND_ADDR_TRANS
+ depends on LNET && PCI && INFINIBAND && INFINIBAND_ADDR_TRANS
default LNET && INFINIBAND
help
This option allows the LNET users to use infiniband as an
diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig
index d61e2de8d0eb..5f132d59dfc2 100644
--- a/fs/cifs/Kconfig
+++ b/fs/cifs/Kconfig
@@ -197,7 +197,7 @@ config CIFS_SMB311
config CIFS_SMB_DIRECT
bool "SMB Direct support (Experimental)"
- depends on CIFS=m && INFINIBAND_ADDR_TRANS || CIFS=y && INFINIBAND_ADDR_TRANS=y
+ depends on CIFS=m && INFINIBAND && INFINIBAND_ADDR_TRANS || CIFS=y && INFINIBAND=y && INFINIBAND_ADDR_TRANS=y
help
Enables SMB Direct experimental support for SMB 3.0, 3.02 and 3.1.1.
SMB Direct allows transferring SMB packets over RDMA. If unsure,
diff --git a/net/9p/Kconfig b/net/9p/Kconfig
index 46c39f7da444..e6014e0e51f7 100644
--- a/net/9p/Kconfig
+++ b/net/9p/Kconfig
@@ -32,7 +32,7 @@ config NET_9P_XEN
config NET_9P_RDMA
- depends on INET && INFINIBAND_ADDR_TRANS
+ depends on INET && INFINIBAND && INFINIBAND_ADDR_TRANS
tristate "9P RDMA Transport (Experimental)"
help
This builds support for an RDMA transport.
diff --git a/net/rds/Kconfig b/net/rds/Kconfig
index 1a31502ee7db..bffde4b46c5d 100644
--- a/net/rds/Kconfig
+++ b/net/rds/Kconfig
@@ -8,7 +8,7 @@ config RDS
config RDS_RDMA
tristate "RDS over Infiniband"
- depends on RDS && INFINIBAND_ADDR_TRANS
+ depends on RDS && INFINIBAND && INFINIBAND_ADDR_TRANS
---help---
Allow RDS to use Infiniband as a transport.
This transport supports RDMA operations.
diff --git a/net/sunrpc/Kconfig b/net/sunrpc/Kconfig
index 6358e5271070..ac09ca803296 100644
--- a/net/sunrpc/Kconfig
+++ b/net/sunrpc/Kconfig
@@ -50,7 +50,7 @@ config SUNRPC_DEBUG
config SUNRPC_XPRT_RDMA
tristate "RPC-over-RDMA transport"
- depends on SUNRPC && INFINIBAND_ADDR_TRANS
+ depends on SUNRPC && INFINIBAND && INFINIBAND_ADDR_TRANS
default SUNRPC && INFINIBAND
select SG_POOL
help
--
2.9.0
^ permalink raw reply related
* [PATCH] ath9k: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2018-05-25 21:22 UTC (permalink / raw)
To: QCA ath9k Development, Kalle Valo, David S. Miller
Cc: linux-wireless, netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 2 ++
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 1 +
drivers/net/wireless/ath/ath9k/main.c | 1 +
3 files changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
index 7922550..ef2dd68 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
@@ -583,12 +583,14 @@ static void ar5008_hw_init_chain_masks(struct ath_hw *ah)
case 0x5:
REG_SET_BIT(ah, AR_PHY_ANALOG_SWAP,
AR_PHY_SWAP_ALT_CHAIN);
+ /* fall through */
case 0x3:
if (ah->hw_version.macVersion == AR_SREV_REVISION_5416_10) {
REG_WRITE(ah, AR_PHY_RX_CHAINMASK, 0x7);
REG_WRITE(ah, AR_PHY_CAL_CHAINMASK, 0x7);
break;
}
+ /* else: fall through */
case 0x1:
case 0x2:
case 0x7:
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.c b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
index 61a9b85..7132918 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.c
@@ -119,6 +119,7 @@ static int ar9002_hw_set_channel(struct ath_hw *ah, struct ath9k_channel *chan)
aModeRefSel = 2;
if (aModeRefSel)
break;
+ /* else: fall through */
case 1:
default:
aModeRefSel = 0;
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index a3be8ad..11d84f4 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1928,6 +1928,7 @@ static int ath9k_ampdu_action(struct ieee80211_hw *hw,
case IEEE80211_AMPDU_TX_STOP_FLUSH:
case IEEE80211_AMPDU_TX_STOP_FLUSH_CONT:
flush = true;
+ /* fall through */
case IEEE80211_AMPDU_TX_STOP_CONT:
ath9k_ps_wakeup(sc);
ath_tx_aggr_stop(sc, sta, tid);
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox