* [PATCH] bna: Remove unnecessary self assignment
From: Nathan Chancellor @ 2018-09-20 22:24 UTC (permalink / raw)
To: Rasesh Mody, Sudarsana Kalluru, Dept-GELinuxNICDev,
David S. Miller
Cc: netdev, linux-kernel, Nathan Chancellor
Clang warns when a variable is assigned to itself.
drivers/net/ethernet/brocade/bna/bna_enet.c:1800:9: warning: explicitly
assigning value of variable of type 'int' to itself [-Wself-assign]
for (i = i; i < (bna->ioceth.attr.num_ucmac * 2); i++)
~ ^ ~
drivers/net/ethernet/brocade/bna/bna_enet.c:1835:9: warning: explicitly
assigning value of variable of type 'int' to itself [-Wself-assign]
for (i = i; i < (bna->ioceth.attr.num_mcmac * 2); i++)
~ ^ ~
2 warnings generated.
Link: https://github.com/ClangBuiltLinux/linux/issues/110
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/ethernet/brocade/bna/bna_enet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bna_enet.c b/drivers/net/ethernet/brocade/bna/bna_enet.c
index bba81735ce87..6d2d4527357c 100644
--- a/drivers/net/ethernet/brocade/bna/bna_enet.c
+++ b/drivers/net/ethernet/brocade/bna/bna_enet.c
@@ -1797,7 +1797,7 @@ bna_ucam_mod_init(struct bna_ucam_mod *ucam_mod, struct bna *bna,
/* A separate queue to allow synchronous setting of a list of MACs */
INIT_LIST_HEAD(&ucam_mod->del_q);
- for (i = i; i < (bna->ioceth.attr.num_ucmac * 2); i++)
+ for (; i < (bna->ioceth.attr.num_ucmac * 2); i++)
list_add_tail(&ucam_mod->ucmac[i].qe, &ucam_mod->del_q);
ucam_mod->bna = bna;
@@ -1832,7 +1832,7 @@ bna_mcam_mod_init(struct bna_mcam_mod *mcam_mod, struct bna *bna,
/* A separate queue to allow synchronous setting of a list of MACs */
INIT_LIST_HEAD(&mcam_mod->del_q);
- for (i = i; i < (bna->ioceth.attr.num_mcmac * 2); i++)
+ for (; i < (bna->ioceth.attr.num_mcmac * 2); i++)
list_add_tail(&mcam_mod->mcmac[i].qe, &mcam_mod->del_q);
mcam_mod->bna = bna;
--
2.19.0
^ permalink raw reply related
* Re: [PATCH] net: netronome: remove redundant continue
From: Jakub Kicinski @ 2018-09-20 16:38 UTC (permalink / raw)
To: zhong jiang; +Cc: davem, dirk.vandermerwe, simon.horman, netdev, linux-kernel
In-Reply-To: <1537430541-37817-1-git-send-email-zhongjiang@huawei.com>
On Thu, 20 Sep 2018 16:02:21 +0800, zhong jiang wrote:
> The continue will not truely skip any code. hence it is safe to
> remove it.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
I think this came up during review at some point. I still prefer to
keep the continue. The body of the loop performs initialization of
objects, if an object is removed we shouldn't carry on with the body.
It's easy to miss that the object got freed otherwise, there is no
error being set and no warning printed...
> diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
> index 0b1ac9c..50d7b58 100644
> --- a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
> +++ b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
> @@ -230,10 +230,8 @@ static void nfp_net_pf_free_vnics(struct nfp_pf *pf)
> ctrl_bar += NFP_PF_CSR_SLICE_SIZE;
>
> /* Kill the vNIC if app init marked it as invalid */
> - if (nn->port && nn->port->type == NFP_PORT_INVALID) {
> + if (nn->port && nn->port->type == NFP_PORT_INVALID)
> nfp_net_pf_free_vnic(pf, nn);
> - continue;
> - }
> }
>
> if (list_empty(&pf->vnics))
^ permalink raw reply
* Re: [PATCH net] netfilter: bridge: Don't sabotage nf_hook calls from an l3mdev
From: Pablo Neira Ayuso @ 2018-09-20 16:25 UTC (permalink / raw)
To: dsahern; +Cc: netdev, netfilter-devel, ndsouza, idosch, fw, David Ahern
In-Reply-To: <20180917152036.30674-1-dsahern@kernel.org>
On Mon, Sep 17, 2018 at 08:20:36AM -0700, dsahern@kernel.org wrote:
> From: David Ahern <dsahern@gmail.com>
>
> For starters, the bridge netfilter code registers operations that
> are invoked any time nh_hook is called. Specifically, ip_sabotage_in
> watches for nested calls for NF_INET_PRE_ROUTING when a bridge is in
> the stack.
>
> Packet wise, the bridge netfilter hook runs first. br_nf_pre_routing
> allocates nf_bridge, sets in_prerouting to 1 and calls NF_HOOK for
> NF_INET_PRE_ROUTING. It's finish function, br_nf_pre_routing_finish,
> then resets in_prerouting flag to 0 and the packet continues up the
> stack. The packet eventually makes it to the VRF driver and it invokes
> nf_hook for NF_INET_PRE_ROUTING in case any rules have been added against
> the vrf device.
>
> Because of the registered operations the call to nf_hook causes
> ip_sabotage_in to be invoked. That function sees the nf_bridge on the
> skb and that in_prerouting is not set. Thinking it is an invalid nested
> call it steals (drops) the packet.
>
> Update ip_sabotage_in to recognize that the bridge or one of its upper
> devices (e.g., vlan) can be enslaved to a VRF (L3 master device) and
> allow the packet to go through the nf_hook a second time.
Applied.
^ permalink raw reply
* [RFC PATCH] net: nixge: Address compiler warnings when building for i386
From: Moritz Fischer @ 2018-09-20 21:55 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, keescook, davem, moritz.fischer, f.fainelli,
Moritz Fischer
From: Moritz Fischer <mdf@kernel.org>
Address compiler warnings reported by kbuild autobuilders
when building for i386 as a result of dma_addr_t size on
different architectures.
warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
Signed-off-by: Moritz Fischer <mdf@kernel.org>
---
Hi all,
got an angry email from the kbuild bot.
This is an attempt at fixing its complaints. I'm travelling this week
so I don't have access to test this on hardware but maybe someone
can shoot a hole into this already.
I have *only build-tested* this for arm/arm64/x86/x86_64 and it seemed
to be happy.
Comments?
Thanks for your feedback
- Moritz
---
drivers/net/ethernet/ni/nixge.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/ni/nixge.c b/drivers/net/ethernet/ni/nixge.c
index 74cf52e3fb09..0611f2335b4a 100644
--- a/drivers/net/ethernet/ni/nixge.c
+++ b/drivers/net/ethernet/ni/nixge.c
@@ -127,8 +127,8 @@ struct nixge_hw_dma_bd {
#ifdef CONFIG_PHYS_ADDR_T_64BIT
#define nixge_hw_dma_bd_set_addr(bd, field, addr) \
do { \
- (bd)->field##_lo = lower_32_bits(((u64)addr)); \
- (bd)->field##_hi = upper_32_bits(((u64)addr)); \
+ (bd)->field##_lo = lower_32_bits((addr)); \
+ (bd)->field##_hi = upper_32_bits((addr)); \
} while (0)
#else
#define nixge_hw_dma_bd_set_addr(bd, field, addr) \
@@ -251,7 +251,7 @@ static void nixge_hw_dma_bd_release(struct net_device *ndev)
NIXGE_MAX_JUMBO_FRAME_SIZE,
DMA_FROM_DEVICE);
- skb = (struct sk_buff *)
+ skb = (struct sk_buff *)(uintptr_t)
nixge_hw_dma_bd_get_addr(&priv->rx_bd_v[i],
sw_id_offset);
dev_kfree_skb(skb);
@@ -323,7 +323,7 @@ static int nixge_hw_dma_bd_init(struct net_device *ndev)
if (!skb)
goto out;
- nixge_hw_dma_bd_set_offset(&priv->rx_bd_v[i], skb);
+ nixge_hw_dma_bd_set_offset(&priv->rx_bd_v[i], (uintptr_t)skb);
phys = dma_map_single(ndev->dev.parent, skb->data,
NIXGE_MAX_JUMBO_FRAME_SIZE,
DMA_FROM_DEVICE);
@@ -601,8 +601,8 @@ static int nixge_recv(struct net_device *ndev, int budget)
tail_p = priv->rx_bd_p + sizeof(*priv->rx_bd_v) *
priv->rx_bd_ci;
- skb = (struct sk_buff *)nixge_hw_dma_bd_get_addr(cur_p,
- sw_id_offset);
+ skb = (struct sk_buff *)(uintptr_t)
+ nixge_hw_dma_bd_get_addr(cur_p, sw_id_offset);
length = cur_p->status & XAXIDMA_BD_STS_ACTUAL_LEN_MASK;
if (length > NIXGE_MAX_JUMBO_FRAME_SIZE)
@@ -643,7 +643,7 @@ static int nixge_recv(struct net_device *ndev, int budget)
nixge_hw_dma_bd_set_phys(cur_p, cur_phys);
cur_p->cntrl = NIXGE_MAX_JUMBO_FRAME_SIZE;
cur_p->status = 0;
- nixge_hw_dma_bd_set_offset(cur_p, new_skb);
+ nixge_hw_dma_bd_set_offset(cur_p, (uintptr_t)new_skb);
++priv->rx_bd_ci;
priv->rx_bd_ci %= RX_BD_NUM;
--
2.18.0
^ permalink raw reply related
* Re: [RFC bpf-next 4/4] tools/bpf: handle EOPNOTSUPP when map lookup is failed
From: Jakub Kicinski @ 2018-09-20 15:59 UTC (permalink / raw)
To: Prashant Bhole
Cc: Alexei Starovoitov, Daniel Borkmann, Quentin Monnet,
David S . Miller, netdev
In-Reply-To: <6fb405e9-fe02-17c6-90e6-cf9c73ca7693@lab.ntt.co.jp>
On Thu, 20 Sep 2018 14:04:19 +0900, Prashant Bhole wrote:
> On 9/20/2018 12:29 AM, Jakub Kicinski wrote:
> > On Wed, 19 Sep 2018 16:51:43 +0900, Prashant Bhole wrote:
> >> Let's add a check for EOPNOTSUPP error when map lookup is failed.
> >> Also in case map doesn't support lookup, the output of map dump is
> >> changed from "can't lookup element" to "lookup not supported for
> >> this map".
> >>
> >> Patch adds function print_entry_error() function to print the error
> >> value.
> >>
> >> Following example dumps a map which does not support lookup.
> >>
> >> Output before:
> >> root# bpftool map -jp dump id 40
> >> [
> >> "key": ["0x0a","0x00","0x00","0x00"
> >> ],
> >> "value": {
> >> "error": "can\'t lookup element"
> >> },
> >> "key": ["0x0b","0x00","0x00","0x00"
> >> ],
> >> "value": {
> >> "error": "can\'t lookup element"
> >> }
> >> ]
> >>
> >> root# bpftool map dump id 40
> >> can't lookup element with key:
> >> 0a 00 00 00
> >> can't lookup element with key:
> >> 0b 00 00 00
> >> Found 0 elements
> >>
> >> Output after changes:
> >> root# bpftool map dump -jp id 45
> >> [
> >> "key": ["0x0a","0x00","0x00","0x00"
> >> ],
> >> "value": {
> >> "error": "lookup not supported for this map"
> >> },
> >> "key": ["0x0b","0x00","0x00","0x00"
> >> ],
> >> "value": {
> >> "error": "lookup not supported for this map"
> >> }
> >> ]
> >>
> >> root# bpftool map dump id 45
> >> key:
> >> 0a 00 00 00
> >> value:
> >> lookup not supported for this map
> >> key:
> >> 0b 00 00 00
> >> value:
> >> lookup not supported for this map
> >> Found 0 elements
> >
> > Nice improvement, thanks for the changes! I wonder what your thoughts
> > would be on just printing some form of "lookup not supported for this
> > map" only once? It seems slightly like repeated information - if
> > lookup is not supported for one key it likely won't be for other keys
> > too, so we could shorten the output. Would that make sense?
> >
> >> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
> >> ---
> >> tools/bpf/bpftool/main.h | 5 +++++
> >> tools/bpf/bpftool/map.c | 35 ++++++++++++++++++++++++++++++-----
> >> 2 files changed, 35 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h
> >> index 40492cdc4e53..1a8c683f949b 100644
> >> --- a/tools/bpf/bpftool/main.h
> >> +++ b/tools/bpf/bpftool/main.h
> >> @@ -46,6 +46,11 @@
> >>
> >> #include "json_writer.h"
> >>
> >> +#define ERR_CANNOT_LOOKUP \
> >> + "can't lookup element"
> >> +#define ERR_LOOKUP_NOT_SUPPORTED \
> >> + "lookup not supported for this map"
> >
> > Do we need these? Are we going to reused them in more parts of the
> > code?
>
> These are used only once. These can be used in do_lookup(). Currently
> do_lookup() prints strerror(errno) when lookup is failed. Shall I change
> that do_lookup() output?
I actually prefer to stick to strerror(), the standard errors more
clearly correlate with what happened in my mind (i.e. "Operation not
supported" == kernel sent EOPNOTSUPP). strerror() may also print in
local language if translation/localization matters.
We could even use strerr() in dump_map_elem() but up to you. The one
in do_lookup() I'd prefer to leave be ;)
^ permalink raw reply
* Re: [PATCH net-next 00/22] net: fix return type of ndo_start_xmit function
From: David Miller @ 2018-09-20 15:50 UTC (permalink / raw)
To: yuehaibing
Cc: dmitry.tarnyagin, wg, mkl, michal.simek, hsweeten, madalin.bucur,
pantelis.antoniou, claudiu.manoil, leoyang.li, linux, sammy, ralf,
nico, steve.glendinning, f.fainelli, grygorii.strashko, w-kwok2,
m-karicheri2, t.sailer, jreuter, kys, haiyangz, wei.liu2,
paul.durrant, arvid.brodin, pshelar, linux-kernel, netdev,
linux-can, linux-arm-kernel, linuxppc-dev, linux-mips, linux-omap
In-Reply-To: <20180920123306.14772-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 20 Sep 2018 20:32:44 +0800
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, so make sure the implementation in
> this driver has returns 'netdev_tx_t' value, and change the function
> return type to netdev_tx_t.
I would advise you not to send so many of these changes as a group.
If one of the patches needs feedback addressed, which is already the
case, you will have to resubmit the entire series all over again with
the fixes.
^ permalink raw reply
* Re: [PATCH] PCI: hv: Fix return value check in hv_pci_assign_slots()
From: Lorenzo Pieralisi @ 2018-09-20 15:41 UTC (permalink / raw)
To: Wei Yongjun
Cc: K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Bjorn Helgaas,
devel, linux-pci, kernel-janitors, David Miller, netdev
In-Reply-To: <1537425631-28460-1-git-send-email-weiyongjun1@huawei.com>
[+DaveM, netdev]
Removed erroneously added disclaimer, apologies.
On Thu, Sep 20, 2018 at 06:40:31AM +0000, Wei Yongjun wrote:
> In case of error, the function pci_create_slot() returns ERR_PTR() and
> never returns NULL. The NULL test in the return value check should be
> replaced with IS_ERR().
>
> Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/pci/controller/pci-hyperv.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> index ee80e79..9ba4d12 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -1484,8 +1484,10 @@ static void hv_pci_assign_slots(struct hv_pcibus_device *hbus)
> snprintf(name, SLOT_NAME_SIZE, "%u", hpdev->desc.ser);
> hpdev->pci_slot = pci_create_slot(hbus->pci_bus, slot_nr,
> name, NULL);
> - if (!hpdev->pci_slot)
> + if (IS_ERR(hpdev->pci_slot)) {
> pr_warn("pci_create slot %s failed\n", name);
> + hpdev->pci_slot = NULL;
> + }
> }
> }
I am dropping this patch from the PCI queue since the original series
is now queued in net-next.
Lorenzo
^ permalink raw reply
* Re: [PATCH] PCI: hv: Fix return value check in hv_pci_assign_slots()
From: Lorenzo Pieralisi @ 2018-09-20 15:28 UTC (permalink / raw)
To: Wei Yongjun
Cc: K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Bjorn Helgaas,
devel, linux-pci, kernel-janitors, David Miller, netdev
In-Reply-To: <1537425631-28460-1-git-send-email-weiyongjun1@huawei.com>
[+DaveM, netdev]
On Thu, Sep 20, 2018 at 06:40:31AM +0000, Wei Yongjun wrote:
> In case of error, the function pci_create_slot() returns ERR_PTR() and
> never returns NULL. The NULL test in the return value check should be
> replaced with IS_ERR().
>
> Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/pci/controller/pci-hyperv.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> index ee80e79..9ba4d12 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -1484,8 +1484,10 @@ static void hv_pci_assign_slots(struct hv_pcibus_device *hbus)
> snprintf(name, SLOT_NAME_SIZE, "%u", hpdev->desc.ser);
> hpdev->pci_slot = pci_create_slot(hbus->pci_bus, slot_nr,
> name, NULL);
> - if (!hpdev->pci_slot)
> + if (IS_ERR(hpdev->pci_slot)) {
> pr_warn("pci_create slot %s failed\n", name);
> + hpdev->pci_slot = NULL;
> + }
> }
> }
>
FYI
I am dropping this patch from the PCI queue since the original series
is now queued in net-next.
Lorenzo
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* Re: [PATCH rdma-next 1/5] RDMA/core: Provide getter and setter to access IB device name
From: Jason Gunthorpe @ 2018-09-20 15:15 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, linux-s390,
Ursula Braun, David S. Miller, netdev, Selvin Xavier, Steve Wise,
Lijun Ou, Shiraz Saleem, Ariel Elior, Christian Benvenuti,
Adit Ranadive, Dennis Dalessandro
In-Reply-To: <20180920112202.9181-2-leon@kernel.org>
On Thu, Sep 20, 2018 at 02:21:58PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Prepare IB device name field to rename operation by ensuring that all
> accesses to it are protected with lock and users don't see part of name.
Oh dear, no, that isn't going to work, there is too much stuff using
dev_name.. Did you read the comment on device_rename??
https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/base/core.c#L2715
> The protection is done with global device_lock because it is used in
> allocation and deallocation phases. At this stage, this lock is not
> busy and easily can be moved to be per-device, once it will be needed.
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> drivers/infiniband/core/device.c | 24 +++++++++++++++++++++++-
> include/rdma/ib_verbs.h | 8 +++++++-
> 2 files changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
> index 5a680a88aa87..3270cde6d806 100644
> +++ b/drivers/infiniband/core/device.c
> @@ -170,6 +170,14 @@ static struct ib_device *__ib_device_get_by_name(const char *name)
> return NULL;
> }
>
> +void ib_device_get_name(struct ib_device *ibdev, char *name)
> +{
> + down_read(&lists_rwsem);
> + strlcpy(name, ibdev->name, IB_DEVICE_NAME_MAX);
> + up_read(&lists_rwsem);
> +}
> +EXPORT_SYMBOL(ib_device_get_name);
I think we have to follow netdev and just rely on device_rename()
being 'good enough'.
Switch everything to use dev_name()/etc rather than try and do
something like this so the responsibility is on the device core to
keep this working, not us.
Turns out I have a series for that for unrelated reasons..
> static int alloc_name(char *name)
> {
> unsigned long *inuse;
> @@ -202,6 +210,21 @@ static int alloc_name(char *name)
> return 0;
> }
>
> +int ib_device_alloc_name(struct ib_device *ibdev, const char *pattern)
> +{
> + int ret = 0;
> +
> + mutex_lock(&device_mutex);
> + strlcpy(ibdev->name, pattern, IB_DEVICE_NAME_MAX);
> + if (strchr(ibdev->name, '%'))
> + ret = alloc_name(ibdev->name);
> +
> + mutex_unlock(&device_mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(ib_device_alloc_name);
Can't call alloc_name() without also adding to the list, this will
allow duplicates.
Jason
^ permalink raw reply
* RE: [PATCH net-next, 1/3] hv_netvsc: Add support for LRO/RSC in the vSwitch
From: Haiyang Zhang @ 2018-09-20 20:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: davem@davemloft.net, netdev@vger.kernel.org, olaf@aepfle.de,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
vkuznets
In-Reply-To: <20180920134725.3e149a0b@xeon-e3>
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Thursday, September 20, 2018 4:48 PM
> To: Haiyang Zhang <haiyangz@linuxonhyperv.com>
> Cc: Haiyang Zhang <haiyangz@microsoft.com>; davem@davemloft.net;
> netdev@vger.kernel.org; olaf@aepfle.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; vkuznets <vkuznets@redhat.com>
> Subject: Re: [PATCH net-next, 1/3] hv_netvsc: Add support for LRO/RSC in the
> vSwitch
>
> On Thu, 20 Sep 2018 17:06:59 +0000
> Haiyang Zhang <haiyangz@linuxonhyperv.com> wrote:
>
> > +static inline void rsc_add_data
> > + (struct netvsc_channel *nvchan,
> > + const struct ndis_pkt_8021q_info *vlan,
> > + const struct ndis_tcp_ip_checksum_info *csum_info,
> > + void *data, u32 len)
> > +{
>
> Could this be changed to look more like a function and skip the inline.
> The compiler will end up inlining it anyway.
>
> static void rsc_add_data(struct netvsc_channel *nvchan,
How about this?
static inline
void rsc_add_data(struct netvsc_channel *nvchan,
^ permalink raw reply
* KMSAN: uninit-value in dev_uc_add_excl
From: syzbot @ 2018-09-20 20:54 UTC (permalink / raw)
To: davem, edumazet, linux-kernel, netdev, sunlw.fnst, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 99e79f6a8963 kmsan: disable assembly implementations of cr..
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=14ccc911400000
kernel config: https://syzkaller.appspot.com/x/.config?x=dc53c800f40430e5
dashboard link: https://syzkaller.appspot.com/bug?extid=3a288d5f5530b901310e
compiler: clang version 8.0.0 (trunk 339414)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=178141fa400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=113d1efa400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3a288d5f5530b901310e@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
==================================================================
BUG: KMSAN: uninit-value in memcmp+0x11d/0x180 lib/string.c:863
CPU: 1 PID: 4318 Comm: syz-executor998 Not tainted 4.19.0-rc3+ #49
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x14b/0x190 lib/dump_stack.c:113
kmsan_report+0x183/0x2b0 mm/kmsan/kmsan.c:956
__msan_warning+0x70/0xc0 mm/kmsan/kmsan_instr.c:645
memcmp+0x11d/0x180 lib/string.c:863
dev_uc_add_excl+0x165/0x7b0 net/core/dev_addr_lists.c:464
ndo_dflt_fdb_add net/core/rtnetlink.c:3463 [inline]
rtnl_fdb_add+0x1081/0x1270 net/core/rtnetlink.c:3558
rtnetlink_rcv_msg+0xa0b/0x1530 net/core/rtnetlink.c:4715
netlink_rcv_skb+0x36e/0x5f0 net/netlink/af_netlink.c:2454
rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4733
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
netlink_unicast+0x1638/0x1720 net/netlink/af_netlink.c:1343
netlink_sendmsg+0x1205/0x1290 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
__sys_sendmsg net/socket.c:2152 [inline]
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg+0x2a3/0x3d0 net/socket.c:2159
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2159
do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
entry_SYSCALL_64_after_hwframe+0x63/0xe7
RIP: 0033:0x440ee9
Code: e8 cc ab 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 bb 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fff6a93b518 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000440ee9
RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000003
RBP: 0000000000000000 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 000000000000b4b0
R13: 0000000000401ec0 R14: 0000000000000000 R15: 0000000000000000
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:256 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:181
kmsan_kmalloc+0x98/0x100 mm/kmsan/kmsan_hooks.c:91
kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan_hooks.c:100
slab_post_alloc_hook mm/slab.h:446 [inline]
slab_alloc_node mm/slub.c:2718 [inline]
__kmalloc_node_track_caller+0x9e7/0x1160 mm/slub.c:4351
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x2f5/0x9e0 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:996 [inline]
netlink_alloc_large_skb net/netlink/af_netlink.c:1189 [inline]
netlink_sendmsg+0xb49/0x1290 net/netlink/af_netlink.c:1883
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg net/socket.c:631 [inline]
___sys_sendmsg+0xe70/0x1290 net/socket.c:2114
__sys_sendmsg net/socket.c:2152 [inline]
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg+0x2a3/0x3d0 net/socket.c:2159
__x64_sys_sendmsg+0x4a/0x70 net/socket.c:2159
do_syscall_64+0xb8/0x100 arch/x86/entry/common.c:291
entry_SYSCALL_64_after_hwframe+0x63/0xe7
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* KMSAN: uninit-value in ip6_parse_tlv
From: syzbot @ 2018-09-20 20:54 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 74ee2200b89f kmsan: bump .config.example to v4.17-rc3
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=1426fde7800000
kernel config: https://syzkaller.appspot.com/x/.config?x=4ca1e57bafa8ab1f
dashboard link: https://syzkaller.appspot.com/bug?extid=f08ac29f2ac8aea19826
compiler: clang version 7.0.0 (trunk 329391)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15574be7800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1003fc37800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+f08ac29f2ac8aea19826@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
==================================================================
BUG: KMSAN: uninit-value in ip6_parse_tlv+0x8d5/0xcd0 net/ipv6/exthdrs.c:172
CPU: 1 PID: 4535 Comm: syz-executor786 Not tainted 4.17.0-rc3+ #88
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
ip6_parse_tlv+0x8d5/0xcd0 net/ipv6/exthdrs.c:172
ipv6_destopt_rcv+0x50d/0xd90 net/ipv6/exthdrs.c:310
ip6_input_finish+0xaac/0x2250 net/ipv6/ip6_input.c:284
NF_HOOK include/linux/netfilter.h:288 [inline]
ip6_input net/ipv6/ip6_input.c:327 [inline]
ip6_mc_input+0xa67/0x1080 net/ipv6/ip6_input.c:404
dst_input include/net/dst.h:450 [inline]
ip6_rcv_finish+0x46e/0x6e0 net/ipv6/ip6_input.c:71
NF_HOOK include/linux/netfilter.h:288 [inline]
ipv6_rcv+0x1e16/0x2340 net/ipv6/ip6_input.c:208
__netif_receive_skb_core+0x47df/0x4a90 net/core/dev.c:4592
__netif_receive_skb net/core/dev.c:4657 [inline]
process_backlog+0x62d/0xe20 net/core/dev.c:5337
napi_poll net/core/dev.c:5735 [inline]
net_rx_action+0x7c1/0x1a70 net/core/dev.c:5801
__do_softirq+0x56d/0x93d kernel/softirq.c:285
do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
</IRQ>
do_softirq+0xb6/0xf0 kernel/softirq.c:329
netif_rx_ni net/core/dev.c:4219 [inline]
dev_loopback_xmit+0x8b0/0x900 net/core/dev.c:3347
NF_HOOK include/linux/netfilter.h:288 [inline]
ip6_finish_output2+0x1e24/0x2110 net/ipv6/ip6_output.c:84
ip6_finish_output+0xae9/0xba0 net/ipv6/ip6_output.c:154
NF_HOOK_COND include/linux/netfilter.h:277 [inline]
ip6_output+0x597/0x6c0 net/ipv6/ip6_output.c:171
dst_output include/net/dst.h:444 [inline]
ip6_local_out+0x15e/0x1d0 net/ipv6/output_core.c:176
ip6_send_skb net/ipv6/ip6_output.c:1702 [inline]
ip6_push_pending_frames+0x218/0x4d0 net/ipv6/ip6_output.c:1722
rawv6_push_pending_frames net/ipv6/raw.c:616 [inline]
rawv6_sendmsg+0x4235/0x4fb0 net/ipv6/raw.c:935
inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg net/socket.c:639 [inline]
__sys_sendto+0x6c0/0x7e0 net/socket.c:1789
__do_sys_sendto net/socket.c:1801 [inline]
__se_sys_sendto net/socket.c:1797 [inline]
__x64_sys_sendto+0x1a1/0x210 net/socket.c:1797
do_syscall_64+0x154/0x220 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x43fe79
RSP: 002b:00007ffc475970d8 EFLAGS: 00000216 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fe79
RDX: 0000000000000000 RSI: 0000000020001ffe RDI: 0000000000000003
RBP: 00000000006ca018 R08: 0000000020003000 R09: 000000000000001c
R10: 0000000000000000 R11: 0000000000000216 R12: 00000000004017a0
R13: 0000000000401830 R14: 0000000000000000 R15: 0000000000000000
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan.c:321
slab_post_alloc_hook mm/slab.h:446 [inline]
slab_alloc_node mm/slub.c:2753 [inline]
__kmalloc_node_track_caller+0xb32/0x11b0 mm/slub.c:4395
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:988 [inline]
alloc_skb_with_frags+0x1e6/0xb80 net/core/skbuff.c:5254
sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2088
sock_alloc_send_skb+0xca/0xe0 net/core/sock.c:2105
__ip6_append_data+0x33a2/0x4e40 net/ipv6/ip6_output.c:1427
ip6_append_data+0x40e/0x6b0 net/ipv6/ip6_output.c:1596
rawv6_sendmsg+0x2740/0x4fb0 net/ipv6/raw.c:928
inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg net/socket.c:639 [inline]
__sys_sendto+0x6c0/0x7e0 net/socket.c:1789
__do_sys_sendto net/socket.c:1801 [inline]
__se_sys_sendto net/socket.c:1797 [inline]
__x64_sys_sendto+0x1a1/0x210 net/socket.c:1797
do_syscall_64+0x154/0x220 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [PATCH] wireless: ipw2x00: Remove unnecessary parentheses
From: Nathan Chancellor @ 2018-09-20 20:45 UTC (permalink / raw)
To: Stanislav Yakovlev, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel, Nathan Chancellor
Clang warns when multiple pairs of parentheses are used for a single
conditional statement.
drivers/net/wireless/intel/ipw2x00/ipw2200.c:5655:28: warning: equality
comparison with extraneous parentheses [-Wparentheses-equality]
if ((priv->ieee->iw_mode == IW_MODE_ADHOC)) {
~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
drivers/net/wireless/intel/ipw2x00/ipw2200.c:5655:28: note: remove
extraneous parentheses around the comparison to silence this warning
if ((priv->ieee->iw_mode == IW_MODE_ADHOC)) {
~ ^ ~
drivers/net/wireless/intel/ipw2x00/ipw2200.c:5655:28: note: use '=' to
turn this equality comparison into an assignment
if ((priv->ieee->iw_mode == IW_MODE_ADHOC)) {
^~
=
1 warning generated.
Link: https://github.com/ClangBuiltLinux/linux/issues/134
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index 9644e7b93645..bbdca13c5a9f 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -5652,7 +5652,7 @@ static void ipw_merge_adhoc_network(struct work_struct *work)
}
mutex_lock(&priv->mutex);
- if ((priv->ieee->iw_mode == IW_MODE_ADHOC)) {
+ if (priv->ieee->iw_mode == IW_MODE_ADHOC) {
IPW_DEBUG_MERGE("remove network %*pE\n",
priv->essid_len, priv->essid);
ipw_remove_current_network(priv);
--
2.19.0
^ permalink raw reply related
* KMSAN: uninit-value in tipc_nl_compat_doit
From: syzbot @ 2018-09-20 20:44 UTC (permalink / raw)
To: davem, jon.maloy, linux-kernel, netdev, syzkaller-bugs,
tipc-discussion, ying.xue
Hello,
syzbot found the following crash on:
HEAD commit: d2d741e5d189 kmsan: add initialization for shmem pages
git tree: https://github.com/google/kmsan.git/master
console output: https://syzkaller.appspot.com/x/log.txt?x=14b18f6b800000
kernel config: https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f
dashboard link: https://syzkaller.appspot.com/bug?extid=bca0dc46634781f08b38
compiler: clang version 7.0.0 (trunk 329391)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15cad047800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=114ceffb800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+bca0dc46634781f08b38@syzkaller.appspotmail.com
==================================================================
BUG: KMSAN: uninit-value in tipc_nl_compat_doit+0x404/0xa10
net/tipc/netlink_compat.c:335
CPU: 0 PID: 4514 Comm: syz-executor485 Not tainted 4.16.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
tipc_nl_compat_doit+0x404/0xa10 net/tipc/netlink_compat.c:335
tipc_nl_compat_recv+0x164b/0x2700 net/tipc/netlink_compat.c:1153
genl_family_rcv_msg net/netlink/genetlink.c:599 [inline]
genl_rcv_msg+0x1686/0x1810 net/netlink/genetlink.c:624
netlink_rcv_skb+0x378/0x600 net/netlink/af_netlink.c:2447
genl_rcv+0x63/0x80 net/netlink/genetlink.c:635
netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline]
netlink_unicast+0x166b/0x1740 net/netlink/af_netlink.c:1337
netlink_sendmsg+0x1048/0x1310 net/netlink/af_netlink.c:1900
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
__sys_sendmsg net/socket.c:2080 [inline]
SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
SyS_sendmsg+0x54/0x80 net/socket.c:2087
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x43fda9
RSP: 002b:00007ffd0c184ba8 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fda9
RDX: 0000000000000000 RSI: 0000000020023000 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 00000000004016d0
R13: 0000000000401760 R14: 0000000000000000 R15: 0000000000000000
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
slab_post_alloc_hook mm/slab.h:445 [inline]
slab_alloc_node mm/slub.c:2737 [inline]
__kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:984 [inline]
netlink_alloc_large_skb net/netlink/af_netlink.c:1183 [inline]
netlink_sendmsg+0x9a6/0x1310 net/netlink/af_netlink.c:1875
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
__sys_sendmsg net/socket.c:2080 [inline]
SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
SyS_sendmsg+0x54/0x80 net/socket.c:2087
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* RE: [PATCH v2 1/5] netlink: remove NLA_NESTED_COMPAT
From: David Laight @ 2018-09-20 14:54 UTC (permalink / raw)
To: 'Johannes Berg', linux-wireless@vger.kernel.org,
netdev@vger.kernel.org
Cc: David Ahern, Johannes Berg
In-Reply-To: <20180919194905.16462-2-johannes@sipsolutions.net>
From: Johannes Berg
> Sent: 19 September 2018 20:49
> This isn't used anywhere, so we might as well get rid of it.
>
> Reviewed-by: David Ahern <dsahern@gmail.com>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> include/net/netlink.h | 2 --
> lib/nlattr.c | 11 -----------
> 2 files changed, 13 deletions(-)
>
> diff --git a/include/net/netlink.h b/include/net/netlink.h
> index 318b1ded3833..b680fe365e91 100644
> --- a/include/net/netlink.h
> +++ b/include/net/netlink.h
> @@ -172,7 +172,6 @@ enum {
> NLA_FLAG,
> NLA_MSECS,
> NLA_NESTED,
> - NLA_NESTED_COMPAT,
> NLA_NUL_STRING,
> NLA_BINARY,
> NLA_S8,
...
Is it safe to remove an item from this emun ?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH RFT net-next 0/2] net: phy: Eliminate unnecessary soft
From: Andrew Lunn @ 2018-09-20 14:58 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, nbd, cphealy, harini.katakam, afleming,
agust, arnd, asmirnov, avi.kp.137, avorontsov, baijiaju1990, benh,
charles-antoine.couret, clemens.gruber, colin.king, cyril,
david.thomson, ddaney, dongsheng.wang, dwmw2, eha, houjingj, jeff,
Jingju.Hou, Jisheng.Zhang, johan, Kapil.Juneja, kim.phillips,
linyunsheng, madalin.bucur, michael, mic
In-Reply-To: <20180919013505.11347-1-f.fainelli@gmail.com>
On Tue, Sep 18, 2018 at 06:35:03PM -0700, Florian Fainelli wrote:
> Hi all,
>
> This patch series eliminates unnecessary software resets of the PHY.
> This should hopefully not break anybody's hardware; but I would
> appreciate testing to make sure this is is the case.
>
> Sorry for this long email list, I wanted to make sure I reached out to
> all people who made changes to the Marvell PHY driver.
Hi Florian
I want to test this, but i'm battling other issues at the moment and
not got around to it.
But i see it has been tested by two people. So i think we should merge
it, and see if anybody screams.
Andrew
^ permalink raw reply
* [PATCH] net: neterion: vxge: Remove unnecessary parentheses
From: Nathan Chancellor @ 2018-09-20 20:37 UTC (permalink / raw)
To: Jon Mason, David S. Miller; +Cc: netdev, linux-kernel, Nathan Chancellor
Clang warns when multiple pairs of parentheses are used for a single
conditional statement.
drivers/net/ethernet/neterion/vxge/vxge-traffic.c:2265:31: warning:
equality comparison with extraneous parentheses [-Wparentheses-equality]
if ((hldev->config.intr_mode ==
VXGE_HW_INTR_MODE_MSIX_ONE_SHOT))
~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/neterion/vxge/vxge-traffic.c:2265:31: note: remove
extraneous parentheses around the comparison to silence this warning
if ((hldev->config.intr_mode ==
VXGE_HW_INTR_MODE_MSIX_ONE_SHOT))
~ ^ ~
drivers/net/ethernet/neterion/vxge/vxge-traffic.c:2265:31: note: use '='
to turn this equality comparison into an assignment
if ((hldev->config.intr_mode ==
VXGE_HW_INTR_MODE_MSIX_ONE_SHOT))
^~
=
1 warning generated.
Link: https://github.com/ClangBuiltLinux/linux/issues/124
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/ethernet/neterion/vxge/vxge-traffic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/neterion/vxge/vxge-traffic.c b/drivers/net/ethernet/neterion/vxge/vxge-traffic.c
index 30e5cdc52eb6..f7a0d1d5885e 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-traffic.c
+++ b/drivers/net/ethernet/neterion/vxge/vxge-traffic.c
@@ -2262,7 +2262,7 @@ void vxge_hw_vpath_msix_clear(struct __vxge_hw_vpath_handle *vp, int msix_id)
{
struct __vxge_hw_device *hldev = vp->vpath->hldev;
- if ((hldev->config.intr_mode == VXGE_HW_INTR_MODE_MSIX_ONE_SHOT))
+ if (hldev->config.intr_mode == VXGE_HW_INTR_MODE_MSIX_ONE_SHOT)
__vxge_hw_pio_mem_write32_upper(
(u32) vxge_bVALn(vxge_mBIT((msix_id >> 2)), 0, 32),
&hldev->common_reg->clr_msix_one_shot_vec[msix_id % 4]);
--
2.19.0
^ permalink raw reply related
* Re: [PATCH net] ixgbe: check return value of napi_complete_done()
From: Eric Dumazet @ 2018-09-20 20:35 UTC (permalink / raw)
To: Song Liu, netdev; +Cc: intel-wired-lan, kernel-team, stable, Jeff Kirsher
In-Reply-To: <20180920190113.490005-1-songliubraving@fb.com>
On 09/20/2018 12:01 PM, Song Liu wrote:
> The NIC driver should only enable interrupts when napi_complete_done()
> returns true. This patch adds the check for ixgbe.
>
> Cc: stable@vger.kernel.org # 4.10+
> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Song Liu <songliubraving@fb.com>
> ---
Well, unfortunately we do not know why this is needed,
this is why I have not yet sent this patch formally.
netpoll has correct synchronization :
poll_napi() places into napi->poll_owner current cpu number before calling poll_one_napi()
netpoll_poll_lock() does also use napi->poll_owner
When netpoll calls ixgbe poll() method, it passed a budget of 0,
meaning napi_complete_done() is not called.
As long as we can not explain the problem properly in the changelog,
we should investigate, otherwise we will probably see coming dozens of patches
trying to fix a 'potential hazard'.
Thanks.
^ permalink raw reply
* Re: [PATCH] smc: generic netlink family should be __ro_after_init
From: David Miller @ 2018-09-20 14:50 UTC (permalink / raw)
To: johannes; +Cc: linux-s390, netdev, ubraun, johannes.berg
In-Reply-To: <20180920072730.17584-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 20 Sep 2018 09:27:30 +0200
> From: Johannes Berg <johannes.berg@intel.com>
>
> The generic netlink family is only initialized during module init,
> so it should be __ro_after_init like all other generic netlink
> families.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Looks good, applied.
^ permalink raw reply
* Re: [PATCH net] mlxsw: spectrum: Bump required firmware version
From: David Miller @ 2018-09-20 14:49 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, petrm, mlxsw
In-Reply-To: <20180920063145.12770-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Thu, 20 Sep 2018 09:31:45 +0300
> From: Petr Machata <petrm@mellanox.com>
>
> MC-aware mode was introduced to mlxsw in commit 7b8195306694 ("mlxsw: spectrum:
> Configure MC-aware mode on mlxsw ports") and fixed up later in commit
> 3a3539cd3632 ("mlxsw: spectrum_buffers: Set up a dedicated pool for BUM
> traffic"). As the final piece of puzzle, a firmware issue whereby a wrong
> priority was assigned to BUM traffic was corrected in FW version 13.1703.4.
> Therefore require this FW version in the driver.
>
> Fixes: 7b8195306694 ("mlxsw: spectrum: Configure MC-aware mode on mlxsw ports")
> Signed-off-by: Petr Machata <petrm@mellanox.com>
> Reviewed-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 00/13] mlxsw: Further MC-awareness configuration
From: David Miller @ 2018-09-20 14:47 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, petrm, mlxsw
In-Reply-To: <20180920062136.11888-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Thu, 20 Sep 2018 09:21:23 +0300
> Petr says:
>
> Due to an issue in Spectrum chips, when unicast traffic shares the same
> queue as BUM traffic, and there is congestion, the BUM traffic is
> admitted to the queue anyway, thus pushing out all UC traffic. In order
> to give unicast traffic precedence over BUM traffic, multicast-aware
> mode is now configured on all ports. Under MC-aware mode, egress TCs
> 8..15 are used for BUM traffic, which has its own dedicated pool.
>
> This patch set improves the way that the MC pool and the higher-order
> TCs are integrated into the system.
Series applied, thanks.
> Then in patch #13 the selftest itself is added.
Just wanted to say I'm really happy with the selftests that exist
for all of the problems that have been fixed recently in mlxsw.
^ permalink raw reply
* Re: [PATCH bpf-next 2/2] xsk: fix bug when trying to use both copy and zero-copy on one queue id
From: Jakub Kicinski @ 2018-09-20 14:41 UTC (permalink / raw)
To: Magnus Karlsson
Cc: ys114321, Karlsson, Magnus, Björn Töpel, ast,
Daniel Borkmann, Network Development
In-Reply-To: <CAJ8uoz2m2amnk_aFwpyGg8Ss20vbt5EeVbXLEXQeO+gfEBc_cg@mail.gmail.com>
On Thu, 20 Sep 2018 11:17:17 +0200, Magnus Karlsson wrote:
> On Wed, Sep 19, 2018 at 9:18 AM Magnus Karlsson wrote:
> > On Wed, Sep 19, 2018 at 3:58 AM Jakub Kicinski wrote:
> > >
> > > On Tue, 18 Sep 2018 10:22:11 -0700, Y Song wrote:
> > > > > +/* The umem is stored both in the _rx struct and the _tx struct as we do
> > > > > + * not know if the device has more tx queues than rx, or the opposite.
> > > > > + * This might also change during run time.
> > > > > + */
> > > > > +static void xdp_reg_umem_at_qid(struct net_device *dev, struct xdp_umem *umem,
> > > > > + u16 queue_id)
> > > > > +{
> > > > > + if (queue_id < dev->real_num_rx_queues)
> > > > > + dev->_rx[queue_id].umem = umem;
> > > > > + if (queue_id < dev->real_num_tx_queues)
> > > > > + dev->_tx[queue_id].umem = umem;
> > > > > +}
> > > > > +
> > > > > +static struct xdp_umem *xdp_get_umem_from_qid(struct net_device *dev,
> > > > > + u16 queue_id)
> > > > > +{
> > > > > + if (queue_id < dev->real_num_rx_queues)
> > > > > + return dev->_rx[queue_id].umem;
> > > > > + if (queue_id < dev->real_num_tx_queues)
> > > > > + return dev->_tx[queue_id].umem;
> > > > > +
> > > > > + return NULL;
> > > > > +}
> > > > > +
> > > > > +static void xdp_clear_umem_at_qid(struct net_device *dev, u16 queue_id)
> > > > > +{
> > > > > + /* Zero out the entry independent on how many queues are configured
> > > > > + * at this point in time, as it might be used in the future.
> > > > > + */
> > > > > + if (queue_id < dev->num_rx_queues)
> > > > > + dev->_rx[queue_id].umem = NULL;
> > > > > + if (queue_id < dev->num_tx_queues)
> > > > > + dev->_tx[queue_id].umem = NULL;
> > > > > +}
> > > > > +
> > > >
> > > > I am sure whether the following scenario can happen or not.
> > > > Could you clarify?
> > > > 1. suppose initially we have num_rx_queues = num_tx_queues = 10
> > > > xdp_reg_umem_at_qid() set umem1 to queue_id = 8
> > > > 2. num_tx_queues is changed to 5
> > > > 3. xdp_clear_umem_at_qid() is called for queue_id = 8,
> > > > and dev->_rx[8].umum = 0.
> > > > 4. xdp_reg_umem_at_qid() is called gain to set for queue_id = 8
> > > > dev->_rx[8].umem = umem2
> > > > 5. num_tx_queues is changed to 10
> > > > Now dev->_rx[8].umem != dev->_tx[8].umem, is this possible and is it
> > > > a problem?
> > >
> > > Plus IIRC the check of qid vs real_num_[rt]x_queues in xsk_bind() is
> > > not under rtnl_lock so it doesn't count for much. Why not do all the
> > > checks against num_[rt]x_queues here, instead of real_..?
> >
> > You are correct, two separate rtnl_lock regions is broken. Will spin a
> > v2 tomorrow when I am back in the office.
> >
> > Thanks Jakub for catching this. I really appreciate you reviewing my code.
>
> Sorry, forgot to answer your question about why real_num_ instead of
> num_. If we used num_ instead, we would get a behavior where we can
> open a socket on a queue id, let us say 10, that will not be active if
> real_num_ is below 10. So no traffic will flow on this socket until we
> issue an ethtool command to state that we have 10 or more queues
> configured. While this behavior is sane (and consistent), I believe it
> will lead to a more complicated driver implementation, break the
> current uapi (since we will return an error if you try to bind to a
> queue id that is not active at the moment) and I like my suggestion
> below better :-).
>
> What I would like to suggest is that the current model at bind() is
> kept, that is it will fail if you try to bind to a non-active queue
> id. But we add some code in ethool_set_channels in net/core/ethtool.c
> to check if you have an active af_xdp socket on a queue id and try to
> make it inactive, we return an error and disallow the change. This
> would IMHO be like not allowing a load module to be unloaded if
> someone is using it or not allowing unmounting a file system if files
> are in use. What do you think? If you think this is the right way to
> go, I can implement this in a follow up patch or in this patch set if
> that makes more sense, let me know. This suggestion would actually
> make it simpler to implement zero-copy support in the driver. Some of
> the complications we are having today is due to the fact that ethtool
> can come in from the side and change things for us when an AF_XDP
> socket is active on a queue id. And implementing zero copy support in
> the driver needs to get simpler IMO.
>
> Please let me know what you think.
I think I'd like that:
https://patchwork.ozlabs.org/project/netdev/list/?series=57843&state=*
in particular:
https://patchwork.ozlabs.org/patch/949891/
;)
If we fix the resize indeed you could stick to real_* but to be honest,
I'm not entirely clear on what the advantage would be? The arrays are
sized to num..queues, do you envision a use case where having
xdp_get_umem_from_qid() return a NULL when asked for qid > real_..
would help? Is there one for xdp_reg_umem_at_qid()
I have no strong preference here, just wondering.
^ permalink raw reply
* Re: [PATCH rdma-next 1/5] RDMA/core: Provide getter and setter to access IB device name
From: Steve Wise @ 2018-09-20 14:32 UTC (permalink / raw)
To: Leon Romanovsky, Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, linux-s390, Ursula Braun,
David S. Miller, netdev, Selvin Xavier, Steve Wise, Lijun Ou,
Shiraz Saleem, Ariel Elior, Christian Benvenuti, Adit Ranadive,
Dennis Dalessandro
In-Reply-To: <20180920112202.9181-2-leon@kernel.org>
On 9/20/2018 6:21 AM, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Prepare IB device name field to rename operation by ensuring that all
> accesses to it are protected with lock and users don't see part of name.
>
> The protection is done with global device_lock because it is used in
> allocation and deallocation phases. At this stage, this lock is not
> busy and easily can be moved to be per-device, once it will be needed.
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> drivers/infiniband/core/device.c | 24 +++++++++++++++++++++++-
> include/rdma/ib_verbs.h | 8 +++++++-
> 2 files changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
> index 5a680a88aa87..3270cde6d806 100644
> --- a/drivers/infiniband/core/device.c
> +++ b/drivers/infiniband/core/device.c
> @@ -170,6 +170,14 @@ static struct ib_device *__ib_device_get_by_name(const char *name)
> return NULL;
> }
>
> +void ib_device_get_name(struct ib_device *ibdev, char *name)
> +{
> + down_read(&lists_rwsem);
> + strlcpy(name, ibdev->name, IB_DEVICE_NAME_MAX);
> + up_read(&lists_rwsem);
> +}
> +EXPORT_SYMBOL(ib_device_get_name);
> +
> static int alloc_name(char *name)
> {
> unsigned long *inuse;
> @@ -202,6 +210,21 @@ static int alloc_name(char *name)
> return 0;
> }
>
> +int ib_device_alloc_name(struct ib_device *ibdev, const char *pattern)
> +{
> + int ret = 0;
> +
> + mutex_lock(&device_mutex);
> + strlcpy(ibdev->name, pattern, IB_DEVICE_NAME_MAX);
> + if (strchr(ibdev->name, '%'))
> + ret = alloc_name(ibdev->name);
> +
> + mutex_unlock(&device_mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(ib_device_alloc_name);
> +
> static void ib_device_release(struct device *device)
> {
> struct ib_device *dev = container_of(device, struct ib_device, dev);
> @@ -499,7 +522,6 @@ int ib_register_device(struct ib_device *device,
> ret = alloc_name(device->name);
> if (ret)
> goto out;
> - }
I don't think this is correct...
>
> if (ib_device_check_mandatory(device)) {
> ret = -EINVAL;
> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> index e764ed1f6025..66660e7b9854 100644
> --- a/include/rdma/ib_verbs.h
> +++ b/include/rdma/ib_verbs.h
> @@ -2260,6 +2260,11 @@ struct ib_device {
> /* Do not access @dma_device directly from ULP nor from HW drivers. */
> struct device *dma_device;
>
> + /*
> + * Do not access @name directly,
> + * use ib_device_get_name()/ib_device_alloc_name()
> + * and don't assume that it can't change after access.
> + */
> char name[IB_DEVICE_NAME_MAX];
>
> struct list_head event_handler_list;
> @@ -2638,7 +2643,8 @@ struct ib_device *ib_alloc_device(size_t size);
> void ib_dealloc_device(struct ib_device *device);
>
> void ib_get_device_fw_str(struct ib_device *device, char *str);
> -
> +int ib_device_alloc_name(struct ib_device *ibdev, const char *pattern);
> +void ib_device_get_name(struct ib_device *ibdev, char *name);
> int ib_register_device(struct ib_device *device,
> int (*port_callback)(struct ib_device *,
> u8, struct kobject *));
> --
> 2.14.4
>
^ permalink raw reply
* Re: WARNING: refcount bug in igmp_start_timer
From: syzbot @ 2018-09-20 20:06 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
In-Reply-To: <0000000000002b42040573b8495a@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: ae596de1a0c8 Compiler Attributes: naked can be shared
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15bdb156400000
kernel config: https://syzkaller.appspot.com/x/.config?x=5fa12be50bca08d8
dashboard link: https://syzkaller.appspot.com/bug?extid=e28037ac1c96d2a86e89
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=178537da400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e28037ac1c96d2a86e89@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
------------[ cut here ]------------
refcount_t: increment on 0; use-after-free.
WARNING: CPU: 1 PID: 13494 at lib/refcount.c:153
refcount_inc_checked+0x5d/0x70 lib/refcount.c:153
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 13494 Comm: syz-executor0 Not tainted 4.19.0-rc4+ #26
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
panic+0x238/0x4e7 kernel/panic.c:184
__warn.cold.8+0x163/0x1ba kernel/panic.c:536
report_bug+0x254/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993
RIP: 0010:refcount_inc_checked+0x5d/0x70 lib/refcount.c:153
Code: 1d a2 83 91 06 31 ff 89 de e8 7f 8e ef fd 84 db 75 df e8 a6 8d ef fd
48 c7 c7 40 82 44 88 c6 05 82 83 91 06 01 e8 63 74 b9 fd <0f> 0b eb c3 0f
1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 55 48 89
RSP: 0018:ffff8801c7fdeca0 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8164fce5 RDI: 0000000000000005
RBP: ffff8801c7fdeca8 R08: ffff8801c67da1c0 R09: ffffed003b5e3ee2
R10: ffffed003b5e3ee2 R11: ffff8801daf1f717 R12: 0000000000000000
R13: 0000000000000008 R14: ffff8801b465f640 R15: dffffc0000000000
igmp_start_timer+0xaf/0xe0 net/ipv4/igmp.c:217
igmp_mod_timer net/ipv4/igmp.c:255 [inline]
igmp_heard_query net/ipv4/igmp.c:1026 [inline]
igmp_rcv+0x190e/0x3020 net/ipv4/igmp.c:1061
ip_local_deliver_finish+0x2e9/0xda0 net/ipv4/ip_input.c:215
NF_HOOK include/linux/netfilter.h:287 [inline]
ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256
dst_input include/net/dst.h:450 [inline]
ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415
NF_HOOK include/linux/netfilter.h:287 [inline]
ip_rcv+0xed/0x610 net/ipv4/ip_input.c:524
__netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4891
__netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5001
netif_receive_skb_internal+0x12c/0x620 net/core/dev.c:5104
napi_frags_finish net/core/dev.c:5642 [inline]
napi_gro_frags+0x75a/0xc90 net/core/dev.c:5715
tun_get_user+0x31d5/0x42a0 drivers/net/tun.c:1965
tun_chr_write_iter+0xb9/0x154 drivers/net/tun.c:2010
call_write_iter include/linux/fs.h:1808 [inline]
do_iter_readv_writev+0x8b0/0xa80 fs/read_write.c:680
do_iter_write+0x185/0x5f0 fs/read_write.c:959
vfs_writev+0x1f1/0x360 fs/read_write.c:1004
do_writev+0x11a/0x310 fs/read_write.c:1039
__do_sys_writev fs/read_write.c:1112 [inline]
__se_sys_writev fs/read_write.c:1109 [inline]
__x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457531
Code: 75 14 b8 14 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 54 b5 fb ff c3 48
83 ec 08 e8 1a 2d 00 00 48 89 04 24 b8 14 00 00 00 0f 05 <48> 8b 3c 24 48
89 c2 e8 63 2d 00 00 48 89 d0 48 83 c4 08 48 3d 01
RSP: 002b:00007f1448a89ba0 EFLAGS: 00000293 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 000000000000002a RCX: 0000000000457531
RDX: 0000000000000001 RSI: 00007f1448a89bf0 RDI: 00000000000000f0
RBP: 0000000020000240 R08: 00000000000000f0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000293 R12: 00000000ffffffff
R13: 00000000004d7938 R14: 00000000004c48b4 R15: 0000000000000000
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply
* Re: [PATCH v2 0/2] hv_netvsc: associate VF and PV device by serial number
From: Lorenzo Pieralisi @ 2018-09-20 14:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: kys, haiyangz, sthemmin, devel, netdev, linux-pci
In-Reply-To: <20180914195457.20433-1-sthemmin@microsoft.com>
On Fri, Sep 14, 2018 at 12:54:55PM -0700, Stephen Hemminger wrote:
> The Hyper-V implementation of PCI controller has concept of 32 bit serial number
> (not to be confused with PCI-E serial number). This value is sent in the protocol
> from the host to indicate SR-IOV VF device is attached to a synthetic NIC.
>
> Using the serial number (instead of MAC address) to associate the two devices
> avoids lots of potential problems when there are duplicate MAC addresses from
> tunnels or layered devices.
>
> The patch set is broken into two parts, one is for the PCI controller
> and the other is for the netvsc device. Normally, these go through different
> trees but sending them together here for better review. The PCI changes
> were submitted previously, but the main review comment was "why do you
> need this?". This is why.
The question was more whether we should convert this serial number into
a PCI slot number (that has user space visibility and that is what you are
after) to improve the current matching, I do not question why you need
it, just for the records.
Lorenzo
> v2 - slot name can be shorter.
> remove locking when creating pci_slots; see comment for explaination
>
> Stephen Hemminger (2):
> PCI: hv: support reporting serial number as slot information
> hv_netvsc: pair VF based on serial number
>
> drivers/net/hyperv/netvsc.c | 3 ++
> drivers/net/hyperv/netvsc_drv.c | 58 ++++++++++++++++-------------
> drivers/pci/controller/pci-hyperv.c | 37 ++++++++++++++++++
> 3 files changed, 73 insertions(+), 25 deletions(-)
>
> --
> 2.18.0
>
^ 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