On Mon, Oct 26, 2020 at 03:45:55PM +1100, Michael Ellerman wrote:
> Vitaly Chikunov writes:
> > Adding netdev and PowerPC maintainers JFYI.
>
> Thanks.
>
> > On Sat, Oct 24, 2020 at 11:23:19AM +0300, Dmitry V. Levin wrote:
> >> Hi,
> >>
> >> On Sat, Oct 24, 2020 at 02:06:41AM +0300, Vitaly Chik
On Tue, Mar 30, 2021 at 03:42:35PM +0800, Jianlin Lv wrote:
> A64_MOV is currently mapped to Add Instruction. Architecturally MOV
> (register) is an alias of ORR (shifted register) and MOV (to or from SP)
> is an alias of ADD (immediate).
> This patch redefines A64_MOV and uses existing functionali
---
> include/linux/iommu.h | 2 --
> 2 files changed, 50 deletions(-)
Acked-by: Will Deacon
Will
-
> drivers/iommu/fsl_pamu_domain.c | 30 --
> include/linux/iommu.h | 4
> 2 files changed, 34 deletions(-)
Acked-by: Will Deacon
Will
changed, 5 insertions(+), 68 deletions(-)
Took me a minute to track down the other magic '36' which ends up in
aperture_end, but I found it eventually so:
Acked-by: Will Deacon
(It does make me wonder what all this glue was intended to be used for)
Will
hanged, 10 insertions(+), 24 deletions(-)
Acked-by: Will Deacon
Will
stale ^^
> - struct dma_window *win_arr;
> + struct dma_window win_arr[1];
> /* list of devices associated with the domain */
> struct list_headdevices;
> /* dma_domain states:
Acked-by: Will Deacon
Will
On Tue, Mar 16, 2021 at 04:38:12PM +0100, Christoph Hellwig wrote:
> The only thing that fsl_pamu_window_enable does for the current caller
> is to fill in the prot value in the only dma_window structure, and to
> propagate a few values from the iommu_domain_geometry struture into the
> dma_window.
> 5 files changed, 9 insertions(+), 40 deletions(-)
Heh, this thing is so over-engineered.
Acked-by: Will Deacon
Will
On Tue, Mar 16, 2021 at 04:38:14PM +0100, Christoph Hellwig wrote:
> Merge the two fuctions that configure the ppaace into a single coherent
> function. I somehow doubt we need the two pamu_config_ppaace calls,
> but keep the existing behavior just to be on the safe side.
>
> Signed-off-by: Chris
; 1 file changed, 20 insertions(+), 39 deletions(-)
Acked-by: Will Deacon
Will
sl/qbman/qman_portal.c | 11 ---
> include/linux/iommu.h | 1 -
> 4 files changed, 3 insertions(+), 66 deletions(-)
Acked-by: Will Deacon
Will
nged, 2 insertions(+), 4 deletions(-)
pamu_config_ppaace() takes quite a few useless parameters at this stage,
but anyway:
Acked-by: Will Deacon
Do you know if this driver is actually useful? Once the complexity has been
stripped back, the stubs and default values really stand out.
Will
On Tue, Mar 16, 2021 at 04:38:18PM +0100, Christoph Hellwig wrote:
> DOMAIN_ATTR_PAGING is never used.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Li Yang
> ---
> drivers/iommu/iommu.c | 5 -
> include/linux/iommu.h | 1 -
> 2 files changed, 6 deletions(-
-
> drivers/vfio/vfio_iommu_type1.c | 26 --
> drivers/vhost/vdpa.c| 10 +++---
> include/linux/iommu.h | 1 -
> 4 files changed, 18 insertions(+), 39 deletions(-)
Acked-by: Will Deacon
Will
> 6 files changed, 55 insertions(+), 68 deletions(-)
Acked-by: Will Deacon
Will
On Tue, Mar 16, 2021 at 04:38:21PM +0100, Christoph Hellwig wrote:
> Don't obsfucate the trivial bit flag check.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/iommu/iommu.c | 23 +--
> 1 file changed, 5 insertions(+), 18 deletions(-)
Acked-by: Will Deacon
Will
On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
> From: Robin Murphy
>
> Instead make the global iommu_dma_strict paramete in iommu.c canonical by
> exporting helpers to get and set it and use those directly in the drivers.
>
> This make sure that the iommu.strict parameter al
| 12 -
> 6 files changed, 35 insertions(+), 63 deletions(-)
I'm fine with this for now, although there has been talk about passing
things other than boolean flags as page-table quirks. We can cross that
bridge when we get there, so:
Acked-by: Will Deacon
Will
---
> 2 files changed, 62 deletions(-)
Acked-by: Will Deacon
Will
On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin Murphy wrote:
> On 2021-03-30 14:11, Will Deacon wrote:
> > On Tue, Mar 16, 2021 at 04:38:22PM +0100, Christoph Hellwig wrote:
> > > From: Robin Murphy
> > >
> > > Instead make the global iommu_dma_str
On Wed, Mar 31, 2021 at 05:22:18PM +0800, Jianlin Lv wrote:
> On Tue, Mar 30, 2021 at 5:31 PM Will Deacon wrote:
> >
> > On Tue, Mar 30, 2021 at 03:42:35PM +0800, Jianlin Lv wrote:
> > > A64_MOV is currently mapped to Add Instruction. Architecturally MOV
> > &
On Tue, Mar 30, 2021 at 05:28:19PM +0100, Robin Murphy wrote:
> On 2021-03-30 14:58, Will Deacon wrote:
> > On Tue, Mar 30, 2021 at 02:19:38PM +0100, Robin Murphy wrote:
> > > On 2021-03-30 14:11, Will Deacon wrote:
> > > > On Tue, Mar 16, 2021 at 04:38:22PM
On Wed, Mar 31, 2021 at 02:09:37PM +0100, Robin Murphy wrote:
> On 2021-03-31 12:49, Will Deacon wrote:
> > On Tue, Mar 30, 2021 at 05:28:19PM +0100, Robin Murphy wrote:
> > > On 2021-03-30 14:58, Will Deacon wrote:
> > > > On Tue, Mar 30, 2021 at 02:19:38PM +0100, Ro
On Thu, Apr 01, 2021 at 11:59:45AM +0200, Christoph Hellwig wrote:
> For now I'll just pass the iommu_domain to iommu_get_dma_strict,
> so that we can check for it. We can do additional cleanups on top
> of that later.
Sounds good to me, cheers!
Will
On Tue, Mar 02, 2021 at 10:13:21AM +0100, Daniel Borkmann wrote:
> On 3/2/21 9:05 AM, Björn Töpel wrote:
> > On 2021-03-01 17:10, Toke Høiland-Jørgensen wrote:
> > > Björn Töpel writes:
> > > > From: Björn Töpel
> > > >
> > > > Now that the AF_XDP rings have load-acquire/store-release semantics,
On Thu, Mar 04, 2021 at 03:11:08PM -0800, Rob Clark wrote:
> On Thu, Mar 4, 2021 at 7:48 AM Robin Murphy wrote:
> >
> > On 2021-03-01 08:42, Christoph Hellwig wrote:
> > > Signed-off-by: Christoph Hellwig
> >
> > Moreso than the previous patch, where the feature is at least relatively
> > generic
On Wed, Mar 10, 2021 at 09:58:06AM +0100, Christoph Hellwig wrote:
> On Fri, Mar 05, 2021 at 10:00:12AM +0000, Will Deacon wrote:
> > > But one thing I'm not sure about is whether
> > > IO_PGTABLE_QUIRK_ARM_OUTER_WBWA is something that other devices
> > >
On Fri, Feb 05, 2021 at 09:11:00AM +, Steven Price wrote:
> On 02/02/2021 14:11, Marc Zyngier wrote:
> > diff --git a/drivers/firmware/smccc/kvm_guest.c
> > b/drivers/firmware/smccc/kvm_guest.c
> > new file mode 100644
> > index ..23ce1ded88b4
> > --- /dev/null
> > +++ b/drivers/fi
On Fri, Feb 05, 2021 at 04:50:27PM +, Marc Zyngier wrote:
> On 2021-02-05 11:19, Will Deacon wrote:
> > On Fri, Feb 05, 2021 at 09:11:00AM +, Steven Price wrote:
> > > On 02/02/2021 14:11, Marc Zyngier wrote:
> > > > + for (i = 0; i < 32; ++i) {
&
On Tue, Jul 28, 2020 at 01:07:14AM +, Jianyong Wu wrote:
>
>
> > -Original Message-
> > From: Will Deacon
> > Sent: Monday, July 27, 2020 7:38 PM
> > To: Jianyong Wu
> > Cc: netdev@vger.kernel.org; yangbo...@nxp.com; john.stu...@linar
Hi Alex,
On Tue, Mar 27, 2018 at 10:46:58AM -0400, Sinan Kaya wrote:
> +netdev, +Alex
>
> On 3/26/2018 6:00 PM, Benjamin Herrenschmidt wrote:
> > On Mon, 2018-03-26 at 23:30 +0200, Arnd Bergmann wrote:
> >> Most of the drivers have a unwound loop with writeq() or something to
> >>> do it.
> >>
>
On Wed, Mar 28, 2018 at 05:42:56PM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2018-03-27 at 20:26 -1000, Linus Torvalds wrote:
> > On Tue, Mar 27, 2018 at 6:33 PM, Benjamin Herrenschmidt
> > wrote:
> > >
> > > This is why, I want (with your agreement) to define clearly and once
> > > and for
On Thu, Mar 29, 2018 at 08:31:32AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2018-03-29 at 02:23 +1000, Nicholas Piggin wrote:
> > This is a variation on the mandatory write barrier that causes writes to
> > weakly
> > ordered I/O regions to be partially ordered. Its effects may go beyon
On Thu, May 16, 2019 at 11:14:35AM +0800, Zhangshaokun wrote:
> On 2019/5/15 17:47, Will Deacon wrote:
> > On Mon, Apr 15, 2019 at 07:18:22PM +0100, Robin Murphy wrote:
> >> On 12/04/2019 10:52, Will Deacon wrote:
> >>> I'm waiting for Robin to come back
On Mon, Apr 15, 2019 at 07:18:22PM +0100, Robin Murphy wrote:
> On 12/04/2019 10:52, Will Deacon wrote:
> > I'm waiting for Robin to come back with numbers for a C implementation.
> >
> > Robin -- did you get anywhere with that?
>
> Still not what I would call fin
Hi Linus,
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.
> > So I'm not sure h
Hi again Linus, Alexei,
On Tue, Jan 09, 2018 at 10:21:29AM +, Will Deacon wrote:
> On Mon, Jan 08, 2018 at 10:49:01AM -0800, Linus Torvalds wrote:
> > In this particular case, we should be very much aware of future CPU's
> > being more _constrained_, because CPU vend
On Fri, Apr 12, 2019 at 10:31:16AM +0800, Zhangshaokun wrote:
> On 2019/2/19 7:08, Ard Biesheuvel wrote:
> > It turns out that the IP checksumming code is still exercised often,
> > even though one might expect that modern NICs with checksum offload
> > have no use for it. However, as Lingyan point
On Mon, Sep 14, 2020 at 11:36:21AM +0300, Ilias Apalodimas wrote:
> Running the eBPF test_verifier leads to random errors looking like this:
>
> [ 6525.735488] Unexpected kernel BRK exception at EL1
> [ 6525.735502] Internal error: ptrace BRK handler: f2000100 [#1] SMP
> [ 6525.741609] Modules lin
Hi Ilias,
On Mon, Sep 14, 2020 at 04:23:50PM +0300, Ilias Apalodimas wrote:
> On Mon, Sep 14, 2020 at 03:35:04PM +0300, Ilias Apalodimas wrote:
> > On Mon, Sep 14, 2020 at 01:20:43PM +0100, Will Deacon wrote:
> > > On Mon, Sep 14, 2020 at 11:36:21AM +0300, Ilias Apalodimas wrot
Hi Ilias,
On Mon, Sep 14, 2020 at 07:03:55PM +0300, Ilias Apalodimas wrote:
> Running the eBPF test_verifier leads to random errors looking like this:
>
> [ 6525.735488] Unexpected kernel BRK exception at EL1
> [ 6525.735502] Internal error: ptrace BRK handler: f2000100 [#1] SMP
Does this happen
On Tue, Sep 15, 2020 at 04:53:44PM +0300, Ilias Apalodimas wrote:
> On Tue, Sep 15, 2020 at 02:11:03PM +0100, Will Deacon wrote:
> > Hi Ilias,
> >
> > On Mon, Sep 14, 2020 at 07:03:55PM +0300, Ilias Apalodimas wrote:
> > > Running the eBPF test_verifier leads to r
On Tue, Oct 06, 2020 at 01:08:23AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:549738f1 Linux 5.9-rc8
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15b97ba390
> kernel config: https://syzkaller.appspot.co
On Mon, Jul 27, 2020 at 03:45:37AM +, Jianyong Wu wrote:
> > From: Will Deacon
> >
> > We can advertise ourselves to guests as KVM and provide a basic features
> > bitmap for discoverability of future hypervisor services.
> >
> > Cc: Marc Zyngier
> &
ing the arm instruction offsets.
>
> Fixes: 2589726d12a1 ("bpf: introduce bounded loops")
> Reported-by: Naresh Kamboju
> Reported-by: Jiri Olsa
> Co-developed-by: Jean-Philippe Brucker
> Signed-off-by: Jean-Philippe Brucker
> Co-developed-by: Yauheni Kaliuta
> Signed-off-by: Yauheni Kaliuta
> Signed-off-by: Ilias Apalodimas
Acked-by: Will Deacon
Catalin -- do you want to take this as a fix?
Will
Hi Will, Pablo,
On Tue, Aug 04, 2020 at 01:37:11PM +0200, Pablo Neira Ayuso wrote:
> This patch is much smaller and if you confirm this is address the
> issue, then this is awesome.
Did that ever get confirmed? AFAICT, nothing ended up landing in the stable
trees for this.
Cheers,
Will
> On M
On Thu, Oct 18, 2018 at 08:53:42PM -0700, Alexei Starovoitov wrote:
> On Thu, Oct 18, 2018 at 09:00:46PM +0200, Daniel Borkmann wrote:
> > On 10/18/2018 05:33 PM, Alexei Starovoitov wrote:
> > > On Thu, Oct 18, 2018 at 05:04:34PM +0200, Daniel Borkmann wrote:
> > >> #endif /* _TOOLS_LINUX_ASM_IA64
Hi Alexei,
On Mon, Jan 28, 2019 at 01:56:24PM -0800, Alexei Starovoitov wrote:
> On Mon, Jan 28, 2019 at 10:24:08AM +0100, Peter Zijlstra wrote:
> > On Fri, Jan 25, 2019 at 04:17:26PM -0800, Alexei Starovoitov wrote:
> > > What I want to avoid is to define the whole execution ordering model
> > >
On Wed, Jan 02, 2019 at 03:57:54PM -0500, Michael S. Tsirkin wrote:
> We don't really care whether the variable is in-register
> or in-memory. Relax the constraint accordingly.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> include/linux/compiler.h | 2 +-
> 1 file changed, 1 insertion(+), 1 dele
On Tue, Nov 27, 2018 at 05:21:08PM -0800, Nadav Amit wrote:
> > On Nov 27, 2018, at 5:06 PM, Nadav Amit wrote:
> >
> >> On Nov 27, 2018, at 4:07 PM, Rick Edgecombe
> >> wrote:
> >>
> >> Sometimes when memory is freed via the module subsystem, an executable
> >> permissioned TLB entry can remai
On Fri, Nov 23, 2018 at 11:18:04PM +0100, Ard Biesheuvel wrote:
> The arm64 module region is a 128 MB region that is kept close to
> the core kernel, in order to ensure that relative branches are
> always in range. So using the same region for programs that do
> not have this restriction is wastefu
On Fri, Nov 30, 2018 at 08:20:06PM +0100, Ard Biesheuvel wrote:
> On Fri, 30 Nov 2018 at 19:26, Will Deacon wrote:
> >
> > On Fri, Nov 23, 2018 at 11:18:04PM +0100, Ard Biesheuvel wrote:
> > > The arm64 module region is a 128 MB region that is kept close to
> >
On Mon, Dec 03, 2018 at 05:43:11PM -0800, Nadav Amit wrote:
> > On Nov 27, 2018, at 4:07 PM, Rick Edgecombe
> > wrote:
> >
> > Since vfree will lazily flush the TLB, but not lazily free the underlying
> > pages,
> > it often leaves stale TLB entries to freed pages that could get re-used.
> > T
On Tue, Dec 04, 2018 at 12:09:49PM -0800, Andy Lutomirski wrote:
> On Tue, Dec 4, 2018 at 12:02 PM Edgecombe, Rick P
> wrote:
> >
> > On Tue, 2018-12-04 at 16:03 +, Will Deacon wrote:
> > > On Mon, Dec 03, 2018 at 05:43:11PM -0800, Nadav Amit wrote:
> > > &
On Wed, Dec 05, 2018 at 01:24:17PM +0100, Daniel Borkmann wrote:
> On 12/04/2018 04:45 PM, Ard Biesheuvel wrote:
> > On Mon, 3 Dec 2018 at 13:49, Will Deacon wrote:
> >> On Fri, Nov 30, 2018 at 08:20:06PM +0100, Ard Biesheuvel wrote:
> >>> On Fri, 30 Nov 201
On Thu, Dec 06, 2018 at 08:29:03AM +0100, Ard Biesheuvel wrote:
> On Thu, 6 Dec 2018 at 00:16, Andy Lutomirski wrote:
> >
> > On Wed, Dec 5, 2018 at 3:41 AM Will Deacon wrote:
> > >
> > > On Tue, Dec 04, 2018 at 12:09:49PM -0800, Andy Lutomirski wrote:
> &
On Thu, Dec 06, 2018 at 08:23:20PM +0100, Ard Biesheuvel wrote:
> On Thu, 6 Dec 2018 at 20:21, Andy Lutomirski wrote:
> >
> > On Thu, Dec 6, 2018 at 11:04 AM Ard Biesheuvel
> > wrote:
> > >
> > > On Thu, 6 Dec 2018 at 19:54, Andy Lutomirski wrote:
> > > >
> >
> > > > That’s not totally nuts. Do
On Thu, Oct 04, 2018 at 07:43:59PM +0200, Ard Biesheuvel wrote:
> (+ Arnd, Russell, Catalin, Will)
>
> On 4 October 2018 at 19:36, Ben Hutchings
> wrote:
> > NET_IP_ALIGN is supposed to be defined as 0 if DMA writes to an
> > unaligned buffer would be more expensive than CPU access to unaligned
Hi Greentime,
On Wed, Nov 08, 2017 at 01:54:59PM +0800, Greentime Hu wrote:
> From: Greentime Hu
>
> Signed-off-by: Vincent Chen
> Signed-off-by: Greentime Hu
> ---
> arch/nds32/include/asm/futex.h| 116
> arch/nds32/include/asm/spinlock.h | 178
> +
On Thu, May 07, 2020 at 02:48:07PM -0700, Luke Nelson wrote:
> Thanks for the comments! Responses below:
>
> > It's a bit grotty spreading the checks out now. How about we tweak things
> > slightly along the lines of:
> >
> >
> > diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
> >
On Fri, 8 May 2020 11:15:43 -0700, Luke Nelson wrote:
> This patch series introduces several optimizations to the arm64 BPF JIT.
> The optimizations make use of arm64 immediate instructions to avoid
> loading BPF immediates to temporary registers, when possible.
>
> In the process, we discovered t
On Sat, Jun 06, 2020 at 07:03:03AM -0700, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 13dc4d836179444f0ca90188cfccd23f9cd9ff05
> Author: Will Deacon
> Date: Tue Apr 21 14:29:18 2020 +
>
> arm64: cpufeature: Remove redundant call to
Hi Luke,
Thanks for the patches.
On Wed, May 06, 2020 at 06:05:01PM -0700, Luke Nelson wrote:
> This patch fixes two issues present in the current function for encoding
> arm64 logical immediates when using the 32-bit variants of instructions.
>
> First, the code does not correctly reject an all
> definitions from core code.
>
> Signed-off-by: Paul E. McKenney
> Cc: Arnd Bergmann
> Cc: Ingo Molnar
> Cc: Will Deacon
> Cc: Peter Zijlstra
> Cc: Alan Stern
> Cc: Andrea Parri
> Cc: Linus Torvalds
> ---
> include/asm-generic/qspinlock.h |
arch-specific
> arch_spin_unlock_wait().
>
> Signed-off-by: Paul E. McKenney
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc:
> Cc: Peter Zijlstra
> Cc: Alan Stern
> Cc: Andrea Parri
> Cc: Linus Torvalds
> ---
> arch/arm64/include/asm/spinlock.h | 58
> ---
On Fri, Jun 30, 2017 at 05:38:15AM -0700, Paul E. McKenney wrote:
> On Fri, Jun 30, 2017 at 10:19:29AM +0100, Will Deacon wrote:
> > On Thu, Jun 29, 2017 at 05:01:16PM -0700, Paul E. McKenney wrote:
> > > There is no agreed-upon definition of spin_unlock_wait()'s semantic
On Fri, Jun 30, 2017 at 03:18:40PM -0700, Paul E. McKenney wrote:
> On Fri, Jun 30, 2017 at 02:13:39PM +0100, Will Deacon wrote:
> > On Fri, Jun 30, 2017 at 05:38:15AM -0700, Paul E. McKenney wrote:
> > > I also need to check all uses of spin_is_locked(). There might no
> &
On Mon, Jul 03, 2017 at 09:40:22AM -0700, Linus Torvalds wrote:
> On Mon, Jul 3, 2017 at 9:18 AM, Paul E. McKenney
> wrote:
> >
> > Agreed, and my next step is to look at spin_lock() followed by
> > spin_is_locked(), not necessarily the same lock.
>
> Hmm. Most (all?) "spin_is_locked()" really sh
On Thu, Jul 06, 2017 at 06:50:36PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 06, 2017 at 09:20:24AM -0700, Paul E. McKenney wrote:
> > On Thu, Jul 06, 2017 at 06:05:55PM +0200, Peter Zijlstra wrote:
> > > On Thu, Jul 06, 2017 at 02:12:24PM +, David Laight wrote:
> > > > From: Paul E. McKenney
Hi all,
On Wed, Jan 10, 2018 at 07:47:33PM +, Will Deacon wrote:
> On Tue, Jan 09, 2018 at 10:21:29AM +0000, Will Deacon wrote:
> > On Mon, Jan 08, 2018 at 10:49:01AM -0800, Linus Torvalds wrote:
> > > In this particular case, we should be very much aware of future CPU&
Hi Dan, Linus,
On Thu, Jan 11, 2018 at 05:41:08PM -0800, Dan Williams wrote:
> On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds
> wrote:
> > On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams
> > wrote:
> >>
> >> This series incorporates Mark Rutland's latest ARM changes and adds
> >> the x86 specifi
On Thu, Jan 18, 2018 at 08:58:08AM -0800, Dan Williams wrote:
> On Thu, Jan 18, 2018 at 5:18 AM, Will Deacon wrote:
> > On Thu, Jan 11, 2018 at 05:41:08PM -0800, Dan Williams wrote:
> >> On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds
> >> wrote:
> >> &g
1 file changed, 3 insertions(+), 3 deletions(-)
Thanks, this fixes a boot-time crash (below) when bringing up the interface
on my xgene board with -rc3, so:
Tested-by: Will Deacon
Will
--->8
[8.076583] synchronous external abort: synchronous external abort
(0x9610) at 0x0a
Hi Daniel,
[sorry, only just noticed that was queued]
On Mon, May 01, 2017 at 02:57:20AM +0200, Daniel Borkmann wrote:
> This work adds BPF_XADD for BPF_W/BPF_DW to the arm64 JIT and therefore
> completes JITing of all BPF instructions, meaning we can thus also remove
> the 'notyet' label and do
048: 35ac cbnz w12, 0x003c
> [...]
>
> [1] https://static.docs.arm.com/ddi0487/b/DDI0487B_a_armv8_arm.pdf, p.6132
>
> Fixes: 85f68fe89832 ("bpf, arm64: implement jiting of BPF_XADD")
> Reported-by: Will Deacon
> Signed-off-by: Daniel Borkmann
> --
On Thu, Oct 19, 2017 at 10:34:54PM -0700, Eric Dumazet wrote:
> On Thu, Oct 19, 2017 at 8:13 PM, Wei Wei wrote:
> > Code: f9406680 8b01 91009000 f9800011 (885f7c01)
> > All code
> >
> >0: 80 66 40 f9 andb $0xf9,0x40(%rsi)
> >4: 00 00 add
On Thu, May 12, 2016 at 11:37:58PM -0700, Zi Shen Lim wrote:
> Original implementation commit e54bcde3d69d ("arm64: eBPF JIT compiler")
> had the relevant code paths, but due to an oversight always fail jiting.
>
> As a result, we had been falling back to BPF interpreter whenever a BPF
> program h
On Fri, May 13, 2016 at 10:57:18AM +0100, Will Deacon wrote:
> On Thu, May 12, 2016 at 11:37:58PM -0700, Zi Shen Lim wrote:
> > Original implementation commit e54bcde3d69d ("arm64: eBPF JIT compiler")
> > had the relevant code paths, but due to an oversight always fail jit
On Sat, Jun 04, 2016 at 03:00:29PM -0700, Zi Shen Lim wrote:
> Remove superfluous stack frame, saving us 3 instructions for
> every JMP_CALL.
>
> Signed-off-by: Zi Shen Lim
> ---
> arch/arm64/net/bpf_jit_comp.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/arm64/net/bpf_jit_co
On Mon, Jun 06, 2016 at 09:36:03PM -0700, Z Lim wrote:
> On Mon, Jun 6, 2016 at 10:05 AM, Will Deacon wrote:
> > On Sat, Jun 04, 2016 at 03:00:29PM -0700, Zi Shen Lim wrote:
> >> Remove superfluous stack frame, saving us 3 instructions for
> >> every JMP_CALL.
> >
On Wed, Apr 19, 2017 at 02:46:19PM +, Gabriele Paoloni wrote:
> > From: Amir Ancel [mailto:am...@mellanox.com]
> > Sent: 18 April 2017 21:18
> > To: David Laight; Gabriele Paoloni; da...@davemloft.net
> > Cc: Catalin Marinas; Will Deacon; Mark Rutland; Robin Mu
e is renamed.
>
> Reported-by: Will Deacon
> Signed-off-by: Jeremy Linton
> ---
> drivers/net/ethernet/smsc/smsc911x.c | 47
> ++--
> 1 file changed, 18 insertions(+), 29 deletions(-)
FWIW, this fixes the interface naming under /proc//ethX for me:
Tested-by: Will Deacon
Will
On Tue, Dec 01, 2015 at 02:20:40PM -0800, Shi, Yang wrote:
> On 11/30/2015 2:24 PM, Yang Shi wrote:
> >aarch64 doesn't have native store immediate instruction, such operation
> >has to be implemented by the below instruction sequence:
> >
> >Load immediate to register
> >Store register
> >
> >Signe
On Wed, Nov 11, 2015 at 09:49:48AM +0100, Arnd Bergmann wrote:
> On Tuesday 10 November 2015 18:52:45 Z Lim wrote:
> > On Tue, Nov 10, 2015 at 4:42 PM, Alexei Starovoitov
> > wrote:
> > > On Tue, Nov 10, 2015 at 04:26:02PM -0800, Shi, Yang wrote:
> > >> On 11/10/2015 4:08 PM, Eric Dumazet wrote:
>
Hi Daniel,
On Wed, Nov 11, 2015 at 11:42:11AM +0100, Daniel Borkmann wrote:
> On 11/11/2015 11:24 AM, Will Deacon wrote:
> >On Wed, Nov 11, 2015 at 09:49:48AM +0100, Arnd Bergmann wrote:
> >>On Tuesday 10 November 2015 18:52:45 Z Lim wrote:
> >>>On Tue, Nov 10, 2015
On Tue, Nov 10, 2015 at 06:45:39PM -0800, Z Lim wrote:
> On Tue, Nov 10, 2015 at 2:41 PM, Yang Shi wrote:
> > aarch64 doesn't have native store immediate instruction, such operation
>
> Actually, aarch64 does have "STR (immediate)". For arm64 JIT, we can
> consider using it as an optimization.
Y
On Wed, Nov 11, 2015 at 01:21:04PM +0100, Daniel Borkmann wrote:
> On 11/11/2015 12:58 PM, Will Deacon wrote:
> >On Wed, Nov 11, 2015 at 11:42:11AM +0100, Daniel Borkmann wrote:
> >>On 11/11/2015 11:24 AM, Will Deacon wrote:
> >>>On Wed, Nov 11, 2015 at 09:49:4
On Wed, Nov 11, 2015 at 12:12:56PM +, Will Deacon wrote:
> On Tue, Nov 10, 2015 at 06:45:39PM -0800, Z Lim wrote:
> > On Tue, Nov 10, 2015 at 2:41 PM, Yang Shi wrote:
> > > aarch64 doesn't have native store immediate instruction, such operation
> >
> &g
Hi Daniel,
Thanks for investigating this further.
On Wed, Nov 11, 2015 at 04:52:00PM +0100, Daniel Borkmann wrote:
> I played a bit around with eBPF code to assign the __sync_fetch_and_add()
> return value to a var and dump it to trace pipe, or use it as return code.
> llvm compiles it (with the
On Wed, Nov 11, 2015 at 12:35:48PM -0500, David Miller wrote:
> From: Alexei Starovoitov
> Date: Wed, 11 Nov 2015 09:27:00 -0800
>
> > BPF_XADD == atomic_add() in kernel. period.
> > we are not going to deprecate it or introduce something else.
>
> Agreed, it makes no sense to try and tie C99 or
On Wed, Nov 11, 2015 at 10:11:33AM -0800, Alexei Starovoitov wrote:
> On Wed, Nov 11, 2015 at 06:57:41PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 11, 2015 at 12:35:48PM -0500, David Miller wrote:
> > > From: Alexei Starovoitov
> > > Date: Wed, 11 Nov 2015 09:27:00 -0800
> > >
> > > > BPF_XADD
Hi Arnd,
On Tue, Nov 17, 2015 at 09:57:30AM +0100, Arnd Bergmann wrote:
> On Monday 16 November 2015 19:05:05 Olof's autobuilder wrote:
> >
> > Errors:
> >
> > arm64.allmodconfig:
> > arch/arm64/include/asm/barrier.h:71:3: error: read-only variable '___p1'
> > used as 'asm' output
> > a
On Tue, Nov 17, 2015 at 06:03:40PM +0100, Arnd Bergmann wrote:
> On Tuesday 17 November 2015 16:44:53 Will Deacon wrote:
> > > 8<
> > > Subject: ARM64: make smp_load_acquire() work with const arguments
> > >
> > > smp_load_acquire() use
On Tue, Nov 17, 2015 at 08:17:17PM +0100, Arnd Bergmann wrote:
> On Tuesday 17 November 2015 17:12:37 Will Deacon wrote:
> > On Tue, Nov 17, 2015 at 06:03:40PM +0100, Arnd Bergmann wrote:
> > > On Tuesday 17 November 2015 16:44:53 Will Deacon wrote:
> > > > > 8<
On Wed, Nov 18, 2015 at 12:11:25PM +, David Laight wrote:
> From: Will Deacon
> > Sent: 18 November 2015 10:14
> > On Tue, Nov 17, 2015 at 08:17:17PM +0100, Arnd Bergmann wrote:
> > > On Tuesday 17 November 2015 17:12:37 Will Deacon wrote:
> > > > On Tue, No
On Wed, Nov 18, 2015 at 03:21:19PM +, David Laight wrote:
> From: Will Deacon
> > Sent: 18 November 2015 12:28
> > On Wed, Nov 18, 2015 at 12:11:25PM +, David Laight wrote:
> > > From: Will Deacon
> > > >
> > > > http://lists.infradead.org
PARC) || defined (CONFIG_PARISC) || defined(CONFIG_ARM)
> i |= 0x4800;
> #else
> -#warning Processor architecture undefined
> + dev_warn(&dev->dev, "unknown CPU architecture, using default csr0
> setting\n");
> i |= 0x4800;
Then we could print the
98 matches
Mail list logo
