Re: [PATCH bpf] bpf: fix ldx in ld_abs rewrite for large offsets

On Tue, Jul 10, 2018 at 02:13:42PM +0200, Daniel Borkmann wrote: > On 07/10/2018 12:14 PM, Mark Rutland wrote: > > On Tue, Jul 10, 2018 at 12:43:22AM +0200, Daniel Borkmann wrote: > >> Mark reported that syzkaller triggered a KASAN detected slab-out-of-bounds > >

Re: [PATCH bpf] bpf: fix ldx in ld_abs rewrite for large offsets

mplement ld_abs/ld_ind in native bpf") > Reported-by: syzbot > Reported-by: Mark Rutland > Signed-off-by: Daniel Borkmann > --- > net/core/filter.c | 16 +--- > 1 file changed, 13 insertions(+), 3 deletions(-) > > diff --git a/net/core/filter.c b/net/c

Re: [PATCH] bpf: fix possible spectre-v1 in find_and_alloc_map()

On Fri, May 04, 2018 at 02:16:31AM +0200, Daniel Borkmann wrote: > On 05/03/2018 06:04 PM, Mark Rutland wrote: > > It's possible for userspace to control attr->map_type. Sanitize it when > > using it as an array index to prevent an out-of-bounds value being used >

[PATCH] bpf: fix possible spectre-v1 in find_and_alloc_map()

It's possible for userspace to control attr->map_type. Sanitize it when using it as an array index to prevent an out-of-bounds value being used under speculation. Found by smatch. Signed-off-by: Mark Rutland <mark.rutl...@arm.com> Cc: Alexei Starovoitov <a...@kernel.org> Cc

[PATCH RESEND] SUNRPC: fix include for cmpxchg_relaxed()

include today, but this isn't something we can/should rely upon, especially with ongoing rework of the atomic headers for KASAN instrumentation. Let's fix the code to include , avoiding fragility. Signed-off-by: Mark Rutland <mark.rutl...@arm.com> Cc: Trond Myklebust <tro

v4.16 in_dev_finish_destroy() accessing freed idev->dev->pcpu_refcnt

Hi all, As a heads-up, while fuzzing v4.16 on arm64, I'm hitting an intermittent issue where in_dev_finish_destroy() calls dev_put() on idev->dev, where idev->dev->pcpu_refcnt is NULL. Apparently idev->dev has already been freed. This results in a fault where we try to access the percpu offset

dns_resolver_preparse tries to print arbitrarily-large user-provided strings

Hi, As a heads-up, while fuzzing v4.16-rc3 on arm64 with Syzkaller, I hit a system hang which I was able to minize to the reproducer below. It looks like the system hang is an artifact of Syzkaller using panic_on_warn, as dns_resolver_preparse can trigger a WARN_ONCE() in the bowels of printk(),

Re: v4.16-rc1 misaligned atomics in skb__clone / __napi_alloc_skb

gro_frags() > > for TUN/TAP driver > > 943170998b200190f99d3fe7e771437e2c51f319 tun: enable NAPI for TUN/TAP driver > > Can you try this patch ? Looks good! No splats after 10 minutes with a test that usually fails in a few seconds. FWIW: Tested-by: Mark Rutland <mark.rutl.

Re: v4.16-rc1 misaligned atomics in skb__clone / __napi_alloc_skb

On Thu, Feb 15, 2018 at 09:24:36AM -0800, Eric Dumazet wrote: > On Thu, Feb 15, 2018 at 9:20 AM, Eric Dumazet wrote: > > > > Yes, it seems tun.c breaks the assumptions. > > > > If it really wants to provide arbitrary fragments and alignments, it > > should use a separate > >

v4.16-rc1 misaligned atomics in skb__clone / __napi_alloc_skb

Hi, While fuzzing arm64 v4.16-rc1 with Syzkaller, I've been hitting a misaligned atomic in __skb_clone: atomic_inc(&(skb_shinfo(skb)->dataref)); .. where dataref doesn't have the required natural alignment, and the atomic operation faults. e.g. i often see it aligned to a single byte

Re: [PATCH bpf] bpf: prevent out-of-bounds speculation

On Mon, Jan 08, 2018 at 10:49:01AM -0800, Linus Torvalds wrote: > On Mon, Jan 8, 2018 at 9:05 AM, Mark Rutland <mark.rutl...@arm.com> wrote: > > > > I'm a little worried that in the presence of some CPU/compiler > > optimisations, the masking may effectively be skippe

Re: [PATCH 02/18] Documentation: document nospec helpers

Hi Jon, On Mon, Jan 08, 2018 at 09:29:17AM -0700, Jonathan Corbet wrote: > On Fri, 05 Jan 2018 17:10:03 -0800 > Dan Williams wrote: > > > Document the rationale and usage of the new nospec*() helpers. > > I have just a couple of overall comments. > > - It would be

Re: [PATCH bpf] bpf: prevent out-of-bounds speculation

Hi Alexei, On Thu, Jan 04, 2018 at 08:28:11PM -0800, Alexei Starovoitov wrote: > From: Alexei Starovoitov > > Under speculation, CPUs may mis-predict branches in bounds checks. Thus, > memory accesses under a bounds check may be speculated even if the > bounds check fails,

Re: [PATCH 01/18] asm-generic/barrier: add generic nospec helpers

On Fri, Jan 05, 2018 at 09:23:06PM -0800, Dan Williams wrote: > On Fri, Jan 5, 2018 at 6:55 PM, Linus Torvalds > wrote: > > On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams > > wrote: > >> +#ifndef nospec_ptr > >> +#define nospec_ptr(ptr, lo,

Re: [PATCH bpf] bpf: prevent out-of-bounds speculation

Hi Alexei, On Thu, Jan 04, 2018 at 08:28:11PM -0800, Alexei Starovoitov wrote: > From: Alexei Starovoitov > > Under speculation, CPUs may mis-predict branches in bounds checks. Thus, > memory accesses under a bounds check may be speculated even if the > bounds check fails,

Re: [PATCHv2 1/3] dt-bindings: net: Add DT bindings for Socionext Netsec

Hi, On Tue, Dec 12, 2017 at 10:45:21PM +0530, jassisinghb...@gmail.com wrote: > From: Jassi Brar > > This patch adds documentation for Device-Tree bindings for the > Socionext NetSec Controller driver. > > Signed-off-by: Ard Biesheuvel >

Re: [PATCH v3 17/33] nds32: VDSO support

On Fri, Dec 08, 2017 at 07:54:42PM +0800, Greentime Hu wrote: > 2017-12-08 18:21 GMT+08:00 Mark Rutland <mark.rutl...@arm.com>: > > On Fri, Dec 08, 2017 at 05:12:00PM +0800, Greentime Hu wrote: > >> +static int grab_timer_node_info(void) > >> +{ > >

Re: [PATCH v3 24/33] nds32: Device tree support

On Fri, Dec 08, 2017 at 05:12:07PM +0800, Greentime Hu wrote: > + timer0: timer@9840 { > + compatible = "andestech,atftmr010"; > + reg = <0x9840 0x1000>; > + interrupts = <19>; > + clocks = <_pll>; > + clock-names =

Re: [PATCH v3 24/33] nds32: Device tree support

On Fri, Dec 08, 2017 at 05:12:07PM +0800, Greentime Hu wrote: > + timer0: timer@f040 { > + compatible = "andestech,atcpit100"; > + reg = <0xf040 0x1000>; > + interrupts = <2>; > + clocks = <_pll>; > + clock-names = "apb_pclk";

Re: [PATCH v3 17/33] nds32: VDSO support

On Fri, Dec 08, 2017 at 05:12:00PM +0800, Greentime Hu wrote: > From: Greentime Hu > > This patch adds VDSO support. The VDSO code is currently used for > sys_rt_sigreturn() and optimised gettimeofday() (using the SoC timer counter). [...] > +static int

Re: [PATCH v2 10/35] nds32: Atomic operations

Hi, On Mon, Nov 27, 2017 at 08:27:57PM +0800, Greentime Hu wrote: > +static inline void arch_spin_unlock(arch_spinlock_t * lock) > +{ > + asm volatile( > + "xor$r15, $r15, $r15\n" > + "swi$r15, [%0]\n" > + : > + :"r"(>lock) > +

Re: [PATCH v2 06/35] nds32: MMU fault handling and page table management

Hi, On Mon, Nov 27, 2017 at 08:27:53PM +0800, Greentime Hu wrote: > +void do_page_fault(unsigned long entry, unsigned long addr, > +unsigned int error_code, struct pt_regs *regs) > +{ > + /* > + * As per x86, we may deadlock here. However, since the kernel only > +

Re: [PATCH v2 29/35] dt-bindings: nds32 CPU Bindings

Him On Mon, Nov 27, 2017 at 08:28:16PM +0800, Greentime Hu wrote: > From: Greentime Hu > > This patch adds nds32 CPU binding documents. > > Signed-off-by: Vincent Chen > Signed-off-by: Rick Chen > Signed-off-by: Zong Li

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

On Fri, Oct 20, 2017 at 10:40:38AM -0400, Wei Wei wrote: > Sadly, the syzkaller characterized it as a non-reproducible bug and there > were empty > repro files. But if manually executing in VM like this “./syz-execprog > -executor= > ./syz-executor -repeat=0 -procs=16 -cover=0 crash-log”, it

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

On Thu, Oct 19, 2017 at 10:16:08PM -0400, Wei Wei wrote: > Hi all, Hi, > I have fuzzed v4.14-rc3 using syzkaller and found a bug similar to that one > [1]. > But the call trace isn’t the same. The atomic_inc() might handle a corrupted > skb_buff. > > The logs and config have been uploaded to

Re: [PATCH] bpf: devmap: Check attr->max_entries more carefully

On Mon, Oct 16, 2017 at 08:52:13PM +0200, Daniel Borkmann wrote: > [ +Tejun, Mark, John ] > > On 10/16/2017 12:00 AM, Richard Weinberger wrote: > > max_entries is user controlled and used as input for __alloc_percpu(). > > This function expects that the allocation size is a power of two and > >

Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

On Mon, Oct 02, 2017 at 10:27:15AM -0700, Eric Dumazet wrote: > On Mon, Oct 2, 2017 at 10:21 AM, Mark Rutland <mark.rutl...@arm.com> wrote: > > On Mon, Oct 02, 2017 at 07:48:28AM -0700, Eric Dumazet wrote: > >> Please try the following fool proof patch. > >> &g

Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

On Mon, Oct 02, 2017 at 07:48:28AM -0700, Eric Dumazet wrote: > Please try the following fool proof patch. > > This is what I had in my local tree back in August but could not > conclude on the syzkaller bug I was working on. > > diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c > index >

Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

On Mon, Oct 02, 2017 at 07:48:28AM -0700, Eric Dumazet wrote: > Please try the following fool proof patch. > > This is what I had in my local tree back in August but could not > conclude on the syzkaller bug I was working on. Thanks, I'll give this a go shortly. I'm currently minimizing the

Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

On Mon, Oct 02, 2017 at 07:42:17AM -0700, Eric Dumazet wrote: > On Mon, Oct 2, 2017 at 7:21 AM, Mark Rutland <mark.rutl...@arm.com> wrote: > > Just to check I've understood correctly, are you suggesting that the > > IPv4 code should also check the dev->mtu against a IP_MI

Re: v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

Hi Eric, On Mon, Oct 02, 2017 at 06:36:32AM -0700, Eric Dumazet wrote: > On Mon, Oct 2, 2017 at 3:49 AM, Mark Rutland <mark.rutl...@arm.com> wrote: > > I hit the below splat at net/core/skbuff.c:2626 while fuzzing v4.14-rc2 > > on arm64 with Syzkaller. This is the B

v4.14-rc2/arm64 misaligned atomic in ip_expire() / skb_clone()

Hi all, I'm intermittently hitting splats like below in skb_clone() while fuzzing v4.14-rc2 on arm64 with Syzkaller. It looks like the atomic_inc() at the end of __skb_clone() is being passed a misaligned pointer. I've uploaded a number of splats and their associated (full) Syzkaller logs, along

v4.14-rc2/arm64 kernel BUG at net/core/skbuff.c:2626

Hi all, I hit the below splat at net/core/skbuff.c:2626 while fuzzing v4.14-rc2 on arm64 with Syzkaller. This is the BUG_ON(len) at the end of skb_copy_and_csum_bits(). I've uploaded a copy of the splat, my config, and (full) Syzkaller log to my kernel.org web space [1]. I haven't had the

Re: EBPF-triggered WARNING at mm/percpu.c:1361 in v4-14-rc2

On Thu, Sep 28, 2017 at 04:37:46PM +0200, Daniel Borkmann wrote: > On 09/28/2017 01:27 PM, Mark Rutland wrote: > >Hi, > > > >While fuzzing v4.14-rc2 with Syzkaller, I found it was possible to trigger > >the > >warning at mm/percpu.c:1361, on both arm64 and x8

EBPF-triggered WARNING at mm/percpu.c:1361 in v4-14-rc2

Hi, While fuzzing v4.14-rc2 with Syzkaller, I found it was possible to trigger the warning at mm/percpu.c:1361, on both arm64 and x86_64. This appears to require increasing RLIMIT_MEMLOCK, so to the best of my knowledge this cannot be triggered by an unprivileged user. I've included example

Re: arm64: next-20170428 hangs on boot

On Fri, Apr 28, 2017 at 04:24:29PM +0300, Yury Norov wrote: > Hi all, Hi, [adding Dave Miller, netdev, lkml] > On QEMU the next-20170428 hangs on boot for me due to kernel panic in > rtnetlink_init(): > > void __init rtnetlink_init(void) > { > if (register_pernet_subsys(_net_ops)) >

[PATCH] net: ipconfig: fix ic_close_devs() use-after-free

6.720343] == [6.727536] Disabling lock debugging due to kernel taint Signed-off-by: Mark Rutland <mark.rutl...@arm.com> Cc: Alexey Kuznetsov <kuz...@ms2.inr.ac.ru> Cc: David S. Miller <da...@davemloft.net> Cc: Hideaki YOSHIFUJI &

Re: [PATCH V8 1/3] irq: Add flags to request_percpu_irq function

Hi Daniel, On Thu, Mar 23, 2017 at 06:42:01PM +0100, Daniel Lezcano wrote: > In the next changes, we track the interrupts but we discard the timers as > that does not make sense. The next interrupt on a timer is predictable. Sorry, but I could not parse this. [...] > diff --git

[PATCH] SUNRPC: fix include for cmpxhg_relaxed()

include today, but this isn't something we can/should rely upon, especially with ongoing rework of the atomic headers for KASAN instrumentation. Let's fix the code to include , avoiding fragility. Signed-off-by: Mark Rutland <mark.rutl...@arm.com> Cc: Trond Myklebust <tro

Re: amd-xgbe: unbalanced irq enable in v4.11-rc1

On Fri, Mar 10, 2017 at 11:39:42AM -0600, Tom Lendacky wrote: > On 3/10/2017 11:19 AM, Mark Rutland wrote: > >Hi, > > > >I'm seeing the below splat when transferring data over the network, using > >v4.11-rc1 on an AMD Seattle platform. I don't see the splat with v4

amd-xgbe: unbalanced irq enable in v4.11-rc1

Hi, I'm seeing the below splat when transferring data over the network, using v4.11-rc1 on an AMD Seattle platform. I don't see the splat with v4.10. Looking at just the driver, I couldn't see any suspicious changes. Reverting commit 402168b4c2dc0734 ("amd-xgbe: Stop the PHY before releasing

Re: Initializing MAC address at run-time

On Wed, Jan 18, 2017 at 03:03:57PM +0100, Mason wrote: > Hello, > > When my system boots up, eth0 is given a seemingly random MAC address. > > [0.950734] nb8800 26000.ethernet eth0: MAC address ba:de:d6:38:b8:38 > [0.957334] nb8800 26000.ethernet eth0: MAC address 6e:f1:48:de:d6:c4 > >

Re: [PATCH RFC 3/4] dt-bindings: correct marvell orion MDIO binding document

s looks fine to me. Acked-by: Mark Rutland <mark.rutl...@arm.com> Mark. > --- > .../devicetree/bindings/net/marvell-orion-mdio.txt | 17 > +++-- > 1 file changed, 15 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net

[PATCH 2/2] ath9k: ar9003_mac: kill off ACCESS_ONCE()

@ expression E; @@ - ACCESS_ONCE(E) + READ_ONCE(E) Signed-off-by: Mark Rutland <mark.rutl...@arm.com> Cc: ath9k-de...@qca.qualcomm.com Cc: Kalle Valo <kv...@codeaurora.org> Cc: linux-wirel...@vger.kernel.org Cc: ath9k-de...@lists.ath9k.org Cc: netdev@vger.kernel.org --- drivers/

[PATCH 1/2] ath9k: ar9002_mac: kill off ACCESS_ONCE()

@ expression E; @@ - ACCESS_ONCE(E) + READ_ONCE(E) Signed-off-by: Mark Rutland <mark.rutl...@arm.com> Cc: ath9k-de...@qca.qualcomm.com Cc: Kalle Valo <kv...@codeaurora.org> Cc: linux-wirel...@vger.kernel.org Cc: ath9k-de...@lists.ath9k.org Cc: netdev@vger.kernel.org --- drivers/

[PATCH 0/2] ath9k: kill of ACCESS_ONCE() in MAC drivers

) + READ_ONCE(E) Thanks, Mark. Mark Rutland (2): ath9k: ar9002_mac: kill off ACCESS_ONCE() ath9k: ar9003_mac: kill off ACCESS_ONCE() drivers/net/wireless/ath/ath9k/ar9002_mac.c | 64 ++-- drivers/net/wireless/ath/ath9k/ar9003_mac.c | 92 ++--- 2 files

Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()

On Fri, Nov 25, 2016 at 09:52:50AM -0800, Linus Torvalds wrote: > READ/WRITE_ONCE() are atomic *WHEN*THAT*IS*POSSIBLE*. > But sometimes it's not going to be atomic. That's the problem. Common code may rely on something being atomic when that's only true on a subset of platforms. On others, it's

Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()

On Fri, Nov 25, 2016 at 06:28:53PM +0100, Dmitry Vyukov wrote: > On Fri, Nov 25, 2016 at 5:17 PM, Peter Zijlstra wrote: > >> > What are use cases for such primitive that won't be OK with "read once > >> > _and_ atomically"? > >> > >> I have none to hand. > > > > Whatever

Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()

On Fri, Nov 25, 2016 at 05:49:45PM +0100, Christian Borntraeger wrote: > On 11/25/2016 05:17 PM, Peter Zijlstra wrote: > > On Fri, Nov 25, 2016 at 04:10:04PM +0000, Mark Rutland wrote: > >> On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote: > >

Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()

On Fri, Nov 25, 2016 at 05:17:09PM +0100, Peter Zijlstra wrote: > On Fri, Nov 25, 2016 at 04:10:04PM +0000, Mark Rutland wrote: > > On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote: > > > > What are use cases for such primitive that won't be OK with "read o

Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()

On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote: > > READ/WRITE_ONCE imply atomicity. Even if their names don't spell it (a > function name doesn't have to spell all of its guarantees). Most of > the uses of READ/WRITE_ONCE will be broken if they are not atomic. In practice, this

Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()

On Fri, Nov 25, 2016 at 01:40:44PM +0100, Peter Zijlstra wrote: > On Fri, Nov 25, 2016 at 12:23:56PM +0000, Mark Rutland wrote: > > Naming will be problematic; calling them ATOMIC_* makes tham sound like > > they work on atomic_t. That and I have no idea how to ensure correct >

Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()

On Fri, Nov 25, 2016 at 12:33:48PM +0100, Christian Borntraeger wrote: > On 11/25/2016 12:22 PM, Mark Rutland wrote: > > On Thu, Nov 24, 2016 at 10:36:58PM +0200, Michael S. Tsirkin wrote: > >> Though I really question the whole _ONCE APIs esp with > >> aggregate typ

Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()

On Thu, Nov 24, 2016 at 10:36:58PM +0200, Michael S. Tsirkin wrote: > On Thu, Nov 24, 2016 at 10:25:11AM +0000, Mark Rutland wrote: > > For several reasons, it would be beneficial to kill off ACCESS_ONCE() > > tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggre

[PATCH 2/3] vringh: kill off ACCESS_ONCE()

. The userspace tools provide their own definitions in their own . Signed-off-by: Mark Rutland <mark.rutl...@arm.com> Cc: Jason Wang <jasow...@redhat.com> Cc: Michael S. Tsirkin <m...@redhat.com> Cc: k...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: netdev@vger.kernel.o

[PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()

, Mark. Mark Rutland (3): tools/virtio: fix READ_ONCE() vringh: kill off ACCESS_ONCE() tools/virtio: use {READ,WRITE}_ONCE() in uaccess.h drivers/vhost/vringh.c| 5 +++-- tools/virtio/linux/compiler.h | 2 +- tools/virtio/linux/uaccess.h | 9 + 3 files changed, 9 insertions

[PATCH 1/3] tools/virtio: fix READ_ONCE()

regardless. Fixes: a7c490333df3cff5 ("tools/virtio: use virt_xxx barriers") Signed-off-by: Mark Rutland <mark.rutl...@arm.com> Cc: Jason Wang <jasow...@redhat.com> Cc: Michael S. Tsirkin <m...@redhat.com> Cc: linux-ker...@vger.kernel.org Cc: virtualizat...@lists.linux-foun

[PATCH 3/3] tools/virtio: use {READ,WRITE}_ONCE() in uaccess.h

As a step towards killing off ACCESS_ONCE, use {READ,WRITE}_ONCE() for the virtio tools uaccess primitives, pulling these in from . With this done, we can kill off the now-unused ACCESS_ONCE() definition. Signed-off-by: Mark Rutland <mark.rutl...@arm.com> Cc: Jason Wang <jasow...@redha

Re: [PATCH 3/3] net: smsc911x: add u16 workaround for pxa platforms

On Mon, Oct 03, 2016 at 06:11:23PM +0200, Robert Jarzmik wrote: > Mark Rutland <mark.rutl...@arm.com> writes: > > > On Mon, Oct 03, 2016 at 11:05:53AM +0200, Robert Jarzmik wrote: > >> Add a workaround for mainstone, idp and stargate2 boards, for u16 writes > >&

Re: [PATCH 3/3] net: smsc911x: add u16 workaround for pxa platforms

On Mon, Oct 03, 2016 at 05:09:13PM +0100, Russell King - ARM Linux wrote: > Please note that the binding doc for smsc,lan91c111.txt is slightly wrong > on two counts: > > 1) compatible property: > > compatible = "smsc,lan91c111"; > > vs the code: > > static const struct of_device_id

Re: [PATCH 3/3] net: smsc911x: add u16 workaround for pxa platforms

On Mon, Oct 03, 2016 at 11:05:53AM +0200, Robert Jarzmik wrote: > Add a workaround for mainstone, idp and stargate2 boards, for u16 writes > which must be aligned on 32 bits addresses. > > Signed-off-by: Robert Jarzmik > --- >

Re: [v8, 1/7] Documentation: DT: update Freescale DCFG compatible

On Fri, Apr 22, 2016 at 02:27:38PM +0800, Yangbo Lu wrote: > Update Freescale DCFG compatible with 'fsl,-dcfg' instead > of 'fsl,ls1021a-dcfg' to include more chips. > > Signed-off-by: Yangbo Lu > --- > Changes for v8: > - Added this patch > --- >

Re: [PATCH 1/2] drivers: net: xgene: fix: Derive prefetch number from irq

On Tue, Mar 08, 2016 at 09:49:36PM -0800, Iyappan Subramanian wrote: > Prefetch buffer numbers are mapped to hardware irqs. Currently > they are statically assigned to match with firmware irqs. > > If the irq on firmware changes, prefetch buffer number on the driver > also needs to be updated to

Re: KASAN failures in X-Gene ethernet driver in v4.4-rc2

On Wed, Nov 25, 2015 at 08:17:36AM -0800, Eric Dumazet wrote: > On Wed, 2015-11-25 at 15:59 +0000, Mark Rutland wrote: > > xgene_enet_start_xmit > > Please try following trivial fix With that applied KASAN is silent, despite my efforts to trigger the issue, so it looks

KASAN failures in X-Gene ethernet driver in v4.4-rc2

While testing a v4.4-rc2 defconfig + KASAN_INLINE kernel on an X-Gene platform, I spotted the KASAN warnings below. I'm using the Linaro 15.08 little-endian AArch64 GCC [1] to enable KASAN_INLINE. My rootfs is an NFS mount. Most of the time I can trigger the issue by grabbing the kernel source

Re: [PATCH net] bpf, arm: start flushing icache range from header

On Sat, Nov 14, 2015 at 01:26:53AM +0100, Daniel Borkmann wrote: > During review I noticed that the icache range we're flushing should > start at header already and not at ctx.image. > > Reason is that after 55309dd3d4cd ("net: bpf: arm: address randomize > and write protect JIT code"), we also

Re: [PATCH net] bpf, arm: start flushing icache range from header

On Mon, Nov 16, 2015 at 11:40:55AM +, Mark Rutland wrote: > On Sat, Nov 14, 2015 at 01:26:53AM +0100, Daniel Borkmann wrote: > > During review I noticed that the icache range we're flushing should > > start at header already and not at ctx.image. > > > > Reason

Re: [PATCH 2/2] net, thunder, bgx: Add support for ACPI binding.

On Fri, Aug 07, 2015 at 01:33:10AM +0100, David Daney wrote: From: David Daney david.da...@cavium.com Find out which PHYs belong to which BGX instance in the ACPI way. Set the MAC address of the device as provided by ACPI tables. This is similar to the implementation for devicetree in

Re: [PATCH 2/2] net, thunder, bgx: Add support for ACPI binding.

[Correcting the devicetree list address, which I typo'd in my original reply] +static const char * const addr_propnames[] = { + mac-address, + local-mac-address, + address, +}; If these are going to be generally necessary, then we should get them adopted as standardised _DSD

Re: [PATCH 2/2] net, thunder, bgx: Add support for ACPI binding.

[Correcting the devicetree list address, which I typo'd in my original reply] [resending to _really_ correct the address, apologies for the spam] +static const char * const addr_propnames[] = { + mac-address, + local-mac-address, + address, +}; If these are going to be generally