* Re: [Patch net-next] ipv4: initialize ra_mutex in inet_init_net()
From: Cong Wang @ 2018-09-20 17:05 UTC (permalink / raw)
To: Kirill Tkhai; +Cc: Linux Kernel Network Developers
In-Reply-To: <e425ef6d-f94c-731b-817a-6c743b777733@virtuozzo.com>
On Thu, Sep 20, 2018 at 2:04 AM Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>
> On 20.09.2018 0:28, Cong Wang wrote:
> You added me to CC, so you probably want to know my opinion about this.
> Since it's not a real problem fix, but just a refactoring, I say you
> my opinion, how this refactoring may be made better. If you don't want
> to know my opinion, you may consider not to CC me.
Sure, with respects to your opinions, I prefer to drop it happily.
Thanks.
^ permalink raw reply
* [PATCH] net: lan78xx: Avoid unnecessary self assignment
From: Nathan Chancellor @ 2018-09-20 22:48 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, David S. Miller
Cc: netdev, linux-usb, linux-kernel, Nathan Chancellor
Clang warns when a variable is assigned to itself.
drivers/net/usb/lan78xx.c:940:11: warning: explicitly assigning value of
variable of type 'u32' (aka 'unsigned int') to itself [-Wself-assign]
offset = offset;
~~~~~~ ^ ~~~~~~
1 warning generated.
Reorder the if statement to acheive the same result and avoid a self
assignment warning.
Link: https://github.com/ClangBuiltLinux/linux/issues/129
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/usb/lan78xx.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 04f0a094d864..656441d9a955 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -936,11 +936,9 @@ static int lan78xx_read_otp(struct lan78xx_net *dev, u32 offset,
ret = lan78xx_read_raw_otp(dev, 0, 1, &sig);
if (ret == 0) {
- if (sig == OTP_INDICATOR_1)
- offset = offset;
- else if (sig == OTP_INDICATOR_2)
+ if (sig == OTP_INDICATOR_2)
offset += 0x100;
- else
+ else if (sig != OTP_INDICATOR_1)
ret = -EINVAL;
if (!ret)
ret = lan78xx_read_raw_otp(dev, offset, length, data);
--
2.19.0
^ permalink raw reply related
* Re: [PATCH 2/3] net: Register af_inet_ops earlier
From: Cong Wang @ 2018-09-20 17:03 UTC (permalink / raw)
To: Kirill Tkhai
Cc: David Miller, Hideaki YOSHIFUJI, avagin, Eric Dumazet,
Eric W. Biederman, Linux Kernel Network Developers
In-Reply-To: <153743469969.21312.2316847616468846087.stgit@localhost.localdomain>
On Thu, Sep 20, 2018 at 2:12 AM Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>
> This function just initializes locks and defaults.
> Let register it before other pernet operation,
> since some of them potentially may relay on that.
>
> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
It adds no benefits but potential risks on error path
ordering, it is never late to bring this up again when any
future change needs it, until that:
Nacked-by: Cong Wang <xiyou.wangcong@gmail.com>
^ permalink raw reply
* Re: [PATCH 3/3] ipv4: initialize ra_mutex in inet_init_net()
From: Cong Wang @ 2018-09-20 17:01 UTC (permalink / raw)
To: Kirill Tkhai
Cc: David Miller, Hideaki YOSHIFUJI, avagin, Eric Dumazet,
Eric W. Biederman, Linux Kernel Network Developers
In-Reply-To: <153743472937.21312.592412049853708197.stgit@localhost.localdomain>
On Thu, Sep 20, 2018 at 2:12 AM Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
>
> From: Cong Wang <xiyou.wangcong@gmail.com>
>
> ra_mutex is a IPv4 specific mutex, it is inside struct netns_ipv4,
> but its initialization is in the generic netns code, setup_net().
>
> Move it to IPv4 specific net init code, inet_init_net().
>
> Fixes: d9ff3049739e ("net: Replace ip_ra_lock with per-net mutex")
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> Acked-by: Kirill Tkhai <ktkhai@virtuozzo.com>
I regret for wasting my time on this, so:
Nacked-by: Cong Wang <xiyou.wangcong@gmail.com>
Let's just leave the current code as it is.
^ permalink raw reply
* Re: [PATCH net] ixgbe: check return value of napi_complete_done()
From: Song Liu @ 2018-09-20 22:42 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Eric Dumazet, netdev, intel-wired-lan@lists.osuosl.org,
Kernel Team, stable@vger.kernel.org, Alexei Starovoitov
In-Reply-To: <2ca0e823642d232092017f66e8151652e22e74a1.camel@intel.com>
> On Sep 20, 2018, at 2:01 PM, Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
>
> On Thu, 2018-09-20 at 13:35 -0700, Eric Dumazet wrote:
>> 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'.
>
> Agreed, which is why I have our validation and developers looking into it,
> while we test the current patch from Song.
I figured out what is the issue here. And I have a proposal to fix it. I
have verified that this fixes the issue in our tests. But Alexei suggests
that it may not be the right way to fix.
Here is what happened:
netpoll tries to send skb with netpoll_start_xmit(). If that fails, it
calls netpoll_poll_dev(), which calls ndo_poll_controller(). Then, in
the driver, ndo_poll_controller() calls napi_schedule() for ALL NAPIs
within the same NIC.
This is problematic, because at the end napi_schedule() calls:
____napi_schedule(this_cpu_ptr(&softnet_data), n);
which attached these NAPIs to softnet_data on THIS CPU. This is done
via napi->poll_list.
Then suddenly ksoftirqd on this CPU owns multiple NAPIs. And it will
not give up the ownership until it calls napi_complete_done(). However,
for a very busy server, we usually use 16 CPUs to poll NAPI, so this
CPU can easily be overloaded. And as a result, each call of napi->poll()
will hit budget (of 64), and it will not call napi_complete_done(),
and the NAPI stays in the poll_list of this CPU.
When this happens, the host usually cannot get out of this state until
we throttle/stop client traffic.
I am pretty confident this is what happened. Please let me know if
anything above doesn't make sense.
Here is my proposal to fix it: Instead of polling all NAPIs within one
NIC, I would have netpoll to only poll the NAPI that will free space
for netpoll_start_xmit(). I attached my two RFC patches to the end of
this email.
I chatted with Alexei about this. He think polling only one NAPI may
not guarantee netpoll make progress with the TX queue we are aiming
for. Also, the bigger problem may be the fact that NAPIs could get
pinned to one CPU and cannot get released.
At this point, I really don't know what is the best way to fix this.
I will also work on a repro with netperf.
Please let me know your suggestions.
Thanks,
Song
========================= RFCs ============================
>From 7b6d1d0e21bc7a0034dbcacfdaaec95a0e5f5b14 Mon Sep 17 00:00:00 2001
From: Song Liu <songliubraving@fb.com>
Date: Thu, 20 Sep 2018 13:09:26 -0700
Subject: [RFC net 1/2] net: netpoll: when failed to send a message, only poll
the target NAPI
Currently, netpoll polls all NAPIs in the NIC if it fails to send data to
one TX queue. This is not necessary and sometimes problematic. This is
because ndo_poll_controller() calls napi_schedule() for all NAPIs in the
NIC, and attach available NAPIs to this_cpu's softnet_data->poll_list.
Modern highend NIC has tens of NAPIs, and requires multiple CPUs to poll
the data from the queues. Attaching multiple NAPIs to one CPU's poll_list
fan-in softirq work of multiple CPUs to one CPU. As a result, we see one
CPU pegged in ksoftirqd, while other CPUs cannot get assgined work.
This patch fixes this issue by only polls target NAPI when send fails.
New hook ndo_netpoll_get_napi() is added for the driver to map busy
TX queue to the NAPI to poll. If the driver implements this hook, netpoll
will only poll the NAPI of the target TX queue.
Signed-off-by: Song Liu <songliubraving@fb.com>
---
include/linux/netdevice.h | 5 +++++
net/core/netpoll.c | 30 ++++++++++++++++++++++++------
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 6a7ac01fa605..576414b150ff 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1033,6 +1033,9 @@ struct dev_ifalias {
*
* void (*ndo_poll_controller)(struct net_device *dev);
* Run napi_schedule() for all NAPI within this device.
+ * struct napi_struct* (*ndo_netpoll_get_napi)(struct net_device *dev,
+ * struct netdev_queue *txq);
+ * Returns the NAPI to poll for the given TX queue.
*
* SR-IOV management functions.
* int (*ndo_set_vf_mac)(struct net_device *dev, int vf, u8* mac);
@@ -1267,6 +1270,8 @@ struct net_device_ops {
__be16 proto, u16 vid);
#ifdef CONFIG_NET_POLL_CONTROLLER
void (*ndo_poll_controller)(struct net_device *dev);
+ struct napi_struct* (*ndo_netpoll_get_napi)(struct net_device *dev,
+ struct netdev_queue *txq);
int (*ndo_netpoll_setup)(struct net_device *dev,
struct netpoll_info *info);
void (*ndo_netpoll_cleanup)(struct net_device *dev);
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 57557a6a950c..218a46acbdfc 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -187,7 +187,7 @@ static void poll_napi(struct net_device *dev)
}
}
-static void netpoll_poll_dev(struct net_device *dev)
+static void netpoll_poll_dev(struct net_device *dev, struct napi_struct *napi)
{
const struct net_device_ops *ops;
struct netpoll_info *ni = rcu_dereference_bh(dev->npinfo);
@@ -210,10 +210,23 @@ static void netpoll_poll_dev(struct net_device *dev)
return;
}
- /* Process pending work on NIC */
- ops->ndo_poll_controller(dev);
+ if (napi) {
+ int cpu = smp_processor_id();
- poll_napi(dev);
+ /* If we know which NAPI to poll, just poll it. */
+ napi_schedule(napi);
+ if (cmpxchg(&napi->poll_owner, -1, cpu) == -1) {
+ poll_one_napi(napi);
+ smp_store_release(&napi->poll_owner, -1);
+ }
+ } else {
+ /* If we are not sure which NAPI to poll, process all
+ * pending work on NIC.
+ */
+ ops->ndo_poll_controller(dev);
+
+ poll_napi(dev);
+ }
up(&ni->dev_lock);
@@ -303,7 +316,7 @@ static struct sk_buff *find_skb(struct netpoll *np, int len, int reserve)
if (!skb) {
if (++count < 10) {
- netpoll_poll_dev(np->dev);
+ netpoll_poll_dev(np->dev, NULL);
goto repeat;
}
return NULL;
@@ -345,8 +358,13 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
/* don't get messages out of order, and no recursion */
if (skb_queue_len(&npinfo->txq) == 0 && !netpoll_owner_active(dev)) {
struct netdev_queue *txq;
+ struct napi_struct *napi;
txq = netdev_pick_tx(dev, skb, NULL);
+ if (dev->netdev_ops->ndo_netpoll_get_napi)
+ napi = dev->netdev_ops->ndo_netpoll_get_napi(dev, txq);
+ else
+ napi = NULL;
/* try until next clock tick */
for (tries = jiffies_to_usecs(1)/USEC_PER_POLL;
@@ -363,7 +381,7 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
}
/* tickle device maybe there is some cleanup */
- netpoll_poll_dev(np->dev);
+ netpoll_poll_dev(np->dev, napi);
udelay(USEC_PER_POLL);
}
--
2.17.1
>From 9f6bd53cf011820054802f17ede2f73de0ec7d41 Mon Sep 17 00:00:00 2001
From: Song Liu <songliubraving@fb.com>
Date: Thu, 20 Sep 2018 15:08:33 -0700
Subject: [RFC net 2/2] net: bnxt: add ndo_netpoll_get_napi
Signed-off-by: Song Liu <songliubraving@fb.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 177587f9c3f1..0a82a61a16d9 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -7685,6 +7685,20 @@ static void bnxt_poll_controller(struct net_device *dev)
napi_schedule(&txr->bnapi->napi);
}
}
+
+static struct napi_struct* bnxt_netpoll_get_napi(struct net_device *dev,
+ struct netdev_queue *txq)
+{
+ struct bnxt *bp = netdev_priv(dev);
+ int i;
+
+ for (i = 0; i < bp->tx_nr_rings; i++) {
+ struct bnxt_tx_ring_info *txr = &bp->tx_ring[i];
+ if (txq == netdev_get_tx_queue(dev, txr->txq_index))
+ return &txr->bnapi->napi;
+ }
+ return NULL;
+}
#endif
static void bnxt_timer(struct timer_list *t)
@@ -8522,6 +8536,7 @@ static const struct net_device_ops bnxt_netdev_ops = {
#endif
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = bnxt_poll_controller,
+ .ndo_netpoll_get_napi = bnxt_netpoll_get_napi,
#endif
.ndo_setup_tc = bnxt_setup_tc,
#ifdef CONFIG_RFS_ACCEL
^ permalink raw reply related
* [PATCH] net: fddi: skfp: Remove unused function
From: Nathan Chancellor @ 2018-09-20 22:36 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, Nathan Chancellor
Clang warns when a variable is assigned to itself.
drivers/net/fddi/skfp/pcmplc.c:1257:6: warning: explicitly assigning
value of variable of type 'int' to itself [-Wself-assign]
phy = phy ; on_off = on_off ;
~~~ ^ ~~~
drivers/net/fddi/skfp/pcmplc.c:1257:21: warning: explicitly assigning
value of variable of type 'int' to itself [-Wself-assign]
phy = phy ; on_off = on_off ;
~~~~~~ ^ ~~~~~~
2 warnings generated.
Turns out this entire function doesn't actually do anything since
SK_UNUSED is just casting the pointer to void. Remove it to silence
this Clang warning.
Link: https://github.com/ClangBuiltLinux/linux/issues/128
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/fddi/skfp/ecm.c | 3 ---
drivers/net/fddi/skfp/h/cmtdef.h | 1 -
drivers/net/fddi/skfp/pcmplc.c | 11 -----------
3 files changed, 15 deletions(-)
diff --git a/drivers/net/fddi/skfp/ecm.c b/drivers/net/fddi/skfp/ecm.c
index eee9ba91346a..c813e462183d 100644
--- a/drivers/net/fddi/skfp/ecm.c
+++ b/drivers/net/fddi/skfp/ecm.c
@@ -30,7 +30,6 @@
*
* The following external HW dependent functions are referenced :
* sm_pm_bypass_req()
- * sm_pm_ls_latch()
* sm_pm_get_ls()
*
* The following HW dependent events are required :
@@ -356,8 +355,6 @@ static void ecm_fsm(struct s_smc *smc, int cmd)
*/
start_ecm_timer(smc,smc->s.ecm_check_poll,0) ;
smc->e.ecm_line_state = TRUE ; /* flag to pcm: report Q/HLS */
- (void) sm_pm_ls_latch(smc,PA,1) ; /* enable line state latch */
- (void) sm_pm_ls_latch(smc,PB,1) ; /* enable line state latch */
ACTIONS_DONE() ;
break ;
case EC6_CHECK :
diff --git a/drivers/net/fddi/skfp/h/cmtdef.h b/drivers/net/fddi/skfp/h/cmtdef.h
index 5d6891154367..a12f464941ed 100644
--- a/drivers/net/fddi/skfp/h/cmtdef.h
+++ b/drivers/net/fddi/skfp/h/cmtdef.h
@@ -513,7 +513,6 @@ void pcm_status_state(struct s_smc *smc, int np, int *type, int *state,
void plc_config_mux(struct s_smc *smc, int mux);
void sm_lem_evaluate(struct s_smc *smc);
void mac_update_counter(struct s_smc *smc);
-void sm_pm_ls_latch(struct s_smc *smc, int phy, int on_off);
void sm_ma_control(struct s_smc *smc, int mode);
void sm_mac_check_beacon_claim(struct s_smc *smc);
void config_mux(struct s_smc *smc, int mux);
diff --git a/drivers/net/fddi/skfp/pcmplc.c b/drivers/net/fddi/skfp/pcmplc.c
index a9ecf923f63d..6ef44c480bd5 100644
--- a/drivers/net/fddi/skfp/pcmplc.c
+++ b/drivers/net/fddi/skfp/pcmplc.c
@@ -30,7 +30,6 @@
* The following external HW dependent functions are referenced :
* sm_pm_control()
* sm_ph_linestate()
- * sm_pm_ls_latch()
*
* The following HW dependent events are required :
* PC_QLS
@@ -1248,16 +1247,6 @@ static void sm_ph_lem_stop(struct s_smc *smc, int np)
CLEAR(PLC(np,PL_INTR_MASK),PL_LE_CTR) ;
}
-/* ARGSUSED */
-void sm_pm_ls_latch(struct s_smc *smc, int phy, int on_off)
-/* int on_off; en- or disable ident. ls */
-{
- SK_UNUSED(smc) ;
-
- phy = phy ; on_off = on_off ;
-}
-
-
/*
* PCM pseudo code
* receive actions are called AFTER the bit n is received,
--
2.19.0
^ permalink raw reply related
* Re: [PATCH net-next 4/5] ipv6: do not drop vrf udp multicast packets
From: Mike Manning @ 2018-09-20 16:50 UTC (permalink / raw)
To: Paolo Abeni, netdev; +Cc: Dewi Morgan
In-Reply-To: <09797df92f76885b0e3244a3aca68dbf07a09a3a.camel@redhat.com>
On 20/09/2018 14:02, Paolo Abeni wrote:
> Hi,
>
> On Thu, 2018-09-20 at 09:58 +0100, Mike Manning wrote:
>> diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
>> index 108f5f88ec98..fc60f297d95b 100644
>> --- a/net/ipv6/ip6_input.c
>> +++ b/net/ipv6/ip6_input.c
>> @@ -325,9 +325,12 @@ static int ip6_input_finish(struct net *net, struct sock *sk, struct sk_buff *sk
>> {
>> const struct inet6_protocol *ipprot;
>> struct inet6_dev *idev;
>> + struct net_device *dev;
>> unsigned int nhoff;
>> + int sdif = inet6_sdif(skb);
>> int nexthdr;
>> bool raw;
>> + bool deliver;
>> bool have_final = false;
> Please, try instead to sort the variable in reverse x-mas tree order.
Will do.
>>
>> /*
>> @@ -371,9 +374,27 @@ static int ip6_input_finish(struct net *net, struct sock *sk, struct sk_buff *sk
>> skb_postpull_rcsum(skb, skb_network_header(skb),
>> skb_network_header_len(skb));
>> hdr = ipv6_hdr(skb);
>> - if (ipv6_addr_is_multicast(&hdr->daddr) &&
>> - !ipv6_chk_mcast_addr(skb->dev, &hdr->daddr,
>> - &hdr->saddr) &&
>> +
>> + /* skb->dev passed may be master dev for vrfs. */
>> + if (sdif) {
>> + rcu_read_lock();
> AFAICS, the rcu lock is already acquired at the beginning of
> ip6_input_finish(), not need to acquire it here again.
Nice catch, I will remove this.
> + dev = dev_get_by_index_rcu(dev_net(skb->dev),
>> + sdif);
>> + if (!dev) {
>> + rcu_read_unlock();
>> + kfree_skb(skb);
>> + return -ENODEV;
>> + }
>> + } else {
>> + dev = skb->dev;
> The above fragment of code is a recurring pattern in this series,
> perhaps adding an helper for it would reduce code duplication ?
This pattern of checking the secondary device index is used only twice, both in this file.
But with now one instance having the rcu lock handling, and the other not, I cannot refactor this.
>
> Cheers,
>
> Paolo
>
Thanks for the review! I will wait for further comments before producing a v1 of the series.
Regards, Mike
^ permalink raw reply
* Re: [PATCH v2 0/2] hv_netvsc: associate VF and PV device by serial number
From: Stephen Hemminger @ 2018-09-20 16:50 UTC (permalink / raw)
To: Lorenzo Pieralisi; +Cc: kys, haiyangz, sthemmin, devel, netdev, linux-pci
In-Reply-To: <20180920141820.GD838@e107981-ln.cambridge.arm.com>
On Thu, 20 Sep 2018 15:18:20 +0100
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> 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.
The name slot is way overloaded in this context.
There is
windows slot number which comes from Hyperv
pci address slot which pci-hyperv sets from windows slot
pci slot api value which for normal devices comes from ACPI
this patch gets it from serial number
The netvsc driver needed to be able to find a PCI device based on the serial
number. The serial number was not visible in any current PCI-hyperv controller
values. The windows slot (wslot) is not the same the serial number.
^ 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 16:46 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, 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: <20180920164039.GM3519@mtr-leonro.mtl.com>
On Thu, Sep 20, 2018 at 07:40:39PM +0300, Leon Romanovsky wrote:
> > > 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..
>
> And what should I do now with this knowledge?
Maybe I can send it today..
Jason
^ permalink raw reply
* Re: [PATCH rdma-next 1/5] RDMA/core: Provide getter and setter to access IB device name
From: Leon Romanovsky @ 2018-09-20 16:40 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, 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: <20180920151541.GC30219@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]
On Thu, Sep 20, 2018 at 09:15:41AM -0600, Jason Gunthorpe wrote:
> 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
Yes, I read, it was mentioned in the cover letter.
>
> > 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..
And what should I do now with this knowledge?
>
> > 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.
I planned to change it in the future by moving to different name scheme
with unique naming.
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [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
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