On Tue, Apr 14, 2015 at 12:08:11PM +0200, Arnd Bergmann wrote:
> On Tuesday 14 April 2015 11:33:13 Dr. Philipp Tomsich wrote:
> > After getting a good night’s sleep, the “reuse the existing system call
> > table” comment
> > makes a little more sense as I construe it as having just one merged sys
On Tue, Apr 14, 2015 at 11:51:54AM +, Pinski, Andrew wrote:
> > On Apr 14, 2015, at 4:15 AM, Arnd Bergmann wrote:
> > On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote:
> >>> On Apr 14, 2015, at 3:08 AM, Arnd Bergmann wrote:
> >>> There are multiple ways of doing this:
> >>>
> >>> a) se
On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote:
> For completeness, there is yet another option, which would be to use the
> exact system call table from arm64 and do all the emulation in user space
> rather than the kernel. This would however be the least compatible with
> existing
On Tue, Apr 14, 2015 at 05:29:36PM +0200, Dr. Philipp Tomsich wrote:
> > On 14 Apr 2015, at 16:47, Catalin Marinas wrote:
> >> I mainly want to avoid accidentally creating new ABIs for syscalls and
> >> ioctls:
> >> we have many drivers that today use io
On Tue, Apr 14, 2015 at 02:49:04PM -0500, Kumar Gala wrote:
> On Apr 14, 2015, at 11:36 AM, Mark Rutland wrote:
> > On Fri, Apr 10, 2015 at 11:05:29AM +0100, Catalin Marinas wrote:
> >> On Thu, Apr 09, 2015 at 12:37:06PM -0500, Kumar Gala wrote:
> >>> This patch se
On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote:
> On 15 Apr 2015, at 00:28, Arnd Bergmann wrote:
> > On Tuesday 14 April 2015 16:00:34 Catalin Marinas wrote:
> >> On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote:
> >>> For comp
On Tue, Apr 14, 2015 at 05:44:07PM +0200, Arnd Bergmann wrote:
> On Tuesday 14 April 2015 15:47:02 Catalin Marinas wrote:
> > On Tue, Apr 14, 2015 at 12:08:11PM +0200, Arnd Bergmann wrote:
> > > d) don't use the asm-generic/unistd.h table for aarch64-ilp32 at all, but
>
On Tue, Apr 14, 2015 at 05:48:48PM -0400, Rob Clark wrote:
> Just speaking as an outsider to this topic, but seems like most/all
> tablets/phones/etc ship with signed firmware. Which means for most of
> the population, upgrading the firmware to a new version which did
> support the standard (assum
On Tue, Apr 14, 2015 at 09:21:17AM -0500, Kumar Gala wrote:
> On Apr 13, 2015, at 4:41 AM, Catalin Marinas wrote:
> > On Fri, Apr 10, 2015 at 02:06:33PM -0500, Kumar Gala wrote:
> >> On Apr 10, 2015, at 11:10 AM, Catalin Marinas
> >> wrote:
> >> Qualcom
On Tue, Apr 14, 2015 at 10:51:40PM +0200, Arnd Bergmann wrote:
> On Tuesday 14 April 2015 17:29:53 Mark Rutland wrote:
> > > +static int msm_cpu_boot(unsigned int cpu)
> > > +{
> > > + int ret = 0;
> > > +
> > > + if (per_cpu(cold_boot_done, cpu) == false) {
> > > + ret =
On Wed, Apr 15, 2015 at 10:04:25AM +0100, Mark Rutland wrote:
> On Tue, Apr 14, 2015 at 11:52:39PM +0100, Al Stone wrote:
> > On 04/14/2015 10:29 AM, Mark Rutland wrote:
> > >> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
> > >> b/Documentation/devicetree/bindings/arm/cpus.txt
> > >
mleak_init is one less than 'actual number'.
>
> Then, in kmemleak_init, if early_log buffer size equal actual
> number, kmemleak will init sucessful, so change warning condition
> to 'crt_early_log > ARRAY_SIZE(early_log)'.
>
> Signed-off-by: Wang Kai
Ac
On Wed, Apr 15, 2015 at 12:47:32PM +0100, Wang Kai wrote:
> MSECS_MIN_AGE is actually 5000 in kmemleak.c, corret it in doc.
^^
s/corret/correct
> Signed-off-by: Wang Kai
Acked-by: Catalin M
d, just add it to the commit log.
> + if (crt_early_log > ARRAY_SIZE(early_log))
> pr_warning("Early log buffer exceeded (%d), please increase "
> "DEBUG_KMEMLEAK_EARLY_LOG_SIZE\n", crt_early_log);
Otherwise, my ack still stands:
Acked-by:
On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote:
> On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote:
> > On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote:
> > > We’ve run full systems (built from buildroot) consisting of ILP32 binar
On Wed, Apr 15, 2015 at 01:50:51PM +0200, Dr. Philipp Tomsich wrote:
> On 15 Apr 2015, at 13:22, Catalin Marinas wrote:
> > I think you are right. I was more thinking of those routed directly to
> > the native (non-compat) syscalls. We would need to make sure the return
> >
On Wed, Apr 15, 2015 at 07:01:23PM +0200, Dr. Philipp Tomsich wrote:
> On 15 Apr 2015, at 17:38, Catalin Marinas wrote:
> > On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote:
> >> On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote:
> >>> On Wed, Ap
On Thu, Apr 16, 2015 at 12:25:36AM +0200, Alexander Graf wrote:
> We've just started to bootstrap openSUSE for ILP32 with the non-final
> abi. However, keep in mind that at least for us bootstrapping is a
> manual process. So changing syscall numbers means we'll need to go
> through the manual proc
On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote:
> On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich
> wrote:
> > Just for the record (and to avoid anyone wasting their time on what’s
> > available
> > today): we are migrating this over to option (a) now, even though we would
> > p
On Thu, Apr 16, 2015 at 01:19:14PM +0200, Dr. Philipp Tomsich wrote:
> Just for the record (and to avoid anyone wasting their time on what’s
> available
> today): we are migrating this over to option (a) now, even though we would
> prefer to see option (b) implemented.
>
> If we get a consensus o
On Wed, Apr 15, 2015 at 11:01:17AM -0400, Rob Clark wrote:
> On Wed, Apr 15, 2015 at 9:34 AM, Catalin Marinas
> wrote:
> > On Tue, Apr 14, 2015 at 05:48:48PM -0400, Rob Clark wrote:
> >> Just speaking as an outsider to this topic, but seems like most/all
> >> table
On Thu, Apr 16, 2015 at 01:17:32PM -0400, Rob Clark wrote:
> On Thu, Apr 16, 2015 at 11:21 AM, Catalin Marinas
> wrote:
> > On Wed, Apr 15, 2015 at 11:01:17AM -0400, Rob Clark wrote:
> >> There are folks who are working to get saner, more-upstream kernels
> >> work
On Thu, Apr 16, 2015 at 05:21:30PM +0200, Arnd Bergmann wrote:
> On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote:
> > On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote:
> > > There are only a few places where long should be 32bit rather than
> > >
On Fri, Mar 27, 2015 at 09:40:26PM +0800, Hanjun Guo wrote:
> On 2015年03月26日 11:49, Hanjun Guo wrote:
> >On 2015/3/26 1:21, Catalin Marinas wrote:
> >>On Tue, Mar 24, 2015 at 10:02:46PM +0800, Hanjun Guo wrote:
> >>>--- a/drivers/acpi/acpi_processor.c
> >&
Hi Stephen,
On Tue, Mar 31, 2015 at 10:21:22AM +1100, Stephen Rothwell wrote:
> diff --cc arch/arm64/configs/defconfig
> index f3c8619f8fe1,e07896c819ef..
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@@ -31,9 -31,12 +31,13 @@@ CONFIG_MODULES=
> CONFIG_
Hi Andrey,
On Tue, Mar 24, 2015 at 05:49:04PM +0300, Andrey Ryabinin wrote:
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 4085df1..10bbd71 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -41,6 +41,7 @@ config ARM64
> select HAVE_ARCH_AUDITSYSCALL
> se
On Wed, Apr 29, 2015 at 08:44:08AM -0500, Suravee Suthikulpanit wrote:
> From ACPIv6 (http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf),
> section 6.2.17 _CCA states that ARM platforms require ACPI _CCA object to be
> specified for DMA-cabpable devices. This patch introduces ACPI_MUST
On Wed, Apr 29, 2015 at 09:31:03AM -0500, Suravee Suthikulpanit wrote:
>
>
> On 04/29/2015 09:04 AM, Catalin Marinas wrote:
> >On Wed, Apr 29, 2015 at 08:44:08AM -0500, Suravee Suthikulpanit wrote:
> >> From ACPIv6
> >> (http://www.uefi.org/sites/def
Hi Paul,
On Thu, Apr 23, 2015 at 01:07:33PM -0700, Paul E. McKenney wrote:
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 328b8ce4b007..6dc727a6e73e 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -252,15 +252,13 @@ static int op_cpu_kill(unsig
On Tue, Apr 28, 2015 at 05:38:52PM -0700, Feng Kan wrote:
> Using the glibc cortex string work work authored by Linaro as base to
> create new copy to/from user kernel routine.
>
> Iperf performance increase:
> -l (size) 1 core result
> Optimized 64B
On Thu, Apr 30, 2015 at 03:52:17PM +0200, Arnd Bergmann wrote:
> On Thursday 30 April 2015 14:13:45 Will Deacon wrote:
> > On Thu, Apr 30, 2015 at 02:03:00PM +0100, Arnd Bergmann wrote:
> > > On Thursday 30 April 2015 12:46:15 Will Deacon wrote:
> > > > Cache sync doesn't exist in the ARM/arm64arch
Even more options below ;). I'll add mine.
On Fri, Apr 17, 2015 at 02:17:32PM +0100, Arnd Bergmann wrote:
> Here is my current line of thinking:
>
> - Using all the aarch32 data structures would be the easiest way, then
> we could use the side of asm-generic/unistd.h and everything should
> w
On Fri, Apr 17, 2015 at 05:49:44PM +0200, Arnd Bergmann wrote:
> On Friday 17 April 2015 15:46:57 Catalin Marinas wrote:
> > On Fri, Apr 17, 2015 at 02:17:32PM +0100, Arnd Bergmann wrote:
> > > g) create a new ABI that does things in exactly the way that we
> > >
On Fri, Apr 10, 2015 at 02:06:33PM -0500, Kumar Gala wrote:
> On Apr 10, 2015, at 11:10 AM, Catalin Marinas wrote:
> > On Fri, Apr 10, 2015 at 10:24:46AM -0500, Kumar Gala wrote:
> >> On Apr 10, 2015, at 5:05 AM, Catalin Marinas
> >> wrote:
> >>> On Thu,
On Fri, Jul 13, 2012 at 01:40:03PM +0100, Arnd Bergmann wrote:
> On Thursday 12 July 2012, John Stultz wrote:
> >
> > On 07/12/2012 10:31 AM, Marc Zyngier wrote:
> > > On Thu, 12 Jul 2012 09:57:33 -0700, John Stultz
> > > wrote:
> > >
> > >> So following ia64's method is probably better then copy
On Sat, Jul 14, 2012 at 10:35:05AM +0100, Pavel Machek wrote:
> On Tue 2012-07-10 11:12:23, Catalin Marinas wrote:
> > On Sat, Jul 07, 2012 at 10:30:58AM +0100, Mikael Pettersson wrote:
> > > Catalin Marinas writes:
> > > > Compilation requires a new aarch64-none
On Sat, Jul 14, 2012 at 10:30:32AM +0100, Pavel Machek wrote:
> > > > Agreed. It's clear from the code that it started out as a copy
> > > > of the 32 bit ARM code base, which I think was a mistake, but
> > > > it has also moved on since then and many areas of the 64 bit
> > > > code are now muc
On Sun, Jul 15, 2012 at 08:43:07PM +0100, Arnd Bergmann wrote:
> On Sunday 15 July 2012, Catalin Marinas wrote:
> > The AArch32 execution mode is optional, so it depends on the actual CPU
> > implementation (while AArch64 is mandatory). If the implementation
> > support
On Mon, Jul 16, 2012 at 09:24:26AM +0100, Avi Kivity wrote:
> On 07/15/2012 03:16 PM, Catalin Marinas wrote:
> >
> > The AArch32 execution mode is optional, so it depends on the actual CPU
> > implementation (while AArch64 is mandatory). If the implementation
> > s
Hi,
On Mon, Jul 16, 2012 at 01:16:51PM +0100, Pavel Machek wrote:
> > > > The AArch32 execution mode is optional, so it depends on the actual CPU
> > > > implementation (while AArch64 is mandatory). If the implementation
> > > > supports it, the most likely scenario for AArch32 at kernel level is
This patch allows an architecture to not define CLOCK_TICK_RATE, in
which case ACTHZ defaults to (HZ << 8).
Signed-off-by: Catalin Marinas
Acked-by: Arnd Bergmann
Cc: John Stultz
Cc: Andrew Morton
---
include/linux/jiffies.h | 10 +++---
1 files changed, 7 insertions(+), 3 del
This patch introduces CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE and uses
this instead of the multitude of #if defined() checks in atomic64_test.c
Signed-off-by: Catalin Marinas
Cc: Russell King
Cc: Ralf Baechle
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linux...@de.ibm.com
Cc: x
On AArch64, we want the sys_stat64() and related functions for compat
support but do not need the generic struct stat64, enabled automatically
if __ARCH_WANT_STAT64.
Signed-off-by: Catalin Marinas
Acked-by: Arnd Bergmann
Cc: Alexander Viro
Cc: Andrew Morton
---
fs/stat.c |4 ++--
1 files
On Mon, Jul 16, 2012 at 12:53:21AM +0100, Linus Torvalds wrote:
> On Sun, Jul 15, 2012 at 4:21 PM, Måns Rullgård wrote:
> >
> > FWIW, I'd prefer naming the directory either arm64 or armv8 for a few
> > reasons:
> >
> > - Those are the names people actually use to refer to the architecture
> > - Th
On Wed, Jul 18, 2012 at 05:33:57AM +0100, Benjamin Herrenschmidt wrote:
> On Fri, 2012-07-06 at 22:05 +0100, Catalin Marinas wrote:
> > This patch introduces ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE and uses this
> > instead of the multitude of #if defined() checks in atomic64_test.c
>
Hi Jon,
On Wed, Jul 18, 2012 at 06:35:40AM +0100, Jon Masters wrote:
> On 07/06/2012 05:05 PM, Catalin Marinas wrote:
>
> > These patches are also available on this branch:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git
> > ups
On Wed, Jul 18, 2012 at 04:27:12PM +0100, Dennis Gilmore wrote:
> El Tue, 17 Jul 2012 22:33:33 -0400
> Jon Masters escribió:
> > On 07/17/2012 06:35 PM, Joe Perches wrote:
> > > On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
> > >
> > >> The u
On Thu, Jul 19, 2012 at 12:11:03AM +0100, John Stultz wrote:
> On 07/18/2012 03:51 PM, Andrew Morton wrote:
> > On Tue, 17 Jul 2012 17:41:40 +0100
> > Catalin Marinas wrote:
> >
> >> This patch allows an architecture to not define CLOCK_TICK_RATE, in
> >>
On Fri, Jul 20, 2012 at 09:28:12AM +0100, Arnd Bergmann wrote:
> On Friday 20 July 2012, Jon Masters wrote:
> > > I think it would be best to list the technical limitations, from the
> > > kernel's perspective, of the unsupported exception levels and the
> > > advantages of the supported exception
On Fri, Jul 20, 2012 at 01:32:39PM +0100, Geert Uytterhoeven wrote:
> On Fri, Jul 20, 2012 at 12:52 PM, Catalin Marinas
> wrote:
> > On Fri, Jul 20, 2012 at 09:28:12AM +0100, Arnd Bergmann wrote:
> >> On Friday 20 July 2012, Jon Masters wrote:
> >> > >
On Thu, Jul 19, 2012 at 06:31:07PM +0100, Christopher Covington wrote:
> On 07/18/2012 02:57 AM, Jon Masters wrote:
> > On 07/06/2012 05:05 PM, Catalin Marinas wrote:
> >
> >> +- CPU mode
> >> + All forms of interrupts must be masked in PSTATE.DAIF (D
On Fri, Jul 20, 2012 at 02:47:36PM +0100, Christopher Covington wrote:
> On 07/20/2012 03:10 AM, Jon Masters wrote:
> > Unless you enter at EL2 you can never install a hypervisor. That's the
> > reason for the requirement for generally entering at EL2 when possible.
>
> That brief explanation woul
On Wed, Jun 10, 2015 at 09:34:43PM +0200, Lorenzo Nava wrote:
> On Wed, Jun 10, 2015 at 6:28 PM, Catalin Marinas
> wrote:
> > On Wed, Jun 03, 2015 at 07:15:45PM +0200, Lorenzo Nava wrote:
> > > This patch allows the use of CMA for DMA coherent memory allocation.
> > &
On Thu, Jun 11, 2015 at 12:04:32PM +0800, Chunyan Zhang wrote:
> From: Janet Liu
>
> kernel thread's default fpsimd state is zero. When fork a thread, if parent
> is kernel thread,
> and save hardware context to parent's fpsimd state, but this hardware
> context is user
> process's context, be
On Thu, Jun 11, 2015 at 12:02:45PM +0800, Chunyan Zhang wrote:
> From: Janet Liu
>
> Now FPSIMD don't handle HOTPLUG_CPU. This introduces bug after cpu down/up
> process.
>
> After cpu down/up process, the FPSMID hardware register is default value, not
> any
> process's fpsimd context. when CP
On Thu, Jun 11, 2015 at 04:29:43PM +0100, Will Deacon wrote:
> On Thu, Jun 11, 2015 at 11:39:58AM +0100, Maninder Singh wrote:
> > Header is not needed in hw_breakpoint.c
> > for arm as well as arm64.
> > Removing the same.
> >
> > Signed-off-by: Maninder Singh
> > Reviewed-by: Vaneet Narang
>
On Tue, Jun 16, 2015 at 09:44:24AM +0100, Catalin Marinas wrote:
> On Mon, Jun 15, 2015 at 10:25:18PM +0100, Larry Finger wrote:
> > Beginning at commit d52d399, the following INFO splat is logged:
> >
> > [2.816564] ===
> > [2.816
Fai Lau, these are the
> clue to the fix. Routine kmemleak_alloc_percpu() always uses GFP_KERNEL
> for its allocations, whereas it should use the value input to pcpu_alloc().
>
> Signed-off-by: Larry Finger
> Cc: Martin KaFai Lau
> Cc: Catalin Marinas
> To: Tejun Heo
> Cc: C
rm64: drop sleep_idmap_phys and clean up cpu_resume()
Catalin Marinas (3):
Merge branch 'for-next/cpu-init' of git://git.kernel.org/.../arm64/linux
Merge branch 'arm64/psci-rework' of git://git.kernel.org/.../mark/linux
arm64: Do not attempt to use init_mm in res
On Mon, Jun 08, 2015 at 06:14:32AM +0100, Liu, XinwuX wrote:
> when kernel uses kmalloc to allocate memory, slub/slab will find
> a suitable kmem_cache. Ususally the cache's object size is often
> greater than requested size. There is unused space which contains
> dirty data. These dirty data might
On Mon, Jun 08, 2015 at 10:38:13AM +0100, Christoph Lameter wrote:
> On Mon, 8 Jun 2015, Liu, XinwuX wrote:
>
> > when kernel uses kmalloc to allocate memory, slub/slab will find
> > a suitable kmem_cache. Ususally the cache's object size is often
> > greater than requested size. There is unused s
The kmemleak_do_cleanup() work thread already waits for the
kmemleak_scan thread to finish via kthread_stop(). Waiting in
kthread_stop() while scan_mutex is held may lead to deadlock if
kmemleak_scan_thread() also waits to acquire for scan_mutex.
Signed-off-by: Catalin Marinas
Cc: Andrew Morton
worth fixing the
lock acquiring order.
Catalin Marinas (4):
mm: kmemleak: Allow safe memory scanning during kmemleak disabling
mm: kmemleak: Fix delete_object_*() race when called on the same
memory block
mm: kmemleak: Do not acquire scan_mutex in kmemleak_do_cleanup()
mm: kmemleak
ght improvement in the delete_object_*()
performance by avoiding acquiring kmemleak_lock twice and
incrementing/decrementing object->use_count.
Signed-off-by: Catalin Marinas
Cc: Andrew Morton
---
mm/kmemleak.c | 39 ++-
1 file changed, 26 insertions(+), 13 del
k_enabled nob so that we can defer the disabling of the
object freeing tracking until the scanning thread completed. The
kmemleak_free_part() is deliberately ignored by this patch since this is
only called during boot before the scanning thread started.
Signed-off-by: Catalin Marinas
Reported-by
ing. Such object cannot be freed or removed from object_tree_root
and object_list since kmemleak_lock is already held. There is a very
small risk that some of the object data is being modified on another CPU
but the only downside is inconsistent information printing.
Signed-off-by: Catalin Marinas
C
han individual pointer-like values. The
memory scanning performance is significantly improved (by an order of
magnitude on an arm64 system).
Signed-off-by: Catalin Marinas
Cc: Andrew Morton
---
Andrew,
While sorting out some of the kmemleak disabling races, I realised that
kmemleak scann
On Mon, Jun 08, 2015 at 06:06:59PM +0100, Catalin Marinas wrote:
> The kmemleak memory scanning uses finer grained object->lock spinlocks
> primarily to avoid races with the memory block freeing. However, the
> pointer lookup in the rb tree requires the kmemleak_lock to be hel
the
object freeing tracking until the scanning thread completed. The
kmemleak_free_part() is deliberately ignored by this patch since this is
only called during boot before the scanning thread started.
Signed-off-by: Catalin Marinas
Reported-by: Vignesh Radhakrishnan
Tested-by: Vignesh
Hi Andrew,
On Thu, Jun 04, 2015 at 12:29:36AM +0100, Andrew Morton wrote:
> On Wed, 3 Jun 2015 16:42:56 +0100 Catalin Marinas
> wrote:
>
> > With the current implementation, if kmemleak is disabled because of an
> > error condition (e.g. fails to allocate metadata),
ormance is significantly
improved: at least 50% with lock debugging disabled and over an order of
magnitude with lock proving enabled (on an arm64 system).
Signed-off-by: Catalin Marinas
Cc: Andrew Morton
---
Changes since v1:
- scan_block() allow_resched logic moved outside the function since the
On Tue, Jun 09, 2015 at 09:10:45AM +0100, Zhang, Yanmin wrote:
> On 2015/6/8 18:13, Catalin Marinas wrote:
> > As I replied already, I don't think this is that bad, or at least not
> > worse than what kmemleak already does (looking at all data whether it's
> > point
On Wed, Jun 10, 2015 at 08:45:50AM +0100, Zhang, Yanmin wrote:
> On 2015/6/9 23:03, Catalin Marinas wrote:
> > On Tue, Jun 09, 2015 at 09:10:45AM +0100, Zhang, Yanmin wrote:
> >> On 2015/6/8 18:13, Catalin Marinas wrote:
> >>> As I replied already, I don't thin
On Tue, Jun 09, 2015 at 10:02:00PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 09, 2015 at 12:08:28PM -0700, Stephen Boyd wrote:
> > On 04/13/2015 06:42 AM, Russell King - ARM Linux wrote:
> > > On Fri, Apr 10, 2015 at 03:33:11PM -0700, Stephen Boyd wrote:
> > >> Cc: Mark Rutland
> > >> C
On Wed, Jun 03, 2015 at 07:15:45PM +0200, Lorenzo Nava wrote:
> This patch allows the use of CMA for DMA coherent memory allocation.
> At the moment if the input parameter "is_coherent" is set to true
> the allocation is not made using the CMA, which I think is not the
> desired behaviour.
>
> S
On Tue, Jun 09, 2015 at 01:26:41PM -0500, Rob Herring wrote:
> Now that all users of set_irq_flags and custom flags are converted to
> genirq functions, the ARM specific set_irq_flags can be removed.
>
> Signed-off-by: Rob Herring
> Cc: Catalin Marinas
> Cc: Will Deacon
&
On Thu, Jun 18, 2015 at 10:57:06AM +0530, Maninder Singh wrote:
> From: Rohit Thapliyal
>
> On 64bit kernel, the dump_mem gives 32 bit addresses
> on the stack dump. This gives unorganized information regarding
> the 64bit values on the stack. Hence, modified to get a complete
> 64bit memory dump
On Fri, Jun 19, 2015 at 11:30:50AM +0100, vigne...@codeaurora.org wrote:
> >> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> >> index 5405aff5a590..7913386ca506 100644
> >> --- a/mm/kmemleak.c
> >> +++ b/mm/kmemleak.c
> >> @@ -194,6 +194,8 @@ static struct kmem_cache *scan_area_cache;
> >>
> >> /* s
On Thu, Mar 01, 2018 at 10:28:03AM -0600, Rob Herring wrote:
> libfdt gained a new dependency on strrchr, so make it available to the
> EFI namespace before we update libfdt.
>
> Thanks to Ard for providing this fix.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
>
On Wed, Mar 28, 2018 at 08:12:50AM +, Michel Pollet wrote:
> I'm currently adapting a port from a machine-file based approach to driver
> based, and I
> would have a need for arch/arm64/kernel/smp_spin_table.c -- it's *exactly* my
> use
> case, but for arm32.
> So what would be my options her
On Wed, Apr 18, 2018 at 08:53:12PM +0200, Andrey Konovalov wrote:
> @@ -238,12 +239,15 @@ static inline void uaccess_enable_not_uao(void)
> /*
> * Sanitise a uaccess pointer such that it becomes NULL if above the
> * current addr_limit.
> + * Also untag user pointers that have the top byte tag
On Wed, Apr 18, 2018 at 08:53:13PM +0200, Andrey Konovalov wrote:
> diff --git a/mm/gup.c b/mm/gup.c
> index 76af4cfeaf68..fb375de7d40d 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -386,6 +386,8 @@ struct page *follow_page_mask(struct vm_area_struct *vma,
> struct page *page;
> struct
On Wed, Apr 25, 2018 at 04:45:37PM +0200, Andrey Konovalov wrote:
> On Thu, Apr 19, 2018 at 11:33 AM, Kirill A. Shutemov
> wrote:
> > On Wed, Apr 18, 2018 at 08:53:09PM +0200, Andrey Konovalov wrote:
> >> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> >> tags into the
On Tue, Apr 17, 2018 at 03:55:08PM +0530, Chintan Pandya wrote:
> Ping...
>
> On 4/3/2018 1:30 PM, Chintan Pandya wrote:
> > This series of patches are follow up work (and depends on)
> > Toshi Kani 's patches "fix memory leak/
> > panic in ioremap huge pages".
First of all, you'd need to post pa
On Tue, Apr 03, 2018 at 01:30:44PM +0530, Chintan Pandya wrote:
> Add an interface to invalidate intermediate page tables
> from TLB for kernel.
>
> Signed-off-by: Chintan Pandya
> ---
> arch/arm64/include/asm/tlbflush.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/
On Thu, May 17, 2018 at 06:05:24PM +0100, Catalin Marinas wrote:
> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
> > Jeremy Linton (12):
> > drivers: base: cacheinfo: move cache_setup_of_node()
> > drivers: base: cacheinfo: setup DT cache properties
On Tue, Jun 05, 2018 at 01:50:07PM +0200, Arnd Bergmann wrote:
> Without including psci.h and arm-smccc.h, we now get a build failure in
> some configurations:
>
> arch/arm64/kernel/cpu_errata.c: In function 'arm64_update_smccc_conduit':
> arch/arm64/kernel/cpu_errata.c:278:10: error: 'psci_ops' u
On Tue, Jun 05, 2018 at 03:35:03PM +0100, Sudeep Holla wrote:
> Though CONFIG_ACPI_PPTT is selected by platforms and nor user visible,
> it may be useful to support the build with CONFIG_ACPI_PPTT disabled.
>
> This patch adds the missing dummy/boiler plate implementation to fix
> the build.
>
>
On Wed, Jun 06, 2018 at 11:38:46AM -0500, Jeremy Linton wrote:
> The numa mask subset check can often lead to system hang or crash during
> CPU hotplug and system suspend operation if NUMA is disabled. This is
> mostly observed on HMP systems where the CPU compute capacities are
> different and end
e) which can be useful on cores that
> support mapping larger block sizes in the TLB entries.
>
> Signed-off-by: Punit Agrawal
> Cc: Christoffer Dall
> Cc: Marc Zyngier
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm/include/asm/kvm_
e) which can be useful on cores that
> support mapping larger block sizes in the TLB entries.
>
> Signed-off-by: Punit Agrawal
> Reviewed-by: Christoffer Dall
> Cc: Marc Zyngier
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm/include/as
On Wed, May 09, 2018 at 04:46:26PM +0900, Masahiro Yamada wrote:
> VMLINUX_SYMBOL() is no-op unless CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX
> is defined. It has ever been selected only by BLACKFIN and METAG.
> VMLINUX_SYMBOL() is unneeded for ARM64-specific code.
>
> Signed-off-by: Masahiro Yamada
Hi Mark,
On Tue, Apr 17, 2018 at 07:37:31PM +0100, Mark Rutland wrote:
> diff --git a/arch/arm64/include/asm/mmu_context.h
> b/arch/arm64/include/asm/mmu_context.h
> index 39ec0b8a689e..caf0d3010112 100644
> --- a/arch/arm64/include/asm/mmu_context.h
> +++ b/arch/arm64/include/asm/mmu_context.h
>
On Tue, Apr 17, 2018 at 07:37:35PM +0100, Mark Rutland wrote:
> +Basic support
> +-
> +
> +When CONFIG_ARM64_PTR_AUTH is selected, and relevant HW support is
> +present, the kernel will assign a random APIAKey value to each process
> +at exec*() time. This key is shared by all threads w
On Wed, Apr 25, 2018 at 05:50:41AM -0400, Chunyu Hu wrote:
> - Original Message -
> > From: "Catalin Marinas"
> > On Tue, Apr 24, 2018 at 07:20:57AM -0600, Michal Hocko wrote:
> > > On Mon 23-04-18 12:17:32, Chunyu Hu wrote:
> > > [...]
> &g
On Wed, Apr 25, 2018 at 11:36:06PM +, Rohit Khanna wrote:
> Adding few other folks.
It looks fine to me but cc'ing Mark and Lorenzo (and it should have been
posted on linux-arm-ker...@lists.infradead.org).
> From: Rohit Khanna
> Sent: Wednesday, April 25, 2018 4:08 PM
> To: catalin.mari...@ar
On Thu, Apr 26, 2018 at 08:23:19AM -0400, Chunyu Hu wrote:
> kmemleak is using kmem_cache to record every pointers returned from kernel
> mem
> allocation activities such as kmem_cache_alloc(). every time an object from
> slab allocator is returned, a following new kmemleak object is allocated.
Hi Jeremy,
On Tue, Feb 26, 2019 at 07:05:34PM -0600, Jeremy Linton wrote:
> Jeremy Linton (6):
> arm64: Provide a command line to disable spectre_v2 mitigation
> arm64: add sysfs vulnerability show for meltdown
> arm64: Always enable spectrev2 vulnerability detection
> arm64: add sysfs vul
On Tue, Feb 26, 2019 at 06:43:41PM +, James Morse wrote:
> From: Zhang Lei
>
> On the Fujitsu-A64FX cores ver(1.0, 1.1), memory access may cause
> an undefined fault (Data abort, DFSC=0b11). This fault occurs under
> a specific hardware condition when a load/store instruction performs an
On Fri, Feb 22, 2019 at 06:04:51PM +, Will Deacon wrote:
> Will Deacon (3):
> asm-generic/io: Pass result of I/O accessor to __io_[p]ar()
> riscv: io: Update __io_[p]ar() macros to take an argument
> arm64: io: Hook up __io_par() for inX() ordering
Since we have the acks in place, I plan
901 - 1000 of 3477 matches
Mail list logo
