On Tue, Apr 13, 2021 at 04:52:34PM +, Liam Howlett wrote:
> * Catalin Marinas [210412 13:44]:
> > On Wed, Apr 07, 2021 at 03:11:06PM +, Liam Howlett wrote:
> > > find_vma() will continue to search upwards until the end of the virtual
> > > memory space. T
On Wed, Apr 07, 2021 at 03:11:06PM +, Liam Howlett wrote:
> find_vma() will continue to search upwards until the end of the virtual
> memory space. This means the si_code would almost never be set to
> SEGV_MAPERR even when the address falls outside of any VMA. The result
> is that the si_cod
On Tue, Feb 16, 2021 at 06:50:20PM +0100, Jason A. Donenfeld wrote:
> On Tue, Feb 16, 2021 at 6:46 PM Jason A. Donenfeld wrote:
> > On Tue, Feb 16, 2021 at 6:28 PM Catalin Marinas
> > wrote:
> > > > hlist_add_head include/linux/list.h:883 [inline]
> > > &g
On Mon, 28 Dec 2020 15:05:08 +0800, Tian Tao wrote:
> asm/exception.h is included more than once. Remove the one that isn't
> necessary.
Applied to arm64 (for-next/fixes), thanks!
[1/1] arm64: traps: remove duplicate include statement
https://git.kernel.org/arm64/c/3fb6819f411b
--
Catalin
On Thu, 17 Sep 2020 11:49:25 +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 linked in
they
> pass only counts elapsed time, not time since the epoch. They
> will be dealt with later.
>
> Signed-off-by: Arnd Bergmann
Acked-by: Catalin Marinas
(as long as compat follows the arm32 syscall numbers)
uching the 32-bit architectures twice.
>
> Signed-off-by: Arnd Bergmann
For arm64:
Acked-by: Catalin Marinas
NR_migrate_pages 400
> __SYSCALL(__NR_migrate_pages, compat_sys_migrate_pages)
> +#define __NR_kexec_file_load 401
> +__SYSCALL(__NR_kexec_file_load, sys_kexec_file_load)
For arm64:
Acked-by: Catalin Marinas
n 64-bit kernels, so that argument is no
> longer very strong.
>
> Assigning the number lets us use the system call on 64-bit kernels as well
> as providing a more consistent set of syscalls across architectures.
>
> Signed-off-by: Arnd Bergmann
For the arm64 part:
Acked-by: Catalin Marinas
On Fri, Jan 11, 2019 at 07:26:09AM +0300, Konstantin Khlebnikov wrote:
> On Thu, Jan 10, 2019 at 11:45 PM Cong Wang wrote:
> > On Tue, Jan 8, 2019 at 1:30 AM Konstantin Khlebnikov
> > wrote:
> > > @@ -443,12 +444,14 @@ static struct neigh_hash_table
> > > *neigh_hash_alloc(unsigned int shift)
>
hit a similar issue on
arm64 but didn't get the chance to fix it (also at LPC). With a proper
commit message, feel free to add:
Reviewed-by: Catalin Marinas
_not_leak(skb);
Nitpick: I would add a short comment above the kmemleak_not_leak() calls
on why there is a false positive. Otherwise:
Acked-by: Catalin Marinas
On Tue, May 17, 2016 at 09:12:34AM +0200, Daniel Borkmann wrote:
> On 05/17/2016 09:03 AM, Geert Uytterhoeven wrote:
> [...]
> >Someone's not gonna be happy with commit 606b5908 ("bpf: split
> >HAVE_BPF_JIT into cBPF and eBPF variant") breaking the sort order again...
>
> Wasn't aware of that.
> CC: Daniel Borkmann
> Acked-by: Zi Shen Lim
> Signed-off-by: Yang Shi
Acked-by: Catalin Marinas
On Thu, Sep 24, 2015 at 07:10:38PM +0100, David Woodhouse wrote:
> On Thu, 2015-09-24 at 16:15 +0100, Catalin Marinas wrote:
> > With "PRP0001", they can skip the _DSD properties review process (not
> > that they bother much currently) as long as the existing DT suppo
On Thu, Sep 24, 2015 at 12:52:38PM +0100, David Woodhouse wrote:
> On Thu, 2015-09-24 at 11:31 +0100, Catalin Marinas wrote:
> > PRP0001 opens the door to any DT-like properties in ACPI and, knowing
> > how the ARM ecosystem works, I'm pretty sure we'll soon lose control (
Hi Dave,
On Thu, Sep 24, 2015 at 09:16:19AM +0100, David Woodhouse wrote:
> On Wed, 2015-09-23 at 16:56 -0700, Hanjun Guo wrote:
> > It really depends on the people who writing the ASL code (DSDT),
> > I'm not sure if Windows will use _DSD and how to use it, but
> > firmware guys may just use the
On Wed, Sep 23, 2015 at 06:57:03PM +0100, Sudeep Holla wrote:
> On 23/09/15 18:22, Jeremy Linton wrote:
> >|FWIW, mainline booting with this patch on Juno r1 with ACPI enabled
> >dies a |horrible death:
> >
> >Sorry about the delay, I didn't see this message.
> >
> >
> >
> >|How did you get this to
On Tue, Aug 11, 2015 at 01:04:55PM -0700, David Daney wrote:
> On 08/11/2015 11:49 AM, David Miller wrote:
> >From: David Daney
> >Date: Mon, 10 Aug 2015 17:58:35 -0700
> >
> >>Change from v1: Drop PHY binding part, use fwnode_property* APIs.
> >>
> >>The first patch (1/2) rearranges the existing
On Wed, May 20, 2015 at 02:04:02PM +0200, Arnd Bergmann wrote:
> On Wednesday 20 May 2015 06:52:03 Suravee Suthikulanit wrote:
> > On 5/20/2015 5:01 AM, Catalin Marinas wrote:
> > > On Fri, May 15, 2015 at 04:23:09PM -0500, Suravee Suthikulpanit wrote:
> >
On Wed, May 20, 2015 at 11:27:54AM +0200, Arnd Bergmann wrote:
> On Wednesday 20 May 2015 10:24:15 Catalin Marinas wrote:
> > On Sat, May 16, 2015 at 01:59:00AM +0200, Rafael J. Wysocki wrote:
> > > On Friday, May 15, 2015 04:23:11 PM Suravee S
On Thu, May 07, 2015 at 07:37:13PM -0500, Suravee Suthikulpanit wrote:
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 4269dba..c7227e8 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1,5 +1,6 @@
> config ARM64
> def_bool y
> + select ACPI_CCA_REQUIRED i
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> The eepro100 removal has been blocked for almost a year by a vague
> suggestion from Russell that e100 doesn't work on ARM. But he doesn't
> have that machine anymore. So, we're stuck in limbo.
Russell might have tested it on an Integrator/AP (not sure
th
On 26/07/06, Catherine Zhang <[EMAIL PROTECTED]> wrote:
Enclosed please find the new fix for the memory leak problem, incorporating
suggestions from Stephen and James.
FYI, Michal confirmed that, with this patch, kmemleak no longer
reports leaks in the context_struct_to_string() function in
sec
Russell King <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 23, 2005 at 10:15:48PM +, Russell King wrote:
>> Well, I've run 2.6.15-rc2 on what I think was the ARM platform which
>> exhibited the problem, but it doesn't show up.
>
> The test was merely a "did it successfully BOOTP" because I can't
> g
25 matches
Mail list logo
