* Re: KASAN: use-after-free Read in sctp_transport_get_next
From: Marcelo Ricardo Leitner @ 2018-08-24 12:51 UTC (permalink / raw)
To: syzbot
Cc: davem, linux-kernel, linux-sctp, netdev, nhorman, syzkaller-bugs,
vyasevich, lucien.xin
In-Reply-To: <000000000000ccaf1d0574297b6b@google.com>
On Fri, Aug 24, 2018 at 12:40:03AM -0700, syzbot wrote:
> 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]
It is iterating over transports but then also accessing the
association directly, without checking any refcnts before that.
struct sctp_transport *sctp_transport_get_next(struct net *net,
struct rhashtable_iter *iter)
{
struct sctp_transport *t;
t = rhashtable_walk_next(iter);
for (; t; t = rhashtable_walk_next(iter)) {
if (IS_ERR(t)) {
if (PTR_ERR(t) == -EAGAIN)
continue;
break;
}
if (net_eq(sock_net(t->asoc->base.sk), net) &&
t->asoc->peer.primary_path == t)
break;
and these t->asoc-> are risky because transport may be laying dead on
the water already, as transports are freed by RCU and associations are
not.
^ permalink raw reply
* Re: [PATCH 2/3][can-next] can: rcar_can: Add RZ/G2 support
From: Simon Horman @ 2018-08-24 9:16 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Sergei Shtylyov,
David S. Miller, linux-can, netdev, Geert Uytterhoeven,
Chris Paterson, Biju Das, linux-renesas-soc
In-Reply-To: <1535029653-7418-3-git-send-email-fabrizio.castro@bp.renesas.com>
On Thu, Aug 23, 2018 at 02:07:32PM +0100, Fabrizio Castro wrote:
> RZ/G2 devices don't have clkp2, therefore this commit adds a
> generic compatible string for them to allow for proper checking
> during probe.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Signed-off-by: Chris Paterson <Chris.Paterson2@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 linux-can-next-for-4.19-20180727
>
> drivers/net/can/rcar/rcar_can.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/can/rcar/rcar_can.c b/drivers/net/can/rcar/rcar_can.c
> index fbd9284..397208e 100644
> --- a/drivers/net/can/rcar/rcar_can.c
> +++ b/drivers/net/can/rcar/rcar_can.c
> @@ -27,6 +27,7 @@
>
> #define RCAR_SUPPORTED_CLOCKS (BIT(CLKR_CLKP1) | BIT(CLKR_CLKP2) | \
> BIT(CLKR_CLKEXT))
> +#define RZG2_SUPPORTED_CLOCKS (BIT(CLKR_CLKP1) | BIT(CLKR_CLKEXT))
>
> /* Mailbox configuration:
> * mailbox 60 - 63 - Rx FIFO mailboxes
> @@ -933,6 +934,10 @@ static const struct of_device_id rcar_can_of_table[] __maybe_unused = {
> .compatible = "renesas,rcar-gen3-can",
> .data = (void *)RCAR_SUPPORTED_CLOCKS,
> },
> + {
> + .compatible = "renesas,rzg-gen2-can",
> + .data = (void *)RZG2_SUPPORTED_CLOCKS,
> + },
> { }
> };
> MODULE_DEVICE_TABLE(of, rcar_can_of_table);
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 1/3][can-next] can: rcar_can: Fix erroneous registration
From: Simon Horman @ 2018-08-24 9:15 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Sergei Shtylyov,
David S. Miller, linux-can, netdev, Geert Uytterhoeven,
Chris Paterson, Biju Das, linux-renesas-soc
In-Reply-To: <1535029653-7418-2-git-send-email-fabrizio.castro@bp.renesas.com>
On Thu, Aug 23, 2018 at 02:07:31PM +0100, Fabrizio Castro wrote:
> Assigning 2 to "renesas,can-clock-select" tricks the driver into
> registering the CAN interface, even though we don't want that.
> This patch fixes this problem and also allows for architectures
> missing some of the clocks (e.g. RZ/G2) to behave as expected.
>
> Fixes: 862e2b6af9413b43 ("can: rcar_can: support all input clocks")
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [net 07/13] ice: Use order_base_2 to calculate higher power of 2
From: Sergei Shtylyov @ 2018-08-24 9:03 UTC (permalink / raw)
To: Jeff Kirsher, davem
Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene,
Anirudh Venkataramanan
In-Reply-To: <20180823191503.15804-8-jeffrey.t.kirsher@intel.com>
Hello!
On 8/23/2018 10:14 PM, Jeff Kirsher wrote:
> From: Jacob Keller <jacob.e.keller@intel.com>
>
> Currently, we use a combination of ilog2 and is_power_of_2() to
> calculate the next power of 2 for the qcount. This appears to be causing
> a warning on some combinations of GCC and the Linux kernel:
>
> MODPOST 1 modules
> WARNING: "____ilog2_NaN" [ice.ko] undefined!
>
> This appears to because because GCC realizes that qcount could be zero
One "because" is enough. :-)
> in some circumstances and thus attempts to link against the
> intentionally undefined ___ilog2_NaN function.
>
> The order_base_2 function is intentionally defined to return 0 when
> passed 0 as an argument, and thus will be safe to use here.
>
> This not only fixes the warning but makes the resulting code slightly
> cleaner, and is really what we should have used originally.
>
> Also update the comment to make it more clear that we are rounding up,
> not just incrementing the ilog2 of qcount unconditionally.
>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] dt-bindings: can: rcar_can: Add r8a774a1 support
From: Simon Horman @ 2018-08-24 8:26 UTC (permalink / raw)
To: Chris Paterson
Cc: Fabrizio Castro, 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: <TYAPR01MB2285834E95AB0D0D3E2C5B72B7300@TYAPR01MB2285.jpnprd01.prod.outlook.com>
On Wed, Aug 22, 2018 at 03:12:26PM +0000, Chris Paterson wrote:
> Hello Simon,
>
> > From: Simon Horman <horms@verge.net.au>
> > Sent: 22 August 2018 11:49
> >
> > On Fri, Aug 17, 2018 at 03:38:23PM +0100, Fabrizio Castro wrote:
> > > Document RZ/G2M (r8a774a1) SoC bindings.
> > >
> > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> >
> > Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
>
> Thank you.
>
> >
> > > ---
> > > This patch applies on top of next-20180817
> > >
> > > Documentation/devicetree/bindings/net/can/rcar_can.txt | 8 ++++++--
> > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt
> > > b/Documentation/devicetree/bindings/net/can/rcar_can.txt
> > > index 94a7f33..84afc78 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.
> > > @@ -16,7 +17,8 @@ Required properties:
> > > "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device.
> > > "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,rcar-gen3-can" for a generic R-Car Gen3 or 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", and
> >
> > Minor comment: Personally I would start a new sentence at "and".
> >
> > Question: Is a driver update required so support 2-clock SoCs?
>
> The driver will work okay as-is.
>
> 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.
^ permalink raw reply
* Re: [PATCH] iwlwifi: d3: use struct_size() in kzalloc()
From: Gustavo A. R. Silva @ 2018-08-24 11:58 UTC (permalink / raw)
To: Joe Perches, Kees Cook
Cc: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo, David S. Miller, linux-wireless,
Network Development, LKML
In-Reply-To: <d0ee04ea40bfc2aecd71b3ed1e1d388911b7d6cb.camel@perches.com>
Hi Joe,
On 8/23/18 11:33 PM, Joe Perches wrote:
> 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 found the following bug:
https://lore.kernel.org/patchwork/patch/977357/
> 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.
>
It might be worth it to write a Coccinelle script for this.
--
Gustavo
^ permalink raw reply
* Re: broken behaviour of TC filter delete
From: Jiri Pirko @ 2018-08-24 8:17 UTC (permalink / raw)
To: Roman Mashak; +Cc: netdev, jiri, Jamal Hadi Salim
In-Reply-To: <851sao225x.fsf@mojatatu.com>
Thu, Aug 23, 2018 at 11:39:22PM CEST, mrv@mojatatu.com wrote:
>
>
>It appears that the following commit changed the behaviour of scenario where a
>filter is deleted twice:
>
>commit f71e0ca4db187af7c44987e9d21e9042c3046070
>Author: Jiri Pirko <jiri@mellanox.com>
>Date: Mon Jul 23 09:23:05 2018 +0200
>
> net: sched: Avoid implicit chain 0 creation
>
>
>Steps to reproduce :
>
>1) create dummy device
> $ ip link add dev dummy0 type dummy
>
>2) create qdisc
> $ tc qdisc add dev dummy0 ingress
>
>3) create simple u32 filter with action attached
> $ tc filter add dev dummy0 parent ffff: protocol ip prio 1 u32 match ip src 10.10.10.1/32 action ok
>
>4) list the filter
> $ tc filter ls dev dummy0 parent ffff:
>
>5) delete the filter with the given protocol and priority
> $ tc filter del dev dummy0 parent ffff: protocol ip prio 1
>
>6) repeat step 5, this will return -ENOENT ("Error: Filter with specified priority/protocol not found.")
>However, before the change at step 6 we would get -EINVAL (Error: Cannot find specified filter chain.)
>and that makes sense.
Wait, this now returns:
Error: Cannot find specified filter chain.
So you want it to return -EINVAL (Error: Cannot find specified filter chain.) ?
How about for other chains?
>
>The change breaks a number of our internal TC tests.
^ permalink raw reply
* Re: [PATCH] wcn36xx: use dma_zalloc_coherent instead of allocator/memset
From: Kalle Valo @ 2018-08-24 11:50 UTC (permalink / raw)
To: YueHaibing
Cc: davem, linux-kernel, netdev, linux-wireless, wcn36xx, YueHaibing
In-Reply-To: <20180724115211.19264-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Use dma_zalloc_coherent instead of dma_alloc_coherent
> followed by memset 0.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
d410e28f3ae4 wcn36xx: use dma_zalloc_coherent instead of allocator/memset
--
https://patchwork.kernel.org/patch/10541939/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] wcn36xx: Use kmemdup instead of duplicating it in wcn36xx_smd_process_ptt_msg_rsp
From: Kalle Valo @ 2018-08-24 11:49 UTC (permalink / raw)
To: YueHaibing
Cc: davem, linux-kernel, netdev, linux-wireless, wcn36xx, YueHaibing
In-Reply-To: <20180724114317.18580-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Replace calls to kmalloc followed by a memcpy with a direct call to
> kmemdup.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
3f96556f639e wcn36xx: Use kmemdup instead of duplicating it in wcn36xx_smd_process_ptt_msg_rsp
--
https://patchwork.kernel.org/patch/10541903/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* 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
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