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 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 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 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 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
---
> 2 files changed, 62 deletions(-)
Acked-by: Will Deacon
Will
| 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
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
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
> 6 files changed, 55 insertions(+), 68 deletions(-)
Acked-by: Will Deacon
Will
-
> 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
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(-
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
sl/qbman/qman_portal.c | 11 ---
> include/linux/iommu.h | 1 -
> 4 files changed, 3 insertions(+), 66 deletions(-)
Acked-by: Will Deacon
Will
; 1 file changed, 20 insertions(+), 39 deletions(-)
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
> 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: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.
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
hanged, 10 insertions(+), 24 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
-
> drivers/iommu/fsl_pamu_domain.c | 30 --
> include/linux/iommu.h | 4
> 2 files changed, 34 deletions(-)
Acked-by: Will Deacon
Will
---
> include/linux/iommu.h | 2 --
> 2 files changed, 50 deletions(-)
Acked-by: Will Deacon
Will
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
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 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 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 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 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 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, 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
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
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
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
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
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 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 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
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
> &
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
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 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
> >
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
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
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
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 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, 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 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 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 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 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 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 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 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
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
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 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
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.
> >>
>
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&
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
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
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
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 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, 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
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
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
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 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 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
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
> ---
> 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 |
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
> --
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
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 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 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 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 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 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
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
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
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 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 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
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 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
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
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: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
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 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
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 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:
>
98 matches
Mail list logo
