On Tue, Jan 26, 2021 at 11:00:05AM -0600, Bjorn Andersson wrote:
> On Tue 26 Jan 10:21 CST 2021, Mark Rutland wrote:
>
> > On Tue, Jan 26, 2021 at 02:58:33PM +, Matthew Wilcox wrote:
> > > On Tue, Jan 26, 2021 at 10:47:34AM +, Mark Rutland wrote:
> > > >
On Tue, Jan 26, 2021 at 02:58:33PM +, Matthew Wilcox wrote:
> On Tue, Jan 26, 2021 at 10:47:34AM +0000, Mark Rutland wrote:
> > Hi,
> >
> > When fuzzing arm64 with Syzkaller, I'm seeing some splats where
> > this_cpu_ptr() is used in the
Hi,
When fuzzing arm64 with Syzkaller, I'm seeing some splats where
this_cpu_ptr() is used in the bowels of idr_alloc(), by way of
radix_tree_node_alloc(), in a preemptible context:
| BUG: using smp_processor_id() in preemptible [] code:
syz-executor.1/32582
| caller is debug_smp_process
On Fri, Dec 04, 2020 at 12:54:29AM +, Alex Belits wrote:
>
> On Wed, 2020-12-02 at 14:20 +, Mark Rutland wrote:
> > External Email
> >
> > ---
> > ---
> > On Mon, Nov 23, 2020 at
On Fri, Dec 04, 2020 at 12:37:32AM +, Alex Belits wrote:
> On Wed, 2020-12-02 at 13:59 +0000, Mark Rutland wrote:
> > On Mon, Nov 23, 2020 at 05:58:06PM +, Alex Belits wrote:
> > As a heads-up, the arm64 entry code is changing, as we found that
> > our lockdep, RCU,
On Mon, Nov 23, 2020 at 05:58:22PM +, Alex Belits wrote:
> From: Yuri Norov
>
> For nohz_full CPUs the desirable behavior is to receive interrupts
> generated by tick_nohz_full_kick_cpu(). But for hard isolation it's
> obviously not desirable because it breaks isolation.
>
> This patch adds
On Mon, Nov 23, 2020 at 05:57:42PM +, Alex Belits wrote:
> Some drivers don't call functions that call
> task_isolation_kernel_enter() in interrupt handlers. Call it
> directly.
I don't think putting this in drivers is the right approach. IIUC we
only need to track user<->kernel transitions, a
On Tue, Nov 24, 2020 at 05:40:49PM +, Alex Belits wrote:
>
> On Tue, 2020-11-24 at 08:36 -0800, Tom Rix wrote:
> > External Email
> >
> > ---
> > ---
> >
> > On 11/23/20 9:42 AM, Alex Belits wrote:
> > > This is an update of tas
Hi Alex,
On Mon, Nov 23, 2020 at 05:58:06PM +, Alex Belits wrote:
> In do_notify_resume(), call task_isolation_before_pending_work_check()
> first, to report isolation breaking, then after handling all pending
> work, call task_isolation_start() for TIF_TASK_ISOLATION tasks.
>
> Add _TIF_TASK
On Tue, Apr 28, 2020 at 07:14:52AM +0100, Jianyong Wu wrote:
> On 2020/4/24 6:39 PM, Mark Rutland wrote:
> > On Fri, Apr 24, 2020 at 03:50:22AM +0100, Jianyong Wu wrote:
> >> On 2020/4/21 5:57 PM, Mark Rutland wrote:
> >>> On Tue, Apr 21, 2020 at 11:23:00AM +0800,
On Mon, May 13, 2019 at 10:20:19AM -0700, 'Eric Dumazet' via syzkaller wrote:
> On Mon, May 13, 2019 at 10:17 AM Mark Rutland wrote:
> >
> > On Mon, May 13, 2019 at 09:38:55AM -0700, 'Eric Dumazet' via syzkaller
> > wrote:
> > > Various thin
On Mon, May 13, 2019 at 09:38:55AM -0700, 'Eric Dumazet' via syzkaller wrote:
> Various things in eBPF really require us to disable preemption
> before running an eBPF program.
Is that true for all eBPF uses? I note that we don't disable preemption
in the lib/test_bpf.c module, for example.
If it
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
> >> bug
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
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 use
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
Cc: Alexei Starovoitov
Cc: Dan Carpenter
Cc: Daniel Borkmann
Cc: Peter Zijl
itive
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
Cc: Trond Myklebust
Cc: Anna Schumaker
Cc: J. Bruce F
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 of
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(), a
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
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
>
> Sorry, I have sent th
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
bou
On Mon, Jan 08, 2018 at 10:49:01AM -0800, Linus Torvalds wrote:
> On Mon, Jan 8, 2018 at 9:05 AM, Mark Rutland wrote:
> >
> > I'm a little worried that in the presence of some CPU/compiler
> > optimisations, the masking may effectively be skipped under speculation.
>
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 nice if the document were do
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, providing a primitive
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, hi)
> >>
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, providing a primitive
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
> Signed-off-by: Jassi Brar
> ---
> .../devicetree/bindi
On Fri, Dec 08, 2017 at 07:54:42PM +0800, Greentime Hu wrote:
> 2017-12-08 18:21 GMT+08:00 Mark Rutland :
> > On Fri, Dec 08, 2017 at 05:12:00PM +0800, Greentime Hu wrote:
> >> +static int grab_timer_node_info(void)
> >> +{
> >> + struct device_node *time
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 = <&clk_pll>;
> + clock-names = "apb_pc
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 = <&clk_pll>;
> + clock-names = "apb_pcl
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 grab_timer_node_info(void)
> +{
> + s
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->lock)
> +
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
> + *
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
> Signed-off-by: Greentime Hu
> ---
> Documentation/devicetree/binding
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 cra
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 m
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
> > le
On Mon, Oct 02, 2017 at 10:27:15AM -0700, Eric Dumazet wrote:
> On Mon, Oct 2, 2017 at 10:21 AM, Mark Rutland wrote:
> > 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
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
> 681e33998e
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 Syzk
On Mon, Oct 02, 2017 at 07:42:17AM -0700, Eric Dumazet wrote:
> On Mon, Oct 2, 2017 at 7:21 AM, Mark Rutland wrote:
> > Just to check I've understood correctly, are you suggesting that the
> > IPv4 code should also check the dev->mtu against a IP_MIN_MTU (which
> >
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 wrote:
> > 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
> > s
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
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 opportu
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
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 splat
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(&rtnetlink_net_
b
fb
[6.720343]
==
[6.727536] Disabling lock debugging due to kernel taint
Signed-off-by: Mark Rutland
Cc: Alexey Kuznetsov
Cc: David S. Miller
Cc: Hideaki YOSHIFUJI
Cc: James Morris
Cc: Patrick McHardy
Cc: netdev@vger.kernel.org
---
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 a/drivers/perf/
itive
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
Cc: Trond Myklebust
Cc: Anna Schumaker
Cc: J. Bruce F
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 w
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 inte
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
>
>
On Sat, Jan 07, 2017 at 11:28:30AM +, Russell King wrote:
> Correct the Marvell Orion MDIO binding document to properly reflect the
> cases where an interrupt is present. Augment the examples to show this.
>
> Signed-off-by: Russell King
This looks fine to me.
Acked-by:
epends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
Signed-off-by: Mark Rutland
Cc: ath9k-de...@qca.qualcomm.com
Cc: Kalle Valo
Cc: linux-wirel...@vger.kernel.org
Cc: ath9k-de...@lists.ath9k.org
Cc: netdev@vger.kernel.org
---
drivers/net/wireless/ath/ath9k/ar
epends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
Signed-off-by: Mark Rutland
Cc: ath9k-de...@qca.qualcomm.com
Cc: Kalle Valo
Cc: linux-wirel...@vger.kernel.org
Cc: ath9k-de...@lists.ath9k.org
Cc: netdev@vger.kernel.org
---
drivers/net/wireless/ath/ath9k/ar
NCE(E)
+ 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
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
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 triggers the __builtin_mem
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:
> >
> >
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 "r
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 is
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
>
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 types
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
. The userspace tools provide their own definitions in
their own .
Signed-off-by: Mark Rutland
Cc: Jason Wang
Cc: Michael S. Tsirkin
Cc: k...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/vhost/vringh.c | 5
hanks,
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 inser
al/, making READ_ONCE() work as expected regardless.
Fixes: a7c490333df3cff5 ("tools/virtio: use virt_xxx barriers")
Signed-off-by: Mark Rutland
Cc: Jason Wang
Cc: Michael S. Tsirkin
Cc: linux-ker...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
---
tools/virtio/linux/co
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
Cc: Jason Wang
Cc: Michael S. Tsirkin
Cc: linux-ker
On Mon, Oct 03, 2016 at 06:11:23PM +0200, Robert Jarzmik wrote:
> Mark Rutland 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
> >> which must b
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 smc91x_matc
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
> ---
> Documentation/devicetree/bindings/net/smsc911x.txt | 2 ++
> 1 file c
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
> ---
> Documentation/devicetree/bindings/arm/fsl.
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 m
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 lik
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
tar
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.
> >
> > R
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 wa
[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 a
[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
> > adopt
On Fri, Aug 07, 2015 at 01:33:10AM +0100, David Daney wrote:
> From: David Daney
>
> 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
> of_get_mac_address(
82 matches
Mail list logo
