* [REPORT] net: e100: possible data races
From: Jia-Ju Bai @ 2018-10-03 13:03 UTC (permalink / raw)
To: jeffrey.t.kirsher, davem
Cc: intel-wired-lan, netdev, Linux Kernel Mailing List
CPU0:
e100_set_multicast_list
e100_exec_cb
line 854: spin_lock_irqsave()
line 866: e100_configure (function pointer)
line 1114: nic->flags [READ]
line 1123: nic->flags [READ]
CPU1:
e100_watchdog
line 1731: nic->flags [WRITE]
line 1733: nic->flags [WRITE]
As for nic->flags, the WRITE operations in CPU0 are performed
with holding a spinlock, but the READ operations in CPU1 are performed
without holding this spinlock, so there may exist data races.
These possible races are detected by a runtime testing.
I do not find a good way to fix these races, so I only report them.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH net-next] tls: Add support for inplace records encryption
From: David Miller @ 2018-10-03 6:04 UTC (permalink / raw)
To: vakul.garg; +Cc: netdev, borisp, aviadye, davejwatson, doronrk
In-Reply-To: <20180930023435.22864-1-vakul.garg@nxp.com>
From: Vakul Garg <vakul.garg@nxp.com>
Date: Sun, 30 Sep 2018 08:04:35 +0530
> Presently, for non-zero copy case, separate pages are allocated for
> storing plaintext and encrypted text of records. These pages are stored
> in sg_plaintext_data and sg_encrypted_data scatterlists inside record
> structure. Further, sg_plaintext_data & sg_encrypted_data are passed
> to cryptoapis for record encryption. Allocating separate pages for
> plaintext and encrypted text is inefficient from both required memory
> and performance point of view.
>
> This patch adds support of inplace encryption of records. For non-zero
> copy case, we reuse the pages from sg_encrypted_data scatterlist to
> copy the application's plaintext data. For the movement of pages from
> sg_encrypted_data to sg_plaintext_data scatterlists, we introduce a new
> function move_to_plaintext_sg(). This function add pages into
> sg_plaintext_data from sg_encrypted_data scatterlists.
>
> tls_do_encryption() is modified to pass the same scatterlist as both
> source and destination into aead_request_set_crypt() if inplace crypto
> has been enabled. A new ariable 'inplace_crypto' has been introduced in
> record structure to signify whether the same scatterlist can be used.
> By default, the inplace_crypto is enabled in get_rec(). If zero-copy is
> used (i.e. plaintext data is not copied), inplace_crypto is set to '0'.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: dsa: lantiq: Fix path in MAINTAINERS file
From: David Miller @ 2018-10-03 5:58 UTC (permalink / raw)
To: hauke; +Cc: netdev
In-Reply-To: <20180929112630.9872-1-hauke@hauke-m.de>
From: Hauke Mehrtens <hauke@hauke-m.de>
Date: Sat, 29 Sep 2018 13:26:30 +0200
> The MAINTAINERS file contained the wrong file name of the driver.
>
> Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
> Reported-by: Joe Perches <joe@perches.com>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Applied.
^ permalink raw reply
* Re: [PATCH] hv_netvsc: remove ndo_poll_controller
From: David Miller @ 2018-10-03 5:57 UTC (permalink / raw)
To: stephen; +Cc: netdev, sthemmin, haiyangz, edumazet
In-Reply-To: <20180929125256.25994-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Sat, 29 Sep 2018 14:52:56 +0200
> Similar to other patches from ERic.
>
> As diagnosed by Song Liu, ndo_poll_controller() can
> be very dangerous on loaded hosts, since the cpu
> calling ndo_poll_controller() might steal all NAPI
> contexts (for all RX/TX queues of the NIC). This capture
> can last for unlimited amount of time, since one
> cpu is generally not able to drain all the queues under load.
>
> In netvsc driver it uses NAPI for TX completions. The default
> poll_napi will do this for us now and avoid the capture.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next] MAINTAINERS: Fix wrong include file path
From: David Miller @ 2018-10-03 5:56 UTC (permalink / raw)
To: andrew; +Cc: netdev
In-Reply-To: <1538251022-13348-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sat, 29 Sep 2018 21:57:02 +0200
> Fix the patch for the mv88e6xxx.h header file in MAINTAINERS
>
> Reported-by: Joe Perches <joe@perches.com>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied.
^ permalink raw reply
* Re: [PATCH v2 08/22] soc/fsl/qbman_portals: add APIs to retrieve the probing status
From: Robin Murphy @ 2018-10-03 12:27 UTC (permalink / raw)
To: Laurentiu Tudor, Leo Li
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Netdev, lkml,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Roy Pledge, Madalin-cristian Bucur, David Miller, Shawn Guo,
Bharat Bhushan
In-Reply-To: <c4ff9977-c730-be48-8046-97da663c5a23@nxp.com>
On 2018-10-03 11:50 AM, Laurentiu Tudor wrote:
> Hi Leo,
>
> On 27.09.2018 23:03, Li Yang wrote:
>> On Wed, Sep 26, 2018 at 8:26 AM <laurentiu.tudor@nxp.com> wrote:
>>>
>>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>>
>>> Add a couple of new APIs to check the probing status of the required
>>> cpu bound qman and bman portals:
>>> 'int bman_portals_probed()' and 'int qman_portals_probed()'.
>>> They return the following values.
>>> * 1 if qman/bman portals were all probed correctly
>>> * 0 if qman/bman portals were not yet probed
>>> * -1 if probing of qman/bman portals failed
>>> Drivers that use qman/bman portal driver services are required to use
>>> these APIs before calling any functions exported by these drivers or
>>> otherwise they will crash the kernel.
>>> First user will be the dpaa1 ethernet driver, coming in a subsequent
>>> patch.
>>>
>>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>> ---
>>> drivers/soc/fsl/qbman/bman_portal.c | 10 ++++++++++
>>> drivers/soc/fsl/qbman/qman_portal.c | 10 ++++++++++
>>> include/soc/fsl/bman.h | 8 ++++++++
>>> include/soc/fsl/qman.h | 9 +++++++++
>>> 4 files changed, 37 insertions(+)
>>>
>>> diff --git a/drivers/soc/fsl/qbman/bman_portal.c b/drivers/soc/fsl/qbman/bman_portal.c
>>> index f9edd28894fd..8048d35de8a2 100644
>>> --- a/drivers/soc/fsl/qbman/bman_portal.c
>>> +++ b/drivers/soc/fsl/qbman/bman_portal.c
>>> @@ -32,6 +32,7 @@
>>>
>>> static struct bman_portal *affine_bportals[NR_CPUS];
>>> static struct cpumask portal_cpus;
>>> +static int __bman_portals_probed;
>>> /* protect bman global registers and global data shared among portals */
>>> static DEFINE_SPINLOCK(bman_lock);
>>>
>>> @@ -85,6 +86,12 @@ static int bman_online_cpu(unsigned int cpu)
>>> return 0;
>>> }
>>>
>>> +int bman_portals_probed(void)
>>> +{
>>> + return __bman_portals_probed;
>>> +}
>>> +EXPORT_SYMBOL_GPL(bman_portals_probed);
>>> +
>>> static int bman_portal_probe(struct platform_device *pdev)
>>> {
>>> struct device *dev = &pdev->dev;
>>> @@ -148,6 +155,7 @@ static int bman_portal_probe(struct platform_device *pdev)
>>> spin_lock(&bman_lock);
>>> cpu = cpumask_next_zero(-1, &portal_cpus);
>>> if (cpu >= nr_cpu_ids) {
>>> + __bman_portals_probed = 1;
>>
>> What if the last CPU is not used for portals? Is there a hard
>> requirement that all CPUs need to be used for portal?
>
> As far as I know, in the current driver design a portal is required for
> each CPU.
>
>> What happens if the last CPU is offline?
>
> Can this happen at probe time?
As I understand things, yes - if you boot with "maxcpus=1", only the
boot CPU will be onlined by the kernel, but the others can still be
brought up manually by userspace later.
Robin.
> Anyway, I'm not sure that the driver is even aware of cpu hotplug but
> I'll let Roy comment on this one.
>
>>
>>> /* unassigned portal, skip init */
>>> spin_unlock(&bman_lock);
>>> return 0;
>>> @@ -173,6 +181,8 @@ static int bman_portal_probe(struct platform_device *pdev)
>>> err_ioremap2:
>>> memunmap(pcfg->addr_virt_ce);
>>> err_ioremap1:
>>> + __bman_portals_probed = 1;
>>> +
>>
>> There are other error paths that not covered.
>
> Right, thanks for pointing. On top of that, the assigned value here
> should be -1 to signal error (instead of 1 which signals success).
>
> ---
> Best Regards, Laurentiu
>
^ permalink raw reply
* [PATCH] soc: qcom: qmi_interface: Limit txn ids to U16_MAX
From: Arun Kumar Neelakantam @ 2018-10-03 5:40 UTC (permalink / raw)
To: davem, bjorn.andersson, clew
Cc: netdev, linux-kernel, linux-arm-msm, fw, hannes, dvlasenk,
nicolas.dechesne, Arun Kumar Neelakantam, Andy Gross, David Brown,
open list:ARM/QUALCOMM SUPPORT
Txn IDs created up to INT_MAX cause overflow while storing
the IDs in u16 type supported by QMI header.
Limit the txn IDs max value to U16_MAX to avoid overflow.
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
---
drivers/soc/qcom/qmi_interface.c | 2 +-
include/linux/soc/qcom/qmi.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/qcom/qmi_interface.c b/drivers/soc/qcom/qmi_interface.c
index 938ca41c..c239a28 100644
--- a/drivers/soc/qcom/qmi_interface.c
+++ b/drivers/soc/qcom/qmi_interface.c
@@ -318,7 +318,7 @@ int qmi_txn_init(struct qmi_handle *qmi, struct qmi_txn *txn,
txn->dest = c_struct;
mutex_lock(&qmi->txn_lock);
- ret = idr_alloc_cyclic(&qmi->txns, txn, 0, INT_MAX, GFP_KERNEL);
+ ret = idr_alloc_cyclic(&qmi->txns, txn, 0, U16_MAX, GFP_KERNEL);
if (ret < 0)
pr_err("failed to allocate transaction id\n");
diff --git a/include/linux/soc/qcom/qmi.h b/include/linux/soc/qcom/qmi.h
index f4de336..5efa2b6 100644
--- a/include/linux/soc/qcom/qmi.h
+++ b/include/linux/soc/qcom/qmi.h
@@ -166,7 +166,7 @@ struct qmi_ops {
struct qmi_txn {
struct qmi_handle *qmi;
- int id;
+ u16 id;
struct mutex lock;
struct completion completion;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 05/16] igbvf: Replace spin_is_locked() with lockdep
From: Lance Roy @ 2018-10-03 5:38 UTC (permalink / raw)
To: linux-kernel
Cc: Paul E. McKenney, Lance Roy, Jeff Kirsher, David S. Miller,
intel-wired-lan, netdev
In-Reply-To: <20181003053902.6910-1-ldr709@gmail.com>
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy <ldr709@gmail.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: intel-wired-lan@lists.osuosl.org
Cc: <netdev@vger.kernel.org>
---
drivers/net/ethernet/intel/igbvf/mbx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igbvf/mbx.c b/drivers/net/ethernet/intel/igbvf/mbx.c
index 163e5838f7c2..a3cd7ac48d4b 100644
--- a/drivers/net/ethernet/intel/igbvf/mbx.c
+++ b/drivers/net/ethernet/intel/igbvf/mbx.c
@@ -241,7 +241,7 @@ static s32 e1000_write_mbx_vf(struct e1000_hw *hw, u32 *msg, u16 size)
s32 err;
u16 i;
- WARN_ON_ONCE(!spin_is_locked(&hw->mbx_lock));
+ lockdep_assert_held(&hw->mbx_lock);
/* lock the mailbox to prevent pf/vf race condition */
err = e1000_obtain_mbx_lock_vf(hw);
@@ -279,7 +279,7 @@ static s32 e1000_read_mbx_vf(struct e1000_hw *hw, u32 *msg, u16 size)
s32 err;
u16 i;
- WARN_ON_ONCE(!spin_is_locked(&hw->mbx_lock));
+ lockdep_assert_held(&hw->mbx_lock);
/* lock the mailbox to prevent pf/vf race condition */
err = e1000_obtain_mbx_lock_vf(hw);
--
2.19.0
^ permalink raw reply related
* Re: pull request: bluetooth-next 2018-09-30
From: David Miller @ 2018-10-03 5:35 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, netdev
In-Reply-To: <20180930073636.GA25786@x1c.home>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Sun, 30 Sep 2018 10:36:36 +0300
> Here's the first bluetooth-next pull request for the 4.20 kernel.
>
> - Fixes & cleanups to hci_qca driver
> - NULL dereference fix to debugfs
> - Improved L2CAP Connection-oriented Channel MTU & MPS handling
> - Added support for USB-based RTL8822C controller
> - Added device ID for BCM4335C0 UART-based controller
> - Various other smaller cleanups & fixes
>
> Please let me know if there are any issues pulling. Thanks.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH net] ipv4: fix use-after-free in ip_cmsg_recv_dstaddr()
From: David Miller @ 2018-10-03 5:32 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, willemb
In-Reply-To: <20180930183339.153681-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Sun, 30 Sep 2018 11:33:39 -0700
> Caching ip_hdr(skb) before a call to pskb_may_pull() is buggy,
> do not do it.
>
> Fixes: 2efd4fca703a ("ip: in cmsg IP(V6)_ORIGDSTADDR call pskb_may_pull")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Willem de Bruijn <willemb@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable.
^ permalink raw reply
* [PATCH bpf-next] net: core: Fix build with CONFIG_IPV6=m
From: Joe Stringer @ 2018-10-03 5:32 UTC (permalink / raw)
To: daniel; +Cc: netdev, ast
Stephen Rothwell reports the following link failure with IPv6 as module:
x86_64-linux-gnu-ld: net/core/filter.o: in function `sk_lookup':
(.text+0x19219): undefined reference to `__udp6_lib_lookup'
Fix the build by only enabling the IPv6 socket lookup if IPv6 support is
compiled into the kernel.
Signed-off-by: Joe Stringer <joe@wand.net.nz>
---
net/core/filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index 591c698bc517..30c6b2d3ef16 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -4838,7 +4838,7 @@ struct sock *sk_lookup(struct net *net, struct bpf_sock_tuple *tuple,
sk = __udp4_lib_lookup(net, src4, tuple->ipv4.sport,
dst4, tuple->ipv4.dport,
dif, sdif, &udp_table, skb);
-#if IS_ENABLED(CONFIG_IPV6)
+#if IS_REACHABLE(CONFIG_IPV6)
} else {
struct in6_addr *src6 = (struct in6_addr *)&tuple->ipv6.saddr;
struct in6_addr *dst6 = (struct in6_addr *)&tuple->ipv6.daddr;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next] ipv4: Allow sending multicast packets on specific i/f using VRF socket
From: David Miller @ 2018-10-03 5:31 UTC (permalink / raw)
To: mmanning; +Cc: netdev, rshearma
In-Reply-To: <20181001084023.32310-1-mmanning@vyatta.att-mail.com>
From: Mike Manning <mmanning@vyatta.att-mail.com>
Date: Mon, 1 Oct 2018 09:40:23 +0100
> From: Robert Shearman <rshearma@vyatta.att-mail.com>
>
> It is useful to be able to use the same socket for listening in a
> specific VRF, as for sending multicast packets out of a specific
> interface. However, the bound device on the socket currently takes
> precedence and results in the packets not being sent.
>
> Relax the condition on overriding the output interface to use for
> sending packets out of UDP, raw and ping sockets to allow multicast
> packets to be sent using the specified multicast interface.
>
> Signed-off-by: Robert Shearman <rshearma@vyatta.att-mail.com>
> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: add vrf table handling code for ipv6 mcast
From: David Miller @ 2018-10-03 5:31 UTC (permalink / raw)
To: mmanning; +Cc: netdev, pruddy
In-Reply-To: <20181001084127.32370-1-mmanning@vyatta.att-mail.com>
From: Mike Manning <mmanning@vyatta.att-mail.com>
Date: Mon, 1 Oct 2018 09:41:27 +0100
> From: Patrick Ruddy <pruddy@vyatta.att-mail.com>
>
> The code to obtain the correct table for the incoming interface was
> missing for IPv6. This has been added along with the table creation
> notification to fib rules for the RTNL_FAMILY_IP6MR address family.
>
> Signed-off-by: Patrick Ruddy <pruddy@vyatta.att-mail.com>
> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
Applied.
^ permalink raw reply
* Re: [Patch net-next] net_sched: convert idrinfo->lock from spinlock to a mutex
From: Ido Schimmel @ 2018-10-03 5:31 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, jiri, jhs, vladbu, Jiri Pirko
In-Reply-To: <20181002195019.13522-1-xiyou.wangcong@gmail.com>
On Tue, Oct 02, 2018 at 12:50:19PM -0700, Cong Wang wrote:
> In commit ec3ed293e766 ("net_sched: change tcf_del_walker() to take idrinfo->lock")
> we move fl_hw_destroy_tmplt() to a workqueue to avoid blocking
> with the spinlock held. Unfortunately, this causes a lot of
> troubles here:
>
> 1. tcf_chain_destroy() could be called right after we queue the work
> but before the work runs. This is a use-after-free.
>
> 2. The chain refcnt is already 0, we can't even just hold it again.
> We can check refcnt==1 but it is ugly.
>
> 3. The chain with refcnt 0 is still visible in its block, which means
> it could be still found and used!
>
> 4. The block has a refcnt too, we can't hold it without introducing a
> proper API either.
>
> We can make it working but the end result is ugly. Instead of wasting
> time on reviewing it, let's just convert the troubling spinlock to
> a mutex, which allows us to use non-atomic allocations too.
>
> Fixes: ec3ed293e766 ("net_sched: change tcf_del_walker() to take idrinfo->lock")
> Reported-by: Ido Schimmel <idosch@idosch.org>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: Vlad Buslov <vladbu@mellanox.com>
> Cc: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Tested-by: Ido Schimmel <idosch@mellanox.com>
Thanks a lot!
^ permalink raw reply
* Re: [PATCH net-next] bridge: mcast: Default back to multicast enabled state
From: David Miller @ 2018-10-03 5:27 UTC (permalink / raw)
To: idosch; +Cc: netdev, nikolay, roopa, bridge, mlxsw
In-Reply-To: <20181001085701.23295-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Mon, 1 Oct 2018 11:57:01 +0300
> Commit 13cefad2f2c1 ("net: bridge: convert and rename mcast disabled")
> converted the 'multicast_disabled' field to an option bit named
> 'BROPT_MULTICAST_ENABLED'.
>
> While the old field was implicitly initialized to 0, the new field is
> not initialized, resulting in the bridge defaulting to multicast
> disabled state and breaking existing applications.
>
> Fix this by explicitly initializing the option.
>
> Fixes: 13cefad2f2c1 ("net: bridge: convert and rename mcast disabled")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/4] dpaa2-eth: Add support for Rx flow classification
From: David Miller @ 2018-10-03 5:24 UTC (permalink / raw)
To: ruxandra.radulescu; +Cc: netdev, ioana.ciornei
In-Reply-To: <1538390698-22073-1-git-send-email-ruxandra.radulescu@nxp.com>
From: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Date: Mon, 1 Oct 2018 13:44:54 +0300
> The Management Complex (MC) firmware initially allowed the
> configuration of a single key to be used both for Rx flow hashing
> and flow classification. This prevented us from supporting
> Rx flow classification independently of the hash key configuration.
>
> Newer firmware versions expose separate commands for
> configuring the two types of keys, so we can use them to
> introduce Rx classification support. For frames that don't match
> any classification rule, we fall back to statistical distribution
> based on the current hash key.
>
> The first patch in this set updates the Rx hashing code to use
> the new firmware API for key config. Subsequent patches introduce
> the firmware API for configuring the classification and actual
> support for adding and deleting rules via ethtool.
Series applied, thanks.
^ permalink raw reply
* Re: [pull request][net 0/3] Mellanox, mlx5 fixes 2018-10-01
From: David Miller @ 2018-10-03 5:21 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20181001173750.25772-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Mon, 1 Oct 2018 10:37:47 -0700
> This pull request includes some fixes to mlx5 driver,
> Please pull and let me know if there's any problem.
Pulled.
> For -stable v4.11:
> "6e0a4a23c59a ('net/mlx5: E-Switch, Fix out of bound access when setting vport rate')"
>
> For -stable v4.18:
> "98d6627c372a ('net/mlx5e: Set vlan masks for all offloaded TC rules')"
Queued up.
^ permalink raw reply
* Re: [PATCH net-next] tcp: do not release socket ownership in tcp_close()
From: David Miller @ 2018-10-03 5:18 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20181002062426.140891-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 1 Oct 2018 23:24:26 -0700
> syzkaller was able to hit the WARN_ON(sock_owned_by_user(sk));
> in tcp_close()
>
> While a socket is being closed, it is very possible other
> threads find it in rtnetlink dump.
>
> tcp_get_info() will acquire the socket lock for a short amount
> of time (slow = lock_sock_fast(sk)/unlock_sock_fast(sk, slow);),
> enough to trigger the warning.
>
> Fixes: 67db3e4bfbc9 ("tcp: no longer hold ehash lock while calling tcp_get_info()")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 0/3] net: qualcomm: rmnet: Updates 2018-10-02
From: David Miller @ 2018-10-03 5:17 UTC (permalink / raw)
To: subashab; +Cc: netdev
In-Reply-To: <1538527923-29562-1-git-send-email-subashab@codeaurora.org>
From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date: Tue, 2 Oct 2018 18:52:00 -0600
> This series is a set of small fixes for rmnet driver
>
> Patch 1 is a fix for a scenario reported by syzkaller
> Patch 2 & 3 are fixes for incorrect allocation flags
Series applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v2 08/22] soc/fsl/qbman_portals: add APIs to retrieve the probing status
From: Laurentiu Tudor @ 2018-10-03 10:50 UTC (permalink / raw)
To: Leo Li
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Bharat Bhushan, Madalin-cristian Bucur, Netdev, Roy Pledge, lkml,
Shawn Guo, David Miller,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
robin.murphy@arm.com
In-Reply-To: <CADRPPNTD=SNpSqz=zoLyGP1tvh_xDr5E1NDHF_P0bcSPyx9X1A@mail.gmail.com>
Hi Leo,
On 27.09.2018 23:03, Li Yang wrote:
> On Wed, Sep 26, 2018 at 8:26 AM <laurentiu.tudor@nxp.com> wrote:
>>
>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>
>> Add a couple of new APIs to check the probing status of the required
>> cpu bound qman and bman portals:
>> 'int bman_portals_probed()' and 'int qman_portals_probed()'.
>> They return the following values.
>> * 1 if qman/bman portals were all probed correctly
>> * 0 if qman/bman portals were not yet probed
>> * -1 if probing of qman/bman portals failed
>> Drivers that use qman/bman portal driver services are required to use
>> these APIs before calling any functions exported by these drivers or
>> otherwise they will crash the kernel.
>> First user will be the dpaa1 ethernet driver, coming in a subsequent
>> patch.
>>
>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>> ---
>> drivers/soc/fsl/qbman/bman_portal.c | 10 ++++++++++
>> drivers/soc/fsl/qbman/qman_portal.c | 10 ++++++++++
>> include/soc/fsl/bman.h | 8 ++++++++
>> include/soc/fsl/qman.h | 9 +++++++++
>> 4 files changed, 37 insertions(+)
>>
>> diff --git a/drivers/soc/fsl/qbman/bman_portal.c b/drivers/soc/fsl/qbman/bman_portal.c
>> index f9edd28894fd..8048d35de8a2 100644
>> --- a/drivers/soc/fsl/qbman/bman_portal.c
>> +++ b/drivers/soc/fsl/qbman/bman_portal.c
>> @@ -32,6 +32,7 @@
>>
>> static struct bman_portal *affine_bportals[NR_CPUS];
>> static struct cpumask portal_cpus;
>> +static int __bman_portals_probed;
>> /* protect bman global registers and global data shared among portals */
>> static DEFINE_SPINLOCK(bman_lock);
>>
>> @@ -85,6 +86,12 @@ static int bman_online_cpu(unsigned int cpu)
>> return 0;
>> }
>>
>> +int bman_portals_probed(void)
>> +{
>> + return __bman_portals_probed;
>> +}
>> +EXPORT_SYMBOL_GPL(bman_portals_probed);
>> +
>> static int bman_portal_probe(struct platform_device *pdev)
>> {
>> struct device *dev = &pdev->dev;
>> @@ -148,6 +155,7 @@ static int bman_portal_probe(struct platform_device *pdev)
>> spin_lock(&bman_lock);
>> cpu = cpumask_next_zero(-1, &portal_cpus);
>> if (cpu >= nr_cpu_ids) {
>> + __bman_portals_probed = 1;
>
> What if the last CPU is not used for portals? Is there a hard
> requirement that all CPUs need to be used for portal?
As far as I know, in the current driver design a portal is required for
each CPU.
> What happens if the last CPU is offline?
Can this happen at probe time?
Anyway, I'm not sure that the driver is even aware of cpu hotplug but
I'll let Roy comment on this one.
>
>> /* unassigned portal, skip init */
>> spin_unlock(&bman_lock);
>> return 0;
>> @@ -173,6 +181,8 @@ static int bman_portal_probe(struct platform_device *pdev)
>> err_ioremap2:
>> memunmap(pcfg->addr_virt_ce);
>> err_ioremap1:
>> + __bman_portals_probed = 1;
>> +
>
> There are other error paths that not covered.
Right, thanks for pointing. On top of that, the assigned value here
should be -1 to signal error (instead of 1 which signals success).
---
Best Regards, Laurentiu
^ permalink raw reply
* [PATCH] sctp: fix fall-through annotation
From: Gustavo A. R. Silva @ 2018-10-03 10:45 UTC (permalink / raw)
To: Vlad Yasevich, Neil Horman, Marcelo Ricardo Leitner,
David S. Miller
Cc: linux-sctp, netdev, linux-kernel, Gustavo A. R. Silva
Replace "fallthru" with a proper "fall through" annotation.
This fix is part of the ongoing efforts to enabling
-Wimplicit-fallthrough
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
net/sctp/outqueue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index d74d00b..42191ed 100644
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -1048,7 +1048,7 @@ static void sctp_outq_flush_data(struct sctp_flush_ctx *ctx,
if (!ctx->packet || !ctx->packet->has_cookie_echo)
return;
- /* fallthru */
+ /* fall through */
case SCTP_STATE_ESTABLISHED:
case SCTP_STATE_SHUTDOWN_PENDING:
case SCTP_STATE_SHUTDOWN_RECEIVED:
--
2.7.4
^ permalink raw reply related
* Re: [RESEND] [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi
From: Kalle Valo @ 2018-10-03 9:57 UTC (permalink / raw)
To: Grumbach, Emmanuel
Cc: Kai Heng Feng, LKML, Berg, Johannes, Coelho, Luciano, linuxwifi,
David S. Miller, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-bluetooth
In-Reply-To: <0BA3FCBA62E2DC44AF3030971E174FB301336D868D@HASMSX111.ger.corp.intel.com>
+ linux-bluetooth
"Grumbach, Emmanuel" <emmanuel.grumbach@intel.com> writes:
>>
>> > On Oct 3, 2018, at 5:10 PM, Kalle Valo <kvalo@codeaurora.org> wrote:
>> >
>> > Kai-Heng Feng <kai.heng.feng@canonical.com> writes:
>> >
>> >> To avoid the firmware loading race between Bluetooth and WiFi on
>> >> Intel 8260, load firmware exclusively when BT_INTEL is enabled.
>> >>
>> >> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>> >
>> > Still the commit log tells nothing about the actual problem which
>> > makes review impossible.
>>
>> Sorry for that. The first two patches [1] only sends to linux-bluetooth and
>> LMKL.
>>
>> I don’t know what really happened at hardware/firmware level, but making
>> btusb and iwlwifi load firmware sequentially can workaround the issue.
>>
>> Matt Chen may be able to explain this issue with more detail.
>>
>> [1] https://lkml.org/lkml/2018/10/3/322
>>
>
> I just read the code of this patch and I don't quite understand.
> You have a function that is declared as a non-inline function in two different header files?
> btintel_firmware_lock is declared here:
>
> --- /dev/null
> +++ b/include/linux/intel-wifi-bt.h
> @@ -0,0 +1,8 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __INTEL_WIFI_BT_H__
> +#define __INTEL_WIFI_BT_H__
> +
> +void btintel_firmware_lock(void);
>
> And ...
>
> diff --git a/drivers/bluetooth/btintel.h b/drivers/bluetooth/btintel.h
> index 41c642cc523f..1373ffc2b575 100644
> --- a/drivers/bluetooth/btintel.h
> +++ b/drivers/bluetooth/btintel.h
> @@ -102,6 +102,8 @@ int btintel_read_boot_params(struct hci_dev *hdev,
> struct intel_boot_params *params);
> int btintel_download_firmware(struct hci_dev *dev, const struct firmware *fw,
> u32 *boot_param);
> +void btintel_firmware_lock(void);
>
>
> This can't be right.
--
Kalle Valo
^ permalink raw reply
* RE: [RESEND] [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi
From: Grumbach, Emmanuel @ 2018-10-03 9:50 UTC (permalink / raw)
To: Kai Heng Feng, Kalle Valo
Cc: LKML, Berg, Johannes, Coelho, Luciano, linuxwifi, David S. Miller,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <265BAF93-4BFF-4850-92F7-80AC39496473@canonical.com>
>
> > On Oct 3, 2018, at 5:10 PM, Kalle Valo <kvalo@codeaurora.org> wrote:
> >
> > Kai-Heng Feng <kai.heng.feng@canonical.com> writes:
> >
> >> To avoid the firmware loading race between Bluetooth and WiFi on
> >> Intel 8260, load firmware exclusively when BT_INTEL is enabled.
> >>
> >> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> >
> > Still the commit log tells nothing about the actual problem which
> > makes review impossible.
>
> Sorry for that. The first two patches [1] only sends to linux-bluetooth and
> LMKL.
>
> I don’t know what really happened at hardware/firmware level, but making
> btusb and iwlwifi load firmware sequentially can workaround the issue.
>
> Matt Chen may be able to explain this issue with more detail.
>
> [1] https://lkml.org/lkml/2018/10/3/322
>
I just read the code of this patch and I don't quite understand.
You have a function that is declared as a non-inline function in two different header files?
btintel_firmware_lock is declared here:
--- /dev/null
+++ b/include/linux/intel-wifi-bt.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __INTEL_WIFI_BT_H__
+#define __INTEL_WIFI_BT_H__
+
+void btintel_firmware_lock(void);
And ...
diff --git a/drivers/bluetooth/btintel.h b/drivers/bluetooth/btintel.h
index 41c642cc523f..1373ffc2b575 100644
--- a/drivers/bluetooth/btintel.h
+++ b/drivers/bluetooth/btintel.h
@@ -102,6 +102,8 @@ int btintel_read_boot_params(struct hci_dev *hdev,
struct intel_boot_params *params);
int btintel_download_firmware(struct hci_dev *dev, const struct firmware *fw,
u32 *boot_param);
+void btintel_firmware_lock(void);
This can't be right.
^ permalink raw reply related
* Re: [RESEND] [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi
From: Kalle Valo @ 2018-10-03 9:47 UTC (permalink / raw)
To: Kai Heng Feng
Cc: LKML, Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, David S. Miller, linux-wireless, netdev,
linux-bluetooth
In-Reply-To: <87tvm3id0f.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Kai Heng Feng <kai.heng.feng@canonical.com> writes:
>
>>> On Oct 3, 2018, at 5:10 PM, Kalle Valo <kvalo@codeaurora.org> wrote:
>>>
>>> Kai-Heng Feng <kai.heng.feng@canonical.com> writes:
>>>
>>>> To avoid the firmware loading race between Bluetooth and WiFi on Intel
>>>> 8260, load firmware exclusively when BT_INTEL is enabled.
>>>>
>>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>>>
>>> Still the commit log tells nothing about the actual problem which makes
>>> review impossible.
>>
>> Sorry for that. The first two patches [1] only sends to linux-bluetooth and LMKL.
>
> For a patchset like this you should CC linux-wireless for all patches,
> otherwise people just get confused. And even more so as patch 3 seems to
> depend on the other patches.
>
>> I don’t know what really happened at hardware/firmware level, but
>> making btusb and iwlwifi load firmware sequentially can workaround the
>> issue.
>
> We don't apply ugly workarounds without understanding the issue.
>
>> Matt Chen may be able to explain this issue with more detail.
>
> Then you need to work with Matt so that the issue is properly explained
> in the commit log.
linux-bluetooth was not CCed, adding that.
--
Kalle Valo
^ permalink raw reply
* Re: [RESEND] [PATCH 3/3] iwlwifi: Load firmware exclusively for Intel WiFi
From: Kalle Valo @ 2018-10-03 9:40 UTC (permalink / raw)
To: Kai Heng Feng
Cc: LKML, Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, David S. Miller, linux-wireless, netdev
In-Reply-To: <265BAF93-4BFF-4850-92F7-80AC39496473@canonical.com>
Kai Heng Feng <kai.heng.feng@canonical.com> writes:
>> On Oct 3, 2018, at 5:10 PM, Kalle Valo <kvalo@codeaurora.org> wrote:
>>
>> Kai-Heng Feng <kai.heng.feng@canonical.com> writes:
>>
>>> To avoid the firmware loading race between Bluetooth and WiFi on Intel
>>> 8260, load firmware exclusively when BT_INTEL is enabled.
>>>
>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>>
>> Still the commit log tells nothing about the actual problem which makes
>> review impossible.
>
> Sorry for that. The first two patches [1] only sends to linux-bluetooth and LMKL.
For a patchset like this you should CC linux-wireless for all patches,
otherwise people just get confused. And even more so as patch 3 seems to
depend on the other patches.
> I don’t know what really happened at hardware/firmware level, but
> making btusb and iwlwifi load firmware sequentially can workaround the
> issue.
We don't apply ugly workarounds without understanding the issue.
> Matt Chen may be able to explain this issue with more detail.
Then you need to work with Matt so that the issue is properly explained
in the commit log.
--
Kalle Valo
^ 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