* Re: [Xen-devel] [PATCH] xen-netfront: wait xenbus state change when load module manually
From: Juergen Gross @ 2018-08-24 11:26 UTC (permalink / raw)
To: Jiri Slaby, Xiao Liang, David Miller
Cc: netdev, boris.ostrovsky, linux-kernel, xen-devel
In-Reply-To: <83ad1e3c-5e3b-8b24-430b-13e12b59ae8b@suse.cz>
On 24/08/18 13:12, Jiri Slaby wrote:
> On 07/30/2018, 10:18 AM, Xiao Liang wrote:
>> On 07/29/2018 11:30 PM, David Miller wrote:
>>> From: Xiao Liang <xiliang@redhat.com>
>>> Date: Fri, 27 Jul 2018 17:56:08 +0800
>>>
>>>> @@ -1330,6 +1331,11 @@ static struct net_device
>>>> *xennet_create_dev(struct xenbus_device *dev)
>>>> netif_carrier_off(netdev);
>>>> xenbus_switch_state(dev, XenbusStateInitialising);
>>>> + wait_event(module_load_q,
>>>> + xenbus_read_driver_state(dev->otherend) !=
>>>> + XenbusStateClosed &&
>>>> + xenbus_read_driver_state(dev->otherend) !=
>>>> + XenbusStateUnknown);
>>>> return netdev;
>>>> exit:
>>> What performs the wakeups that will trigger for this sleep site?
>> In my understanding, backend leaving closed/unknow state can trigger the
>> wakeups. I mean to make sure both sides are ready for creating connection.
>
> While backporting this to 4.12, I was surprised by the commit the same
> as Boris and David.
>
> So I assume the explanation is that wake_up_all of module_unload_q in
> netback_changed wakes also all the processes waiting on module_load_q?
> If so, what makes sure that module_unload_q is queued and the process is
> the same as for module_load_q?
How could it? Either the thread is waiting on module_unload_q _or_ on
module_load_q. It can't wait on two queues at the same time.
> To me, it looks rather error-prone. Unless it is erroneous now, at least
> for future changes. Wouldn't it make sense to wake up module_load_q
> along with module_unload_q in netback_changed? Or drop module_load_q
> completely and use only module_unload_q (i.e. in xennet_create_dev too)?
To me this looks just wrong. A thread waiting on module_load_q won't be
woken up again.
I'd drop module_load_q in favor of module_unload_q.
Juergen
^ permalink raw reply
* [PATCH] qed: fix spelling mistake "comparsion" -> "comparison"
From: Colin King @ 2018-08-24 11:18 UTC (permalink / raw)
To: Ariel Elior, everest-linux-l2, David S . Miller, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in DP_ERR error message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/qlogic/qed/qed_init_ops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_init_ops.c b/drivers/net/ethernet/qlogic/qed/qed_init_ops.c
index d9ab5add27a8..34193c2f1699 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_init_ops.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_init_ops.c
@@ -407,7 +407,7 @@ static void qed_init_cmd_rd(struct qed_hwfn *p_hwfn,
if (i == QED_INIT_MAX_POLL_COUNT) {
DP_ERR(p_hwfn,
- "Timeout when polling reg: 0x%08x [ Waiting-for: %08x Got: %08x (comparsion %08x)]\n",
+ "Timeout when polling reg: 0x%08x [ Waiting-for: %08x Got: %08x (comparison %08x)]\n",
addr, le32_to_cpu(cmd->expected_val),
val, le32_to_cpu(cmd->op_data));
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net] vhost: correctly check the iova range when waking virtqueue
From: Michael S. Tsirkin @ 2018-08-24 11:02 UTC (permalink / raw)
To: Jason Wang; +Cc: kvm, virtualization, netdev, linux-kernel, peterx
In-Reply-To: <20180824085313.21798-1-jasowang@redhat.com>
On Fri, Aug 24, 2018 at 04:53:13PM +0800, Jason Wang wrote:
> We don't wakeup the virtqueue if the first byte of pending iova range
> is the last byte of the range we just got updated. This will lead a
> virtqueue to wait for IOTLB updating forever. Fixing by correct the
> check and wake up the virtqueue in this case.
>
> Fixes: 6b1e6cc7855b ("vhost: new device IOTLB API")
> Reported-by: Peter Xu <peterx@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> The patch is needed for -stable.
> ---
> drivers/vhost/vhost.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 96c1d8400822..b13c6b4b2c66 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -952,7 +952,7 @@ static void vhost_iotlb_notify_vq(struct vhost_dev *d,
> list_for_each_entry_safe(node, n, &d->pending_list, node) {
> struct vhost_iotlb_msg *vq_msg = &node->msg.iotlb;
> if (msg->iova <= vq_msg->iova &&
> - msg->iova + msg->size - 1 > vq_msg->iova &&
> + msg->iova + msg->size - 1 >= vq_msg->iova &&
> vq_msg->type == VHOST_IOTLB_MISS) {
> vhost_poll_queue(&node->vq->poll);
> list_del(&node->node);
> --
> 2.17.1
^ permalink raw reply
* Re: [PATCH net] vhost: correctly check the iova range when waking virtqueue
From: Peter Xu @ 2018-08-24 9:36 UTC (permalink / raw)
To: Jason Wang; +Cc: mst, kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20180824085313.21798-1-jasowang@redhat.com>
On Fri, Aug 24, 2018 at 04:53:13PM +0800, Jason Wang wrote:
> We don't wakeup the virtqueue if the first byte of pending iova range
> is the last byte of the range we just got updated. This will lead a
> virtqueue to wait for IOTLB updating forever. Fixing by correct the
> check and wake up the virtqueue in this case.
>
> Fixes: 6b1e6cc7855b ("vhost: new device IOTLB API")
> Reported-by: Peter Xu <peterx@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Without this patch, this command will trigger the IO hang merely every
time from host to guest:
netperf -H 1.2.3.4 -l 5 -t TCP_RR -- -b 100
After applying, I can run it 10 times continuously without a problem.
Reviewed-by: Peter Xu <peterx@redhat.com>
Tested-by: Peter Xu <peterx@redhat.com>
Thanks,
--
Peter Xu
^ permalink raw reply
* Re: [PATCH v2 2/2] can: rcar: use SPDX identifier for Renesas drivers
From: Simon Horman @ 2018-08-24 9:18 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-renesas-soc, Kuninori Morimoto, Wolfgang Grandegger,
Marc Kleine-Budde, David S. Miller, linux-can, netdev,
linux-kernel
In-Reply-To: <20180823133456.4748-3-wsa+renesas@sang-engineering.com>
On Thu, Aug 23, 2018 at 03:34:55PM +0200, Wolfram Sang wrote:
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: can: rcar_can: Add r8a774a1 support
From: Simon Horman @ 2018-08-24 9:17 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Rob Herring, Mark Rutland,
Sergei Shtylyov, David S. Miller, linux-can, netdev, devicetree,
Geert Uytterhoeven, Chris Paterson, Biju Das, linux-renesas-soc,
linux-kernel
In-Reply-To: <1535029653-7418-4-git-send-email-fabrizio.castro@bp.renesas.com>
On Thu, Aug 23, 2018 at 02:07:33PM +0100, Fabrizio Castro wrote:
> Document RZ/G2M (r8a774a1) SoC specific bindings and RZ/G2
> generic bindings.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Are we sure these clocks are for all RZ/G2 SoCs?
If so:
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>
> This patch applies on next-20180823
>
> Documentation/devicetree/bindings/net/can/rcar_can.txt | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> index 94a7f33..ae8fccc 100644
> --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt
> +++ b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> @@ -4,6 +4,7 @@ Renesas R-Car CAN controller Device Tree Bindings
> Required properties:
> - compatible: "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC.
> "renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC.
> + "renesas,can-r8a774a1" if CAN controller is a part of R8A774A1 SoC.
> "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC.
> "renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC.
> "renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC.
> @@ -17,6 +18,7 @@ Required properties:
> "renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1
> compatible device.
> "renesas,rcar-gen3-can" for a generic R-Car Gen3 compatible device.
> + "renesas,rzg-gen2-can" for a generic RZ/G2 compatible device.
> When compatible with the generic version, nodes must list the
> SoC-specific version corresponding to the platform first
> followed by the generic version.
> @@ -24,7 +26,9 @@ Required properties:
> - reg: physical base address and size of the R-Car CAN register map.
> - interrupts: interrupt specifier for the sole interrupt.
> - clocks: phandles and clock specifiers for 3 CAN clock inputs.
> -- clock-names: 3 clock input name strings: "clkp1", "clkp2", "can_clk".
> +- clock-names: 2 clock input name strings for RZ/G2: "clkp1", "can_clk".
> + 3 clock input name strings for every other SoC: "clkp1", "clkp2",
> + "can_clk".
> - pinctrl-0: pin control group to be used for this controller.
> - pinctrl-names: must be "default".
>
> @@ -41,8 +45,9 @@ using the below properties:
> Optional properties:
> - renesas,can-clock-select: R-Car CAN Clock Source Select. Valid values are:
> <0x0> (default) : Peripheral clock (clkp1)
> - <0x1> : Peripheral clock (clkp2)
> - <0x3> : Externally input clock
> + <0x1> : Peripheral clock (clkp2) (not supported by
> + RZ/G2 devices)
> + <0x3> : External input clock
>
> Example
> -------
> --
> 2.7.4
>
^ permalink raw reply
* Re: pull-request: bpf 2018-08-24
From: David Miller @ 2018-08-24 5:42 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <20180823230929.28677-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri, 24 Aug 2018 01:09:29 +0200
> The following pull-request contains BPF updates for your *net* tree.
Pulled, thanks Daniel.
^ permalink raw reply
* [PATCH] Revert "net: stmmac: Do not keep rearming the coalesce timer in stmmac_xmit"
From: Jerome Brunet @ 2018-08-24 9:04 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu, netdev
Cc: Jerome Brunet, linux-kernel, linux-amlogic, Joao Pinto,
Vitor Soares, Corentin Labbe
This reverts commit 4ae0169fd1b3c792b66be58995b7e6b629919ecf.
This change in the handling of the coalesce timer is causing regression on
(at least) amlogic platforms.
Network will break down very quickly (a few seconds) after starting
a download. This can easily be reproduced using iperf3 for example.
The problem has been reported on the S805, S905, S912 and A113 SoCs
(Realtek and Micrel PHYs) and it is likely impacting all Amlogics
platforms using Gbit ethernet
No problem was seen with the platform using 10/100 only PHYs (GXL internal)
Reverting change brings things back to normal and allows to use network
again until we better understand the problem with the coalesce timer.
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Vitor Soares <soares@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 -
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 5 +----
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 76649adf8fb0..c0a855b7ab3b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -112,7 +112,6 @@ struct stmmac_priv {
u32 tx_count_frames;
u32 tx_coal_frames;
u32 tx_coal_timer;
- bool tx_timer_armed;
int tx_coalesce;
int hwts_tx_en;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index ff1ffb46198a..9f458bb16f2a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3147,16 +3147,13 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
* element in case of no SG.
*/
priv->tx_count_frames += nfrags + 1;
- if (likely(priv->tx_coal_frames > priv->tx_count_frames) &&
- !priv->tx_timer_armed) {
+ if (likely(priv->tx_coal_frames > priv->tx_count_frames)) {
mod_timer(&priv->txtimer,
STMMAC_COAL_TIMER(priv->tx_coal_timer));
- priv->tx_timer_armed = true;
} else {
priv->tx_count_frames = 0;
stmmac_set_tx_ic(priv, desc);
priv->xstats.tx_set_ic_bit++;
- priv->tx_timer_armed = false;
}
skb_tx_timestamp(skb);
--
2.17.1
^ permalink raw reply related
* [PATCH net] vhost: correctly check the iova range when waking virtqueue
From: Jason Wang @ 2018-08-24 8:53 UTC (permalink / raw)
To: mst, jasowang; +Cc: kvm, virtualization, netdev, linux-kernel, peterx
We don't wakeup the virtqueue if the first byte of pending iova range
is the last byte of the range we just got updated. This will lead a
virtqueue to wait for IOTLB updating forever. Fixing by correct the
check and wake up the virtqueue in this case.
Fixes: 6b1e6cc7855b ("vhost: new device IOTLB API")
Reported-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
The patch is needed for -stable.
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 96c1d8400822..b13c6b4b2c66 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -952,7 +952,7 @@ static void vhost_iotlb_notify_vq(struct vhost_dev *d,
list_for_each_entry_safe(node, n, &d->pending_list, node) {
struct vhost_iotlb_msg *vq_msg = &node->msg.iotlb;
if (msg->iova <= vq_msg->iova &&
- msg->iova + msg->size - 1 > vq_msg->iova &&
+ msg->iova + msg->size - 1 >= vq_msg->iova &&
vq_msg->type == VHOST_IOTLB_MISS) {
vhost_poll_queue(&node->vq->poll);
list_del(&node->node);
--
2.17.1
^ permalink raw reply related
* RE: [PATCH] dt-bindings: can: rcar_can: Add r8a774a1 support
From: Fabrizio Castro @ 2018-08-24 8:31 UTC (permalink / raw)
To: Simon Horman, Chris Paterson
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Rob Herring, Mark Rutland,
David S. Miller, linux-can@vger.kernel.org,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
Geert Uytterhoeven, Biju Das, linux-renesas-soc@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20180824082643.7eapxf72iuvkdw3j@verge.net.au>
Hello Simon,
Thank you for the feedback!
> >
> > In theory CAN could be broken if renesas,can-clock-select is set to 0x1
> > (clkp2) in the DT, as this value will be written to the CAN Clock Select
> > Register. However if the documentation is followed there will be no
> > problems.
> >
> > We should probably update the driver to fix this though, which will be a
> > change specific to all RZ/G2 devices, so perhaps we should also be adding
> > a "renesas,rzg-gen2-can" family compatible string as well? (to driver and
> > documentation)
>
> Yes, I think that sounds reasonable.
>
> But in that case we should pre-emptively not use renesas,rcar-gen3-can for
> RZ/G2.
What do you think about the following:
https://patchwork.kernel.org/patch/10573795/
https://patchwork.kernel.org/patch/10573791/
https://patchwork.kernel.org/patch/10573805/
Thanks,
Fab
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* Re: [PATCH] mt76: Fix comparisons with invalid hardware key index
From: Kalle Valo @ 2018-08-24 8:20 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Geert Uytterhoeven, David S . Miller, Matthias Brugger,
Lorenzo Bianconi, Arnd Bergmann, linux-wireless, netdev,
linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20180824080817.GA6651@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> writes:
> On Thu, Aug 23, 2018 at 11:27:38PM +0200, Geert Uytterhoeven wrote:
>> With gcc 4.1.2:
>>
>> drivers/net/wireless/mediatek/mt76/mt76x0/tx.c: In function ‘mt76x0_tx’:
>> drivers/net/wireless/mediatek/mt76/mt76x0/tx.c:169: warning:
>> comparison is always true due to limited range of data type
>> drivers/net/wireless/mediatek/mt76/mt76x2_tx_common.c: In function ‘mt76x2_tx’:
>> drivers/net/wireless/mediatek/mt76/mt76x2_tx_common.c:35:
>> warning: comparison is always true due to limited range of data type
>>
>> While assigning -1 to a u8 works fine, comparing with -1 does not work
>> as expected.
>>
>> Fix this by comparing with 0xff, like is already done in some other
>> places.
>>
>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> Ack for mt76x0. I think Lorenzo already posted patch for mt76x2.
Yeah, Lorenzo's patch is here:
https://patchwork.kernel.org/patch/10570555/
As Geert's patch seems to be more complete I'm planning to take Geert's
version.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] mt76: Fix comparisons with invalid hardware key index
From: Stanislaw Gruszka @ 2018-08-24 8:08 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Kalle Valo, David S . Miller, Matthias Brugger, Lorenzo Bianconi,
Arnd Bergmann, linux-wireless, netdev, linux-arm-kernel,
linux-mediatek, linux-kernel
In-Reply-To: <20180823212738.18431-1-geert@linux-m68k.org>
On Thu, Aug 23, 2018 at 11:27:38PM +0200, Geert Uytterhoeven wrote:
> With gcc 4.1.2:
>
> drivers/net/wireless/mediatek/mt76/mt76x0/tx.c: In function ‘mt76x0_tx’:
> drivers/net/wireless/mediatek/mt76/mt76x0/tx.c:169: warning: comparison is always true due to limited range of data type
> drivers/net/wireless/mediatek/mt76/mt76x2_tx_common.c: In function ‘mt76x2_tx’:
> drivers/net/wireless/mediatek/mt76/mt76x2_tx_common.c:35: warning: comparison is always true due to limited range of data type
>
> While assigning -1 to a u8 works fine, comparing with -1 does not work
> as expected.
>
> Fix this by comparing with 0xff, like is already done in some other
> places.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Ack for mt76x0. I think Lorenzo already posted patch for mt76x2.
Thanks
Stanislaw
^ permalink raw reply
* KASAN: use-after-free Read in sctp_transport_get_next
From: syzbot @ 2018-08-24 7:40 UTC (permalink / raw)
To: davem, linux-kernel, linux-sctp, marcelo.leitner, netdev, nhorman,
syzkaller-bugs, vyasevich
Hello,
syzbot found the following crash on:
HEAD commit: 815f0ddb346c include/linux/compiler*.h: make compiler-*.h ..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14adfea6400000
kernel config: https://syzkaller.appspot.com/x/.config?x=e408e8a7bf8306cb
dashboard link: https://syzkaller.appspot.com/bug?extid=fe62a0c9aa6a85c6de16
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
userspace arch: i386
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=130da896400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+fe62a0c9aa6a85c6de16@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in sctp_transport_get_next+0x11c/0x140
net/sctp/socket.c:5008
Read of size 8 at addr ffff8801d97c84e0 by task syz-executor0/12694
CPU: 1 PID: 12694 Comm: syz-executor0 Not tainted 4.18.0+ #107
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+0x1c9/0x2b4 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x30d mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
sctp_transport_get_next+0x11c/0x140 net/sctp/socket.c:5008
sctp_transport_get_idx net/sctp/socket.c:5022 [inline]
sctp_for_each_transport+0x152/0x370 net/sctp/socket.c:5083
sctp_diag_dump+0x3a7/0x620 net/sctp/diag.c:527
__inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049
inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065
netlink_dump+0x519/0xd50 net/netlink/af_netlink.c:2233
__netlink_dump_start+0x4f1/0x6f0 net/netlink/af_netlink.c:2329
netlink_dump_start include/linux/netlink.h:213 [inline]
inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170
__sock_diag_cmd net/core/sock_diag.c:232 [inline]
sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454
sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:631
sock_write_iter+0x362/0x5c0 net/socket.c:900
call_write_iter include/linux/fs.h:1805 [inline]
do_iter_readv_writev+0x8b0/0xa80 fs/read_write.c:680
do_iter_write+0x185/0x5f0 fs/read_write.c:959
compat_writev+0x234/0x420 fs/read_write.c:1273
do_compat_writev+0x128/0x260 fs/read_write.c:1294
__do_compat_sys_writev fs/read_write.c:1305 [inline]
__se_compat_sys_writev fs/read_write.c:1301 [inline]
__ia32_compat_sys_writev+0x74/0xb0 fs/read_write.c:1301
do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7f6aca9
Code: 55 08 8b 88 64 cd ff ff 8b 98 68 cd ff ff 89 c8 85 d2 74 02 89 0a 5b
5d c3 8b 04 24 c3 8b 1c 24 c3 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90
90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:00000000f7f660cc EFLAGS: 00000296 ORIG_RAX: 0000000000000092
RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 0000000020000000
RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Allocated by task 12694:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kmem_cache_alloc_trace+0x152/0x730 mm/slab.c:3620
kmalloc include/linux/slab.h:513 [inline]
kzalloc include/linux/slab.h:707 [inline]
sctp_association_new+0x127/0x2290 net/sctp/associola.c:311
sctp_unpack_cookie+0x7b4/0x1160 net/sctp/sm_make_chunk.c:1829
sctp_sf_do_5_1D_ce+0x451/0x14c0 net/sctp/sm_statefuns.c:743
sctp_do_sm+0x1c1/0x71e0 net/sctp/sm_sideeffect.c:1188
sctp_endpoint_bh_rcv+0x465/0x960 net/sctp/endpointola.c:456
sctp_inq_push+0x272/0x340 net/sctp/inqueue.c:95
sctp_rcv+0x2cb2/0x3ab0 net/sctp/input.c:268
sctp6_rcv+0x15/0x30 net/sctp/ipv6.c:1061
ip6_input_finish+0x407/0x1a40 net/ipv6/ip6_input.c:383
NF_HOOK include/linux/netfilter.h:287 [inline]
ip6_input+0xe9/0x600 net/ipv6/ip6_input.c:426
dst_input include/net/dst.h:450 [inline]
ip6_rcv_finish+0x17a/0x330 net/ipv6/ip6_input.c:76
NF_HOOK include/linux/netfilter.h:287 [inline]
ipv6_rcv+0x11e/0x650 net/ipv6/ip6_input.c:271
__netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4892
__netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002
process_backlog+0x219/0x760 net/core/dev.c:5808
napi_poll net/core/dev.c:6228 [inline]
net_rx_action+0x799/0x1900 net/core/dev.c:6294
__do_softirq+0x2eb/0xa74 kernel/softirq.c:292
Freed by task 12693:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xd9/0x210 mm/slab.c:3813
sctp_association_destroy net/sctp/associola.c:437 [inline]
sctp_association_put+0x264/0x350 net/sctp/associola.c:885
sctp_association_free+0x6c9/0x972 net/sctp/associola.c:415
sctp_cmd_delete_tcb net/sctp/sm_sideeffect.c:939 [inline]
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1353 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x4a5c/0x71e0 net/sctp/sm_sideeffect.c:1191
sctp_primitive_ABORT+0xa0/0xd0 net/sctp/primitive.c:119
sctp_close+0x279/0xa80 net/sctp/socket.c:1559
inet_release+0x104/0x1f0 net/ipv4/af_inet.c:428
inet6_release+0x50/0x70 net/ipv6/af_inet6.c:457
__sock_release+0xd7/0x250 net/socket.c:579
sock_close+0x19/0x20 net/socket.c:1139
__fput+0x36e/0x8c0 fs/file_table.c:278
____fput+0x15/0x20 fs/file_table.c:309
task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:193 [inline]
exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_32_irqs_on arch/x86/entry/common.c:341 [inline]
do_fast_syscall_32+0xcd5/0xfb2 arch/x86/entry/common.c:397
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
The buggy address belongs to the object at ffff8801d97c84c0
which belongs to the cache kmalloc-4096 of size 4096
The buggy address is located 32 bytes inside of
4096-byte region [ffff8801d97c84c0, ffff8801d97c94c0)
The buggy address belongs to the page:
page:ffffea000765f200 count:1 mapcount:0 mapping:ffff8801dac00dc0 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea0007628888 ffffea0007620608 ffff8801dac00dc0
raw: 0000000000000000 ffff8801d97c84c0 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801d97c8380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801d97c8400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801d97c8480: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
^
ffff8801d97c8500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801d97c8580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
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 NET 3/3] net: hns: add configuration constraints for 1000M half
From: lipeng (Y) @ 2018-08-24 6:39 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem, netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta
In-Reply-To: <20180824034119.GA29111@lunn.ch>
On 2018/8/24 11:41, Andrew Lunn wrote:
> On Fri, Aug 24, 2018 at 11:42:23AM +0800, Peng Li wrote:
>> Hisilicon hip05 and hip06 board network card do not support
>> 1000M half configuration. Driver can not config gmac as
>> 1000M half.
>>
>> Signed-off-by: Peng Li <lipeng321@huawei.com>
> Hi Peng
>
> Does the driver remove SUPPORTED_1000baseT_Half from
> phydev->supported? If you do that, the PHY should never negotiate
> this speed.
>
> Andrew
Hi, Andrew,
The driver has removed SUPPORTED_1000baseT_Half from
phydev->supported.
the code is :
#define MAC_GMAC_SUPPORTED \
(SUPPORTED_10baseT_Half \
| SUPPORTED_10baseT_Full \
| SUPPORTED_100baseT_Half \
| SUPPORTED_100baseT_Full \
| SUPPORTED_Autoneg)
h->if_support = MAC_GMAC_SUPPORTED;
h->if_support |= SUPPORTED_1000baseT_Full;
phydev->supported &= h->if_support;
As gmac do not support 1000M half, we add this patch to
make sure that no users can set 1000M half in any case.
Thanks
>
> .
>
^ permalink raw reply
* Re: [PATCH] ath10k: use struct_size() in kzalloc()
From: Kees Cook @ 2018-08-24 2:59 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Kalle Valo, David S. Miller, ath10k, linux-wireless,
Network Development, LKML
In-Reply-To: <20180824011247.GA25648@embeddedor.com>
On Thu, Aug 23, 2018 at 6:12 PM, Gustavo A. R. Silva
<gustavo@embeddedor.com> wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entry[];
> };
>
> instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This issue was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
> drivers/net/wireless/ath/ath10k/ce.c | 24 ++++++++----------------
> 1 file changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
> index 18c709c..d0381aa 100644
> --- a/drivers/net/wireless/ath/ath10k/ce.c
> +++ b/drivers/net/wireless/ath/ath10k/ce.c
> @@ -1416,10 +1416,8 @@ ath10k_ce_alloc_src_ring(struct ath10k *ar, unsigned int ce_id,
>
> nentries = roundup_pow_of_two(nentries);
>
> - src_ring = kzalloc(sizeof(*src_ring) +
> - (nentries *
> - sizeof(*src_ring->per_transfer_context)),
> - GFP_KERNEL);
> + src_ring = kzalloc(struct_size(src_ring, per_transfer_context,
> + nentries), GFP_KERNEL);
> if (src_ring == NULL)
> return ERR_PTR(-ENOMEM);
>
> @@ -1476,10 +1474,8 @@ ath10k_ce_alloc_src_ring_64(struct ath10k *ar, unsigned int ce_id,
>
> nentries = roundup_pow_of_two(nentries);
>
> - src_ring = kzalloc(sizeof(*src_ring) +
> - (nentries *
> - sizeof(*src_ring->per_transfer_context)),
> - GFP_KERNEL);
> + src_ring = kzalloc(struct_size(src_ring, per_transfer_context,
> + nentries), GFP_KERNEL);
> if (!src_ring)
> return ERR_PTR(-ENOMEM);
>
> @@ -1534,10 +1530,8 @@ ath10k_ce_alloc_dest_ring(struct ath10k *ar, unsigned int ce_id,
>
> nentries = roundup_pow_of_two(attr->dest_nentries);
>
> - dest_ring = kzalloc(sizeof(*dest_ring) +
> - (nentries *
> - sizeof(*dest_ring->per_transfer_context)),
> - GFP_KERNEL);
> + dest_ring = kzalloc(struct_size(dest_ring, per_transfer_context,
> + nentries), GFP_KERNEL);
> if (dest_ring == NULL)
> return ERR_PTR(-ENOMEM);
>
> @@ -1580,10 +1574,8 @@ ath10k_ce_alloc_dest_ring_64(struct ath10k *ar, unsigned int ce_id,
>
> nentries = roundup_pow_of_two(attr->dest_nentries);
>
> - dest_ring = kzalloc(sizeof(*dest_ring) +
> - (nentries *
> - sizeof(*dest_ring->per_transfer_context)),
> - GFP_KERNEL);
> + dest_ring = kzalloc(struct_size(dest_ring, per_transfer_context,
> + nentries), GFP_KERNEL);
> if (!dest_ring)
> return ERR_PTR(-ENOMEM);
>
> --
> 2.7.4
>
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: [PATCH] iwlwifi: d3: use struct_size() in kzalloc()
From: Joe Perches @ 2018-08-24 4:33 UTC (permalink / raw)
To: Kees Cook, Gustavo A. R. Silva
Cc: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo, David S. Miller, linux-wireless,
Network Development, LKML
In-Reply-To: <CAGXu5jJxbFzKsV1=xHiKtcx+61QBsK0LYMrwo1vGNWgALzqakw@mail.gmail.com>
On Thu, 2018-08-23 at 20:03 -0700, Kees Cook wrote:
> On Thu, Aug 23, 2018 at 6:15 PM, Gustavo A. R. Silva
> <gustavo@embeddedor.com> wrote:
> > One of the more common cases of allocation size calculations is finding
> > the size of a structure that has a zero-sized array at the end, along
> > with memory for some number of elements for that array. For example:
> >
> > struct foo {
> > int stuff;
> > void *entry[];
> > };
Question for Gustavo.
Did you find any existing instances that are miscalculated?
I believe there are some cases like:
size = sizeof(struct foo) + count * sizeof(something);
ptr = kmalloc(size);
memset(ptr + sizeof(struct foo), 0, size - sizeof(struct foo));
where something could go wrong and not be detected.
^ permalink raw reply
* [PATCH NET 3/3] net: hns: add configuration constraints for 1000M half
From: Peng Li @ 2018-08-24 3:42 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
lipeng321
In-Reply-To: <1535082143-122281-1-git-send-email-lipeng321@huawei.com>
Hisilicon hip05 and hip06 board network card do not support
1000M half configuration. Driver can not config gmac as
1000M half.
Signed-off-by: Peng Li <lipeng321@huawei.com>
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
index 09e4061..c1d062e 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
@@ -272,6 +272,11 @@ static int hns_gmac_adjust_link(void *mac_drv, enum mac_speed speed,
{
struct mac_driver *drv = (struct mac_driver *)mac_drv;
+ if (full_duplex == DUPLEX_HALF && speed == MAC_SPEED_1000) {
+ dev_err(drv->dev, "HW do not support 1000M half\n");
+ return -EINVAL;
+ }
+
dsaf_set_dev_bit(drv, GMAC_DUPLEX_TYPE_REG,
GMAC_DUPLEX_TYPE_B, !!full_duplex);
--
2.9.3
^ permalink raw reply related
* [PATCH NET 2/3] net: hns: add netif_carrier_off before change speed and duplex
From: Peng Li @ 2018-08-24 3:42 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
lipeng321
In-Reply-To: <1535082143-122281-1-git-send-email-lipeng321@huawei.com>
If there are packets in hardware when changing the speed
or duplex, it may cause hardware hang up.
This patch adds netif_carrier_off before change speed and
duplex in ethtool_ops.set_link_ksettings, and adds
netif_carrier_on after complete the change.
Signed-off-by: Peng Li <lipeng321@huawei.com>
---
drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
index 08f3c47..774beda 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
@@ -243,7 +243,9 @@ static int hns_nic_set_link_ksettings(struct net_device *net_dev,
}
if (h->dev->ops->adjust_link) {
+ netif_carrier_off(net_dev);
h->dev->ops->adjust_link(h, (int)speed, cmd->base.duplex);
+ netif_carrier_on(net_dev);
return 0;
}
--
2.9.3
^ permalink raw reply related
* [PATCH NET 1/3] net: hns: add the code for cleaning pkt in chip
From: Peng Li @ 2018-08-24 3:42 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
lipeng321
In-Reply-To: <1535082143-122281-1-git-send-email-lipeng321@huawei.com>
If there are packets in hardware when changing the speed
or duplex, it may cause hardware hang up.
This patch adds the code for waiting chip to clean the all
pkts(TX & RX) in chip when the driver uses the function named
"adjust link".
This patch cleans the pkts as follows:
1) close rx of chip, close tx of protocol stack.
2) wait rcb, ppe, mac to clean.
3) adjust link
4) open rx of chip, open tx of protocol stack.
Signed-off-by: Peng Li <lipeng321@huawei.com>
---
drivers/net/ethernet/hisilicon/hns/hnae.h | 2 +
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 67 +++++++++++++++++++++-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 36 ++++++++++++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 44 ++++++++++++++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h | 8 +++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 29 ++++++++++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h | 3 +
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 23 ++++++++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.h | 1 +
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 23 ++++++++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h | 1 +
drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h | 1 +
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 21 ++++++-
13 files changed, 255 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h b/drivers/net/ethernet/hisilicon/hns/hnae.h
index cad52bd..08a750f 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -486,6 +486,8 @@ struct hnae_ae_ops {
u8 *auto_neg, u16 *speed, u8 *duplex);
void (*toggle_ring_irq)(struct hnae_ring *ring, u32 val);
void (*adjust_link)(struct hnae_handle *handle, int speed, int duplex);
+ bool (*need_adjust_link)(struct hnae_handle *handle,
+ int speed, int duplex);
int (*set_loopback)(struct hnae_handle *handle,
enum hnae_loop loop_mode, int en);
void (*get_ring_bdnum_limit)(struct hnae_queue *queue,
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index e6aad30..b52029e 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -155,6 +155,41 @@ static void hns_ae_put_handle(struct hnae_handle *handle)
hns_ae_get_ring_pair(handle->qs[i])->used_by_vf = 0;
}
+static int hns_ae_wait_flow_down(struct hnae_handle *handle)
+{
+ struct dsaf_device *dsaf_dev;
+ struct hns_ppe_cb *ppe_cb;
+ struct hnae_vf_cb *vf_cb;
+ int ret;
+ int i;
+
+ for (i = 0; i < handle->q_num; i++) {
+ ret = hns_rcb_wait_tx_ring_clean(handle->qs[i]);
+ if (ret)
+ return ret;
+ }
+
+ ppe_cb = hns_get_ppe_cb(handle);
+ ret = hns_ppe_wait_tx_fifo_clean(ppe_cb);
+ if (ret)
+ return ret;
+
+ dsaf_dev = hns_ae_get_dsaf_dev(handle->dev);
+ if (!dsaf_dev)
+ return -EINVAL;
+ ret = hns_dsaf_wait_pkt_clean(dsaf_dev, handle->dport_id);
+ if (ret)
+ return ret;
+
+ vf_cb = hns_ae_get_vf_cb(handle);
+ ret = hns_mac_wait_fifo_clean(vf_cb->mac_cb);
+ if (ret)
+ return ret;
+
+ mdelay(10);
+ return 0;
+}
+
static void hns_ae_ring_enable_all(struct hnae_handle *handle, int val)
{
int q_num = handle->q_num;
@@ -399,12 +434,41 @@ static int hns_ae_get_mac_info(struct hnae_handle *handle,
return hns_mac_get_port_info(mac_cb, auto_neg, speed, duplex);
}
+static bool hns_ae_need_adjust_link(struct hnae_handle *handle, int speed,
+ int duplex)
+{
+ struct hns_mac_cb *mac_cb = hns_get_mac_cb(handle);
+
+ return hns_mac_need_adjust_link(mac_cb, speed, duplex);
+}
+
static void hns_ae_adjust_link(struct hnae_handle *handle, int speed,
int duplex)
{
struct hns_mac_cb *mac_cb = hns_get_mac_cb(handle);
- hns_mac_adjust_link(mac_cb, speed, duplex);
+ switch (mac_cb->dsaf_dev->dsaf_ver) {
+ case AE_VERSION_1:
+ hns_mac_adjust_link(mac_cb, speed, duplex);
+ break;
+
+ case AE_VERSION_2:
+ /* chip need to clear all pkt inside */
+ hns_mac_disable(mac_cb, MAC_COMM_MODE_RX);
+ if (hns_ae_wait_flow_down(handle)) {
+ hns_mac_enable(mac_cb, MAC_COMM_MODE_RX);
+ break;
+ }
+
+ hns_mac_adjust_link(mac_cb, speed, duplex);
+ hns_mac_enable(mac_cb, MAC_COMM_MODE_RX);
+ break;
+
+ default:
+ break;
+ }
+
+ return;
}
static void hns_ae_get_ring_bdnum_limit(struct hnae_queue *queue,
@@ -902,6 +966,7 @@ static struct hnae_ae_ops hns_dsaf_ops = {
.get_status = hns_ae_get_link_status,
.get_info = hns_ae_get_mac_info,
.adjust_link = hns_ae_adjust_link,
+ .need_adjust_link = hns_ae_need_adjust_link,
.set_loopback = hns_ae_config_loopback,
.get_ring_bdnum_limit = hns_ae_get_ring_bdnum_limit,
.get_pauseparam = hns_ae_get_pauseparam,
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
index 5488c6e..09e4061 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
@@ -257,6 +257,16 @@ static void hns_gmac_get_pausefrm_cfg(void *mac_drv, u32 *rx_pause_en,
*tx_pause_en = dsaf_get_bit(pause_en, GMAC_PAUSE_EN_TX_FDFC_B);
}
+static bool hns_gmac_need_adjust_link(void *mac_drv, enum mac_speed speed,
+ int duplex)
+{
+ struct mac_driver *drv = (struct mac_driver *)mac_drv;
+ struct hns_mac_cb *mac_cb = drv->mac_cb;
+
+ return (mac_cb->speed != speed) ||
+ (mac_cb->half_duplex == duplex);
+}
+
static int hns_gmac_adjust_link(void *mac_drv, enum mac_speed speed,
u32 full_duplex)
{
@@ -309,6 +319,30 @@ static void hns_gmac_set_promisc(void *mac_drv, u8 en)
hns_gmac_set_uc_match(mac_drv, en);
}
+int hns_gmac_wait_fifo_clean(void *mac_drv)
+{
+ struct mac_driver *drv = (struct mac_driver *)mac_drv;
+ int wait_cnt;
+ u32 val;
+
+ wait_cnt = 0;
+ while (wait_cnt++ < HNS_MAX_WAIT_CNT) {
+ val = dsaf_read_dev(drv, GMAC_FIFO_STATE_REG);
+ /* bit5~bit0 is not send complete pkts */
+ if ((val & 0x3f) == 0)
+ break;
+ usleep_range(100, 200);
+ }
+
+ if (wait_cnt >= HNS_MAX_WAIT_CNT) {
+ dev_err(drv->dev,
+ "hns ge %d fifo was not idle.\n", drv->mac_id);
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
static void hns_gmac_init(void *mac_drv)
{
u32 port;
@@ -690,6 +724,7 @@ void *hns_gmac_config(struct hns_mac_cb *mac_cb, struct mac_params *mac_param)
mac_drv->mac_disable = hns_gmac_disable;
mac_drv->mac_free = hns_gmac_free;
mac_drv->adjust_link = hns_gmac_adjust_link;
+ mac_drv->need_adjust_link = hns_gmac_need_adjust_link;
mac_drv->set_tx_auto_pause_frames = hns_gmac_set_tx_auto_pause_frames;
mac_drv->config_max_frame_length = hns_gmac_config_max_frame_length;
mac_drv->mac_pausefrm_cfg = hns_gmac_pause_frm_cfg;
@@ -717,6 +752,7 @@ void *hns_gmac_config(struct hns_mac_cb *mac_cb, struct mac_params *mac_param)
mac_drv->get_strings = hns_gmac_get_strings;
mac_drv->update_stats = hns_gmac_update_stats;
mac_drv->set_promiscuous = hns_gmac_set_promisc;
+ mac_drv->wait_fifo_clean = hns_gmac_wait_fifo_clean;
return (void *)mac_drv;
}
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index 1c2326b..6ed6f14 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -114,6 +114,26 @@ int hns_mac_get_port_info(struct hns_mac_cb *mac_cb,
return 0;
}
+/**
+ *hns_mac_is_adjust_link - check is need change mac speed and duplex register
+ *@mac_cb: mac device
+ *@speed: phy device speed
+ *@duplex:phy device duplex
+ *
+ */
+bool hns_mac_need_adjust_link(struct hns_mac_cb *mac_cb, int speed, int duplex)
+{
+ struct mac_driver *mac_ctrl_drv;
+
+ mac_ctrl_drv = (struct mac_driver *)(mac_cb->priv.mac);
+
+ if (mac_ctrl_drv->need_adjust_link)
+ return mac_ctrl_drv->need_adjust_link(mac_ctrl_drv,
+ (enum mac_speed)speed, duplex);
+ else
+ return true;
+}
+
void hns_mac_adjust_link(struct hns_mac_cb *mac_cb, int speed, int duplex)
{
int ret;
@@ -430,6 +450,16 @@ int hns_mac_vm_config_bc_en(struct hns_mac_cb *mac_cb, u32 vmid, bool enable)
return 0;
}
+int hns_mac_wait_fifo_clean(struct hns_mac_cb *mac_cb)
+{
+ struct mac_driver *drv = hns_mac_get_drv(mac_cb);
+
+ if (drv->wait_fifo_clean)
+ return drv->wait_fifo_clean(drv);
+
+ return 0;
+}
+
void hns_mac_reset(struct hns_mac_cb *mac_cb)
{
struct mac_driver *drv = hns_mac_get_drv(mac_cb);
@@ -998,6 +1028,20 @@ static int hns_mac_get_max_port_num(struct dsaf_device *dsaf_dev)
return DSAF_MAX_PORT_NUM;
}
+void hns_mac_enable(struct hns_mac_cb *mac_cb, enum mac_commom_mode mode)
+{
+ struct mac_driver *mac_ctrl_drv = hns_mac_get_drv(mac_cb);
+
+ mac_ctrl_drv->mac_enable(mac_cb->priv.mac, mode);
+}
+
+void hns_mac_disable(struct hns_mac_cb *mac_cb, enum mac_commom_mode mode)
+{
+ struct mac_driver *mac_ctrl_drv = hns_mac_get_drv(mac_cb);
+
+ mac_ctrl_drv->mac_disable(mac_cb->priv.mac, mode);
+}
+
/**
* hns_mac_init - init mac
* @dsaf_dev: dsa fabric device struct pointer
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h
index bbc0a98..fbc7534 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h
@@ -356,6 +356,9 @@ struct mac_driver {
/*adjust mac mode of port,include speed and duplex*/
int (*adjust_link)(void *mac_drv, enum mac_speed speed,
u32 full_duplex);
+ /* need adjust link */
+ bool (*need_adjust_link)(void *mac_drv, enum mac_speed speed,
+ int duplex);
/* config autoegotaite mode of port*/
void (*set_an_mode)(void *mac_drv, u8 enable);
/* config loopbank mode */
@@ -394,6 +397,7 @@ struct mac_driver {
void (*get_info)(void *mac_drv, struct mac_info *mac_info);
void (*update_stats)(void *mac_drv);
+ int (*wait_fifo_clean)(void *mac_drv);
enum mac_mode mac_mode;
u8 mac_id;
@@ -427,6 +431,7 @@ void *hns_xgmac_config(struct hns_mac_cb *mac_cb,
int hns_mac_init(struct dsaf_device *dsaf_dev);
void mac_adjust_link(struct net_device *net_dev);
+bool hns_mac_need_adjust_link(struct hns_mac_cb *mac_cb, int speed, int duplex);
void hns_mac_get_link_status(struct hns_mac_cb *mac_cb, u32 *link_status);
int hns_mac_change_vf_addr(struct hns_mac_cb *mac_cb, u32 vmid, char *addr);
int hns_mac_set_multi(struct hns_mac_cb *mac_cb,
@@ -463,5 +468,8 @@ int hns_mac_add_uc_addr(struct hns_mac_cb *mac_cb, u8 vf_id,
int hns_mac_rm_uc_addr(struct hns_mac_cb *mac_cb, u8 vf_id,
const unsigned char *addr);
int hns_mac_clr_multicast(struct hns_mac_cb *mac_cb, int vfn);
+void hns_mac_enable(struct hns_mac_cb *mac_cb, enum mac_commom_mode mode);
+void hns_mac_disable(struct hns_mac_cb *mac_cb, enum mac_commom_mode mode);
+int hns_mac_wait_fifo_clean(struct hns_mac_cb *mac_cb);
#endif /* _HNS_DSAF_MAC_H */
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index ca50c25..e557a4e 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -2727,6 +2727,35 @@ void hns_dsaf_set_promisc_tcam(struct dsaf_device *dsaf_dev,
soft_mac_entry->index = enable ? entry_index : DSAF_INVALID_ENTRY_IDX;
}
+int hns_dsaf_wait_pkt_clean(struct dsaf_device *dsaf_dev, int port)
+{
+ u32 val, val_tmp;
+ int wait_cnt;
+
+ if (port >= DSAF_SERVICE_NW_NUM)
+ return 0;
+
+ wait_cnt = 0;
+ while (wait_cnt++ < HNS_MAX_WAIT_CNT) {
+ val = dsaf_read_dev(dsaf_dev, DSAF_VOQ_IN_PKT_NUM_0_REG +
+ (port + DSAF_XGE_NUM) * 0x40);
+ val_tmp = dsaf_read_dev(dsaf_dev, DSAF_VOQ_OUT_PKT_NUM_0_REG +
+ (port + DSAF_XGE_NUM) * 0x40);
+ if (val == val_tmp)
+ break;
+
+ usleep_range(100, 200);
+ }
+
+ if (wait_cnt >= HNS_MAX_WAIT_CNT) {
+ dev_err(dsaf_dev->dev, "hns dsaf clean wait timeout(%u - %u).\n",
+ val, val_tmp);
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
/**
* dsaf_probe - probo dsaf dev
* @pdev: dasf platform device
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
index 4507e82..0e1cd99 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
@@ -44,6 +44,8 @@ struct hns_mac_cb;
#define DSAF_ROCE_CREDIT_CHN 8
#define DSAF_ROCE_CHAN_MODE 3
+#define HNS_MAX_WAIT_CNT 10000
+
enum dsaf_roce_port_mode {
DSAF_ROCE_6PORT_MODE,
DSAF_ROCE_4PORT_MODE,
@@ -463,5 +465,6 @@ int hns_dsaf_rm_mac_addr(
int hns_dsaf_clr_mac_mc_port(struct dsaf_device *dsaf_dev,
u8 mac_id, u8 port_num);
+int hns_dsaf_wait_pkt_clean(struct dsaf_device *dsaf_dev, int port);
#endif /* __HNS_DSAF_MAIN_H__ */
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index d160d8c..0942e49 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -275,6 +275,29 @@ static void hns_ppe_exc_irq_en(struct hns_ppe_cb *ppe_cb, int en)
dsaf_write_dev(ppe_cb, PPE_INTEN_REG, msk_vlue & vld_msk);
}
+int hns_ppe_wait_tx_fifo_clean(struct hns_ppe_cb *ppe_cb)
+{
+ int wait_cnt;
+ u32 val;
+
+ wait_cnt = 0;
+ while (wait_cnt++ < HNS_MAX_WAIT_CNT) {
+ val = dsaf_read_dev(ppe_cb, PPE_CURR_TX_FIFO0_REG) & 0x3ffU;
+ if (!val)
+ break;
+
+ usleep_range(100, 200);
+ }
+
+ if (wait_cnt >= HNS_MAX_WAIT_CNT) {
+ dev_err(ppe_cb->dev, "hns ppe tx fifo clean wait timeout, still has %u pkt.\n",
+ val);
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
/**
* ppe_init_hw - init ppe
* @ppe_cb: ppe device
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.h b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.h
index 9d8e643..f670e63 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.h
@@ -100,6 +100,7 @@ struct ppe_common_cb {
};
+int hns_ppe_wait_tx_fifo_clean(struct hns_ppe_cb *ppe_cb);
int hns_ppe_init(struct dsaf_device *dsaf_dev);
void hns_ppe_uninit(struct dsaf_device *dsaf_dev);
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index 9d76e2e..5d64519 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -66,6 +66,29 @@ void hns_rcb_wait_fbd_clean(struct hnae_queue **qs, int q_num, u32 flag)
"queue(%d) wait fbd(%d) clean fail!!\n", i, fbd_num);
}
+int hns_rcb_wait_tx_ring_clean(struct hnae_queue *qs)
+{
+ u32 head, tail;
+ int wait_cnt;
+
+ tail = dsaf_read_dev(&qs->tx_ring, RCB_REG_TAIL);
+ wait_cnt = 0;
+ while (wait_cnt++ < HNS_MAX_WAIT_CNT) {
+ head = dsaf_read_dev(&qs->tx_ring, RCB_REG_HEAD);
+ if (tail == head)
+ break;
+
+ usleep_range(100, 200);
+ }
+
+ if (wait_cnt >= HNS_MAX_WAIT_CNT) {
+ dev_err(qs->dev->dev, "rcb wait timeout, head not equal to tail.\n");
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
/**
*hns_rcb_reset_ring_hw - ring reset
*@q: ring struct pointer
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
index 6028164..2319b77 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h
@@ -136,6 +136,7 @@ void hns_rcbv2_int_clr_hw(struct hnae_queue *q, u32 flag);
void hns_rcb_init_hw(struct ring_pair_cb *ring);
void hns_rcb_reset_ring_hw(struct hnae_queue *q);
void hns_rcb_wait_fbd_clean(struct hnae_queue **qs, int q_num, u32 flag);
+int hns_rcb_wait_tx_ring_clean(struct hnae_queue *qs);
u32 hns_rcb_get_rx_coalesced_frames(
struct rcb_common_cb *rcb_common, u32 port_idx);
u32 hns_rcb_get_tx_coalesced_frames(
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index 886cbbf..74d935d 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@ -464,6 +464,7 @@
#define RCB_RING_INTMSK_TX_OVERTIME_REG 0x000C4
#define RCB_RING_INTSTS_TX_OVERTIME_REG 0x000C8
+#define GMAC_FIFO_STATE_REG 0x0000UL
#define GMAC_DUPLEX_TYPE_REG 0x0008UL
#define GMAC_FD_FC_TYPE_REG 0x000CUL
#define GMAC_TX_WATER_LINE_REG 0x0010UL
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index 02a0ba2..f56855e 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -1112,11 +1112,26 @@ static void hns_nic_adjust_link(struct net_device *ndev)
struct hnae_handle *h = priv->ae_handle;
int state = 1;
+ /* If there is no phy, do not need adjust link */
if (ndev->phydev) {
- h->dev->ops->adjust_link(h, ndev->phydev->speed,
- ndev->phydev->duplex);
- state = ndev->phydev->link;
+ /* When phy link down, do nothing */
+ if (ndev->phydev->link == 0)
+ return;
+
+ if (h->dev->ops->need_adjust_link(h, ndev->phydev->speed,
+ ndev->phydev->duplex)) {
+ /* because Hi161X chip don't support to change gmac
+ * speed and duplex with traffic. Delay 200ms to
+ * make sure there is no more data in chip FIFO.
+ */
+ netif_carrier_off(ndev);
+ msleep(200);
+ h->dev->ops->adjust_link(h, ndev->phydev->speed,
+ ndev->phydev->duplex);
+ netif_carrier_on(ndev);
+ }
}
+
state = state && h->dev->ops->get_status(h);
if (state != priv->link) {
--
2.9.3
^ permalink raw reply related
* [PATCH net 0/3] net: hns: fix some bugs about speed and duplex change
From: Peng Li @ 2018-08-24 3:42 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
lipeng321
1, If there are packets in hardware when changing the spped
or duplex, it may cause hardware hang up.
This patchset adds the code for waiting chip to clean the all
pkts(TX & RX) in chip when the driver uses the function named
"adjust link".
This patchset cleans the pkts as follows:
1) close rx of chip, close tx of protocol stack.
2) wait rcb, ppe, mac to clean.
3) adjust link
4) open rx of chip, open tx of protocol stack.
2, Hisilicon hip05 and hip06 board network card do not
support 1000M half configuration. Driver can not config
gmac as 1000M half.
Peng Li (3):
net: hns: add the code for cleaning pkt in chip
net: hns: add netif_carrier_off before change speed and duplex
net: hns: add configuration constraints for 1000M half
drivers/net/ethernet/hisilicon/hns/hnae.h | 2 +
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 67 +++++++++++++++++++++-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 41 +++++++++++++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 44 ++++++++++++++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h | 8 +++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 29 ++++++++++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h | 3 +
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 23 ++++++++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.h | 1 +
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 23 ++++++++
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.h | 1 +
drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h | 1 +
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 21 ++++++-
drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 2 +
14 files changed, 262 insertions(+), 4 deletions(-)
--
2.9.3
^ permalink raw reply
* Re: [PATCH NET 3/3] net: hns: add configuration constraints for 1000M half
From: Andrew Lunn @ 2018-08-24 3:41 UTC (permalink / raw)
To: Peng Li; +Cc: davem, netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta
In-Reply-To: <1535082143-122281-4-git-send-email-lipeng321@huawei.com>
On Fri, Aug 24, 2018 at 11:42:23AM +0800, Peng Li wrote:
> Hisilicon hip05 and hip06 board network card do not support
> 1000M half configuration. Driver can not config gmac as
> 1000M half.
>
> Signed-off-by: Peng Li <lipeng321@huawei.com>
Hi Peng
Does the driver remove SUPPORTED_1000baseT_Half from
phydev->supported? If you do that, the PHY should never negotiate
this speed.
Andrew
^ permalink raw reply
* Re: [PATCH] iwlwifi: d3: use struct_size() in kzalloc()
From: Kees Cook @ 2018-08-24 3:03 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo, David S. Miller, linux-wireless,
Network Development, LKML
In-Reply-To: <20180824011540.GA25716@embeddedor.com>
On Thu, Aug 23, 2018 at 6:15 PM, Gustavo A. R. Silva
<gustavo@embeddedor.com> wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entry[];
> };
>
> instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> This issue was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
> drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
> index 79bdae9..6960318 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
> @@ -1769,8 +1769,7 @@ static void iwl_mvm_query_netdetect_reasons(struct iwl_mvm *mvm,
> n_matches = 0;
> }
>
> - net_detect = kzalloc(sizeof(*net_detect) +
> - (n_matches * sizeof(net_detect->matches[0])),
> + net_detect = kzalloc(struct_size(net_detect, matches, n_matches),
> GFP_KERNEL);
> if (!net_detect || !n_matches)
> goto out_report_nd;
> @@ -1785,8 +1784,7 @@ static void iwl_mvm_query_netdetect_reasons(struct iwl_mvm *mvm,
> for (j = 0; j < SCAN_OFFLOAD_MATCHING_CHANNELS_LEN; j++)
> n_channels += hweight8(fw_match->matching_channels[j]);
>
> - match = kzalloc(sizeof(*match) +
> - (n_channels * sizeof(*match->channels)),
> + match = kzalloc(struct_size(match, channels, n_channels),
> GFP_KERNEL);
> if (!match)
> goto out_report_nd;
> --
> 2.7.4
>
--
Kees Cook
Pixel Security
^ permalink raw reply
* [Patch net] tipc: fix a missing rhashtable_walk_exit()
From: Cong Wang @ 2018-08-23 23:19 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, Herbert Xu, Ying Xue
rhashtable_walk_exit() must be paired with rhashtable_walk_enter().
Fixes: 40f9f4397060 ("tipc: Fix tipc_sk_reinit race conditions")
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/tipc/socket.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index c1e93c9515bc..c9a50b62c738 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -2672,6 +2672,8 @@ void tipc_sk_reinit(struct net *net)
rhashtable_walk_stop(&iter);
} while (tsk == ERR_PTR(-EAGAIN));
+
+ rhashtable_walk_exit(&iter);
}
static struct tipc_sock *tipc_sk_lookup(struct net *net, u32 portid)
--
2.14.4
^ permalink raw reply related
* Re: [PATCH bpf] xsk: fix return value of xdp_umem_assign_dev()
From: Daniel Borkmann @ 2018-08-23 23:10 UTC (permalink / raw)
To: Jakub Kicinski, Prashant Bhole
Cc: Alexei Starovoitov, Björn Töpel, Magnus Karlsson,
David S . Miller, netdev
In-Reply-To: <20180823202938.17b036f7@cakuba.netronome.com>
On 08/23/2018 08:29 PM, Jakub Kicinski wrote:
> On Mon, 20 Aug 2018 09:54:25 +0900, Prashant Bhole wrote:
>> s/ENOTSUPP/EOPNOTSUPP/ in function umem_assign_dev().
>> This function's return value is directly returned by xsk_bind().
>> EOPNOTSUPP is bind()'s possible return value.
>>
>> Fixes: f734607e819b ("xsk: refactor xdp_umem_assign_dev()")
>> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
>
> FWIW the refactoring commit just cleaned up the code, is it worth
> submitting a patch to stable to correct 4.18 as well?
Yep, lets do that once it lands in mainline. Thanks!
^ permalink raw reply
* pull-request: bpf 2018-08-24
From: Daniel Borkmann @ 2018-08-23 23:09 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Fix BPF sockmap and tls where we get a hang in do_tcp_sendpages()
when sndbuf is full due to missing calls into underlying socket's
sk_write_space(), from John.
2) Two BPF sockmap fixes to reject invalid parameters on map creation
and to fix a map element miscount on allocation failure. Another fix
for BPF hash tables to use per hash table salt for jhash(), from Daniel.
3) Fix for bpftool's command line parsing in order to terminate on bad
arguments instead of keeping looping in some border cases, from Quentin.
4) Fix error value of xdp_umem_assign_dev() in order to comply with
expected bind ops error codes, from Prashant.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit b93c1b5ac8643cc08bb74fa8ae21d6c63dfcb23d:
hv_netvsc: ignore devices that are not PCI (2018-08-21 12:02:11 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
for you to fetch changes up to 785e76d7a2051a9e28b9134d5388a45b16f5eb72:
tools: bpftool: return from do_event_pipe() on bad arguments (2018-08-23 20:17:57 +0200)
----------------------------------------------------------------
Daniel Borkmann (3):
bpf, sockmap: fix sock_hash_alloc and reject zero-sized keys
bpf, sockmap: fix sock hash count in alloc_sock_hash_elem
bpf: use per htab salt for bucket hash
John Fastabend (2):
tls: possible hang when do_tcp_sendpages hits sndbuf is full case
bpf: sockmap: write_space events need to be passed to TCP handler
Prashant Bhole (1):
xsk: fix return value of xdp_umem_assign_dev()
Quentin Monnet (1):
tools: bpftool: return from do_event_pipe() on bad arguments
kernel/bpf/hashtab.c | 23 +++++++++++++----------
kernel/bpf/sockmap.c | 11 +++++++++--
net/tls/tls_main.c | 9 +++++++--
net/xdp/xdp_umem.c | 4 ++--
tools/bpf/bpftool/map_perf_ring.c | 5 ++++-
5 files changed, 35 insertions(+), 17 deletions(-)
^ 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