ick this in the commit message, preferably annotated a bit like
Peter's example to show the READ_ONCE() being speculated.
I can confirm that this patch fixes a problem observed in
ep_scan_ready_list(.) whereby ovflist appeared to change when the write
lock was held.
So please feel free to ad
On Tue, Aug 13, 2019 at 03:04:52PM +0100, Steve Capper wrote:
> Hi Will,
>
> On Tue, Aug 13, 2019 at 01:06:44PM +0100, Will Deacon wrote:
> > [+Steve]
> >
> > On Tue, Aug 13, 2019 at 11:58:52AM +0100, Will Deacon wrote:
> > > On Tue, Aug 13, 2019 at
Hi Will,
On Tue, Aug 13, 2019 at 01:06:44PM +0100, Will Deacon wrote:
> [+Steve]
>
> On Tue, Aug 13, 2019 at 11:58:52AM +0100, Will Deacon wrote:
> > On Tue, Aug 13, 2019 at 10:02:01AM +0100, Will Deacon wrote:
> > > On Mon, Aug 12, 2019 at 05:51:35PM -0400, Qian Cai wrote:
> > > > Booting today'
> procedure on X86 architecture.
>
> Acked-by: David Hildenbrand
> Signed-off-by: Anshuman Khandual
> ---
FWIW:
Acked-by: Steve Capper
One minor comment below though.
> arch/arm64/Kconfig | 3 +
> arch/arm64/mm/mmu.c | 290
> ++
_hugepagesz(char *opt)
> return 0;
> }
> __setup("hugepagesz=", setup_hugepagesz);
> -
> -#ifdef CONFIG_ARM64_64K_PAGES
> -static __init int add_default_hugepagesz(void)
> -{
> - if (size_to_hstate(CONT_PTES * PAGE_SIZE) == NULL)
> - hugetlb
2M32M 1G
> 16K:2M 32M 1G
> 64K:2M512M16G
>
> Reviewed-by: Naoya Horiguchi
> Signed-off-by: Anshuman Khandual
Reviewed-by: Steve Capper
> ---
> arch/arm64/include/asm/hugetlb.h | 5 +
> arch/arm64/mm/hugetlbpage.
hich checks standard huge page order.
> But an architecture can choose to override the default and provide support
> for a comprehensive set of huge page sizes.
>
> Reviewed-by: Naoya Horiguchi
> Signed-off-by: Anshuman Khandual
Reviewed-by: Steve Capper
> ---
> include/l
CONT PTEPMDCONT PMDPUD
>------
> 4K: NA 2M NA 1G
> 16K:NA32M NA
> 64K:NA 512M NA
>
> Reviewed-by: Naoya Horiguchi
> Signed-off-by: Anshuman Khandual
Reviewed-by
PUD_SHIFT
> order based HugeTLB pages during migration.
>
> Reviewed-by: Naoya Horiguchi
> Signed-off-by: Anshuman Khandual
Reviewed-by: Steve Capper
> ---
> include/linux/hugetlb.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux
asible to be
> placed under a movable zone. At present it just checks for gigantic pages
> but going forward it can incorporate other enhanced checks.
>
> Reviewed-by: Naoya Horiguchi
> Suggested-by: Michal Hocko
> Signed-off-by: Anshuman Khandual
FWIW:
Reviewed-by: Steve Capper
elow
>> when munmap is called on poisoned hugepages.
>>
>> [ 344.165544] mm/pgtable-generic.c:33: bad pmd 00083af00074.
>>
>> Fix huge_pte_offset() to return the poisoned PMD which is then
>> appropriately handled by the generic layer code.
>>
>> Sign
On Fri, Feb 03, 2017 at 11:28:48AM -0800, Linus Torvalds wrote:
> On Fri, Feb 3, 2017 at 11:08 AM, Al Viro wrote:
> >
> > On x86 it does. I don't see anything equivalent in mm/gup.c one, and the
> > only kinda-sorta similar thing (access_ok() in __get_user_pages_fast()
> > there) is vulnerable to
(.) will always return false, provoking BUGs when one runs
the libhugetlbfs test suite.
This patch replaces PageTransHuge(), with PageHead() which will work for
both HugeTLB and THP.
Fixes: dd78fedde4b9 ("rmap: support file thp")
Cc: Kirill A. Shutemov
Cc: Andrew Morton
Signed-off-by: Stev
)
Fixes: dd78fedde4b9 ("rmap: support file thp")
Cc: Kirill A. Shutemov
Cc: Andrew Morton
Signed-off-by: Steve Capper
---
mm/rmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/rmap.c b/mm/rmap.c
index 709bc83..ad8fc51 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
Hi Alex,
Thanks for posting this.
On Wed, Jul 13, 2016 at 06:14:11PM +0200, Alexander Graf wrote:
> On 07/13/2016 05:59 PM, Ard Biesheuvel wrote:
> >On 13 July 2016 at 17:42, Alexander Graf wrote:
> >>Some user space applications are known to break with 48 bits virtual
> >known by whom? At least
On Thu, Apr 14, 2016 at 01:10:35PM +0200, Ard Biesheuvel wrote:
> On 14 April 2016 at 13:02, Steve Capper wrote:
> > On Fri, Apr 08, 2016 at 03:50:23PM -0700, David Daney wrote:
> >> From: Ard Biesheuvel
> >>
> >> There are two problems with the UEFI stub
On Fri, Apr 08, 2016 at 03:50:23PM -0700, David Daney wrote:
> From: Ard Biesheuvel
>
> There are two problems with the UEFI stub DT memory node removal
> routine:
> - it deletes nodes as it traverses the tree, which happens to work
> but is not supported, as deletion invalidates the node itera
> +
Okay, this looks good to me. If we have a PROT_NONE VMA then this is
caught before going into do_numa_page or do_huge_pmd_numa_page (and
there is a BUG_ON inside these functions to catch stragglers.
I've given this a quick test wit
On Wed, Apr 13, 2016 at 03:09:08PM +0100, Steve Capper wrote:
> On Tue, Mar 08, 2016 at 11:59:46PM +, David Daney wrote:
> > From: Ganapatrao Kulkarni
> >
> > Attempt to get the memory and CPU NUMA node via of_numa. If that
> > fails, default the dummy NUMA node
iewed-by: Robert Richter
> Signed-off-by: Ganapatrao Kulkarni
> Signed-off-by: David Daney
Hi David,
I have one minor comment below, but please feel free to add:
Acked-by: Steve Capper
Cheers,
--
Steve
> ---
> arch/arm64/Kconfig| 26 +++
> arch/arm64/includ
Hi Andrew,
On Thu, Mar 31, 2016 at 04:06:50PM -0700, Andrew Morton wrote:
> On Tue, 29 Mar 2016 17:39:41 +0100 Steve Capper wrote:
>
> > HugeTLB pages cannot be split, thus use the compound_mapcount to
> > track rmaps.
> >
> > Currently the page_mapped function wi
On Tue, Mar 29, 2016 at 07:51:49PM +0300, Kirill A. Shutemov wrote:
> On Tue, Mar 29, 2016 at 05:39:41PM +0100, Steve Capper wrote:
> > HugeTLB pages cannot be split, thus use the compound_mapcount to
> > track rmaps.
> >
> > Currently the page_mapped function will
ill A. Shutemov
Signed-off-by: Steve Capper
---
Hi,
This patch is my approach to fixing a problem that unearthed with
HugeTLB pages on arm64. We ran with PAGE_SIZE=64KB and placed down 32
contiguous ptes to create 2MB HugeTLB pages. (We can provide hints to
the MMU that page table entries are
On 25 February 2016 at 16:01, Kirill A. Shutemov wrote:
> On Thu, Feb 25, 2016 at 03:49:33PM +0000, Steve Capper wrote:
>> On 23 February 2016 at 18:47, Will Deacon wrote:
>> > [adding Steve, since he worked on THP for 32-bit ARM]
>>
>> Apologies for my late reply.
On 23 February 2016 at 18:47, Will Deacon wrote:
> [adding Steve, since he worked on THP for 32-bit ARM]
Apologies for my late reply...
>
> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
>> On Tue, 23 Feb 2016 13:32:21 +0300
>> "Kirill A. Shutemov" wrote:
>> > The theory is th
pages at the PMD level.
>
> If the base page size is set to 64KB then 2MB pages are enabled by
> default. It is possible in the future to make 2MB the default huge
> page size for both 4KB and 64KB granules.
>
> Signed-off-by: David Woods
> Reviewed-by: Chris Metcalf
Tha
On 11 December 2015 at 21:02, David Woods wrote:
> The arm64 MMU supports a Contiguous bit which is a hint that the TTE
> is one of a set of contiguous entries which can be cached in a single
> TLB entry. Supporting this bit adds new intermediate huge page sizes.
>
> The set of huge page sizes av
> are not (technically) executed are also not treated as a hit kprobe. Steve
> Capper has suggested that the probe handling should still take place because
> we stepped through the instruction even if it was effectively a nop. This
> would be a significant change in how it currently works
On Mon, Oct 19, 2015 at 04:09:09PM -0400, David Woods wrote:
> The arm64 MMU supports a Contiguous bit which is a hint that the TTE
> is one of a set of contiguous entries which can be cached in a single
> TLB entry. Supporting this bit adds new intermediate huge page sizes.
>
> The set of huge p
default "14" if (ARM64_64K_PAGES && TRANSPARENT_HUGEPAGE)
>>> + default "12" if (ARM64_16K_PAGES && TRANSPARENT_HUGEPAGE)
>>> default "11"
>>
>>
>> I'm a little lost here. How are these numbers
On 6 October 2015 at 11:25, Mark Rutland wrote:
> On Tue, Oct 06, 2015 at 11:18:42AM +0100, Steve Capper wrote:
>> On 6 October 2015 at 10:09, Russell King - ARM Linux
>> wrote:
>> > On Mon, Oct 05, 2015 at 06:02:10PM +0100, Suzuki K. Poulose wrote:
>> >>
On 6 October 2015 at 10:09, Russell King - ARM Linux
wrote:
> On Mon, Oct 05, 2015 at 06:02:10PM +0100, Suzuki K. Poulose wrote:
>> +static int __init cpuinfo_regs_init(void)
>> +{
>> + int cpu, ret;
>> +
>> + for_each_present_cpu(cpu) {
>> + struct device *dev = get_cpu_device
On 21 September 2015 at 09:44, David Woods wrote:
>
> Steve,
Hi Dave,
>
> Thanks for your review and comments. I take your points about the 16k
> granule - it's helpful to know that support is in the works. However, I'm
> not sure I agree with your reading of section 4.4.2. It's clear that for
Hi Jeremy,
One quick comment for now below.
I ran into a problem testing this on my Seattle board, and needed the fix below.
Cheers,
--
Steve
On 16 September 2015 at 20:03, Jeremy Linton wrote:
> With 64k pages, the next larger segment size is 512M. The linux
> kernel also uses different protect
Hi David,
Some initial comments below.
Cheers,
--
Steve
On Tue, Sep 15, 2015 at 02:01:57PM -0400, David Woods wrote:
> The arm64 MMU supports a Contiguous bit which is a hint that the TTE
> is one of a set of contiguous entries which can be cached in a single
> TLB entry. Supporting this bit ad
On 15 September 2015 at 19:01, David Woods wrote:
> The arm64 MMU supports a Contiguous bit which is a hint that the TTE
> is one of a set of contiguous entries which can be cached in a single
> TLB entry. Supporting this bit adds new intermediate huge page sizes.
>
> The set of huge page sizes a
On 13 August 2015 at 12:34, Suzuki K. Poulose wrote:
> From: "Suzuki K. Poulose"
>
> Ensure that the selected page size is supported by the
> CPU(s).
>
> Cc: Mark Rutland
> Cc: Catalin Marinas
> Cc: Will Deacon
> Signed-off-by: Suzuki K. Poulose
> ---
> arch/arm64/include/asm/sysreg.h |6
itor are rejected too.
>
> System instructions are mostly enabled for stepping, except MSR/MRS
> accesses to "DAIF" flags in PSTATE, which are not safe for
> probing.
>
> Thanks to Steve Capper and Pratyush Anand for several suggested
> Changes.
>
> Signed-off-b
his commit updates the kprobe example code s.t. _do_fork is targeted
instead, and the examples work as expected.
Signed-off-by: Steve Capper
---
samples/kprobes/jprobe_example.c| 8
samples/kprobes/kprobe_example.c| 2 +-
samples/kprobes/kretprobe_example.c | 2 +-
3 files
On 11 August 2015 at 01:52, David Long wrote:
> From: Sandeepa Prabhu
>
> Add info prints in sample kprobe handlers for ARM64
>
> Signed-off-by: Sandeepa Prabhu
> ---
> samples/kprobes/kprobe_example.c | 8
> 1 file changed, 8 insertions(+)
I'm not going through this series backwards,
: Steve Capper
---
Hello,
This RFC is meant to sit on top of Suzuki's set at:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358990.html
On systems with different core types (for instance big.LITTLE systems),
we need to be *very* careful that the REVIDR and MIDR are both read
On 29 June 2015 at 19:16, William Cohen wrote:
> On 06/29/2015 01:25 PM, Steve Capper wrote:
>> On 15 June 2015 at 20:07, David Long wrote:
>>> From: William Cohen
>>>
>>> The trampoline code is used by kretprobes to capture a return from a probed
>&
On 29 June 2015 at 19:36, David Long wrote:
> On 06/29/15 13:23, Steve Capper wrote:
>>
>> On 15 June 2015 at 20:07, David Long wrote:
>>>
>>> From: "David A. Long"
>>>
>>> Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64.
&
On 15 June 2015 at 20:07, David Long wrote:
> From: William Cohen
>
> The trampoline code is used by kretprobes to capture a return from a probed
> function. This is done by saving the registers, calling the handler, and
> restoring the registers. The code then returns to the roginal saved call
On 15 June 2015 at 20:07, David Long wrote:
> From: Sandeepa Prabhu
>
> Kprobes needs simulation of instructions that cannot be stepped
> from different memory location, e.g.: those instructions
> that uses PC-relative addressing. In simulation, the behaviour
> of the instruction is implemented u
Hi David,
Some comments below.
On 15 June 2015 at 20:07, David Long wrote:
> From: "David A. Long"
>
> Certain instructions are hard to execute correctly out-of-line (as in
> kprobes). Test functions are added to insn.[hc] to identify these. The
> instructions include any that use PC-relative
cted too.
>
> System instructions are mostly enabled for stepping, except MSR/MRS
> accesses to "DAIF" flags in PSTATE, which are not safe for
> probing.
>
> Thanks to Steve Capper and Pratyush Anand for several suggested
> Changes.
>
> Signed-off-by: Sande
tion test functions in insn.c.
> 2) I removed the addition of orig_x0 to ptrace.h.
> 3) Reorder the patches.
> 4) Replace the previous interrupt disabling (from Will Cohen) with
> an improved solution (from Steve Capper).
>
> Changes since v4 include:
>
> 1) Added insn.c funct
On 15 June 2015 at 20:07, David Long wrote:
> From: "David A. Long"
>
> Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64.
>
> Signed-off-by: David A. Long
> ---
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/ptrace.h | 25 +
> arch/arm64/kernel/ptrace.c
On 9 June 2015 at 07:52, Hyuk Myeong wrote:
> This patch fix a spelling typo in the comment in pgtable-2level.h.
>
Hi Hyuk,
> Signed-off-by: Hyuk Myeong
> ---
> arch/arm/include/asm/pgtable-2level.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/p
On 26 May 2015 at 15:35, Christoffer Dall wrote:
> Hi Steve,
>
> On Tue, May 26, 2015 at 03:24:20PM +0100, Steve Capper wrote:
>> >> On Sun, May 24, 2015 at 09:34:04PM +0200, Christoffer Dall wrote:
>> >> > Hi all,
>> >> >
>> >>
On 26 May 2015 at 09:08, Christoffer Dall wrote:
> Hi Andrea,
>
> On Mon, May 25, 2015 at 04:15:25PM +0200, Andrea Arcangeli wrote:
>> Hello Christoffer,
>>
>> On Sun, May 24, 2015 at 09:34:04PM +0200, Christoffer Dall wrote:
>> > Hi all,
>> >
>> > I noticed a regression on my arm64 APM X-Gene sys
;> > powerpc, metag, sh, s390) do not?
>>
>> Potentially laziness/ignorance-of-feature? It looks like this feature
>> started on x86_64 and then spread
>> to arm*.
>
> Yes. In 3212b535f200c85b5a6 Steve Capper (ARM person) hoisted the code
> out of x86 into ge
vents filtered out events from being considered by
hist_entry_iter__add.
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Signed-off-by: Steve Capper
---
Hi,
This patch fixes my problem, but I don't know enough perf to
confidently state that this will work
/firmware/efi/libstub] Error 2
make: *** Waiting for unfinished jobs
This patch adjusts the arm64 Makefile to reference the compiled library
explicitly (as is currently done in x86), rather than the directory.
Fixes: f4f75ad5 efi: efistub: Convert into static library
Signed-off-by: Steve Capper
On 17 February 2015 at 23:11, David Long wrote:
> From: Sandeepa Prabhu
>
> Kprobes needs simulation of instructions that cannot be stepped
> from different memory location, e.g.: those instructions
> that uses PC-relative addressing. In simulation, the behaviour
> of the instruction is implement
>
> This patch should address the problem and is a fix to the mmotm patch
> mm-remove-remaining-references-to-numa-hinting-bits-and-helpers.patch
>
> Reported-by: Mark Brown
> Signed-off-by: Mel Gorman
Acked-by: Steve Capper
> ---
> include/linux/swapops.h | 2 +
On 28 January 2015 at 15:24, Mark Brown wrote:
> For at least the past couple of days tests of libhugetlbfs have been
> hanging on mustang in the mlock test running ARMv8 defconfig with both
> 32 bit and 64 bit userspace - after the mprotect test (the one before
> it) we get no console output for
On 28 January 2015 at 15:24, Mark Brown wrote:
> For at least the past couple of days tests of libhugetlbfs have been
> hanging on mustang in the mlock test running ARMv8 defconfig with both
> 32 bit and 64 bit userspace - after the mprotect test (the one before
> it) we get no console output for
On 8 January 2015 at 18:48, Ard Biesheuvel wrote:
> In order to support kexec, the kernel needs to be able to deal with the
> state of the UEFI firmware after SetVirtualAddressMap() has been called.
> To avoid having separate code paths for non-kexec and kexec, let's move
> the call to SetVirtualA
On Sat, Jan 10, 2015 at 11:03:20PM -0500, David Long wrote:
> From: Sandeepa Prabhu
>
> AArch64 ISA does not have instructions to pop the PC register
> value from the stack(like ARM v7 has ldmia {...,pc}) without using
> one of the general purpose registers. This means return probes
> cannot retu
insn.c.
> 2) I removed the addition of orig_x0 to ptrace.h.
> 3) Reorder the patches.
> 4) Replace the previous interrupt disabling (from Will Cohen) with
> an improved solution (from Steve Capper).
Hi David,
I've left feedback on the patches in the series.
I ran into two major is
lusive Monitor are rejected too.
>
> System instructions are mostly enabled for stepping, except MSR
> immediate that updates "daif" flags in PSTATE, which are not safe
> for probing.
>
> Changes since v3:
> from David Long:
> 1) Removed unnecessary addtion o
On Sat, Jan 10, 2015 at 11:03:16PM -0500, David Long wrote:
> From: "David A. Long"
>
> Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64.
>
> Signed-off-by: David A. Long
> ---
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/ptrace.h | 29 +
> arch/ar
On 9 January 2015 at 12:13, Mark Rutland wrote:
> On Thu, Jan 08, 2015 at 12:51:31PM +, Mark Langsdorf wrote:
>> On 01/05/2015 07:46 PM, Linus Torvalds wrote:
>> > It's a day delayed - not because of any particular development issues,
>> > but simply because I was tiling a bathroom yesterday.
On 12 December 2014 at 22:42, David Long wrote:
> On 12/10/14 11:38, Steve Capper wrote:
>>
>> On Tue, Dec 09, 2014 at 09:27:18AM -0500, David Long wrote:
>>>
>>> On 12/09/14 08:33, Steve Capper wrote:
>>>>
>>>> On Thu,
On Tue, Dec 09, 2014 at 09:27:18AM -0500, David Long wrote:
> On 12/09/14 08:33, Steve Capper wrote:
> >On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote:
[...]
> >
> >Not sure if this is helpful, but the following also caused a crash f
On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote:
> (2014/12/04 20:29), Steve Capper wrote:
>
> >> I'd like to ask you to try my fix on your machine, with my reproducing
> >> methods. (do not use sytemtap nor perf, those can have other issues)
&
On 4 December 2014 at 10:43, Masami Hiramatsu
wrote:
> (2014/12/04 19:21), Steve Capper wrote:
>> On 4 December 2014 at 02:48, David Long wrote:
>>> On 12/03/14 20:16, William Cohen wrote:
>>>
>>> [...]
>>>
>>>>
>>>> The p
On 4 December 2014 at 02:48, David Long wrote:
> On 12/03/14 20:16, William Cohen wrote:
>
> [...]
>
>>
>> The perf issue seems to be independent and can be reproduced without using
>> any kprobe support. I need to get a simple reproducer and mention it on the
>> linux-perf-user list.
>>
>> -Will
On 27 November 2014 at 06:07, Masami Hiramatsu
wrote:
> (2014/11/27 3:59), Steve Capper wrote:
>> The crash is extremely easy to reproduce.
>>
>> I've not observed any missed events on a kprobe on an arm64 system
>> that's still alive.
>> My (limited!
On 26 November 2014 at 17:46, David Long wrote:
> On 11/26/14 05:03, Steve Capper wrote:
>>
>> On Wed, Nov 26, 2014 at 05:33:05PM +0900, Masami Hiramatsu wrote:
>>>
>>> (2014/11/21 0:02), Steve Capper wrote:
>>>>
>>>> On Tue, Nov 18, 201
On Wed, Nov 26, 2014 at 05:33:05PM +0900, Masami Hiramatsu wrote:
> (2014/11/21 0:02), Steve Capper wrote:
> > On Tue, Nov 18, 2014 at 01:32:50AM -0500, David Long wrote:
> >> From: "David A. Long"
> >>
> >> This patchset is heavily based on Sandeep
n when the debug symbols have been correctly installed (and loaded
by perf).
This patch adds logic to dso__load_sym to query syms_ss for the
.debug_frame section if it can't be found in the elf file pointed to by
runtime_ss.
Signed-off-by: Steve Capper
---
This patch is against 3.18-rc5.
On Tue, Nov 18, 2014 at 01:32:50AM -0500, David Long wrote:
> From: "David A. Long"
>
> This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
> first
> seen in October 2013. This version attempts to address concerns raised by
> reviewers and also fixes problems discovered
On Wed, Oct 29, 2014 at 01:49:44PM +0530, Aneesh Kumar K.V wrote:
> Update generic gup implementation with powerpc specific details.
> On powerpc at pmd level we can have hugepte, normal pmd pointer
> or a pointer to the hugepage directory.
>
> Signed-off-by: Aneesh Kumar K.V
On Mon, Oct 27, 2014 at 06:43:27PM -0400, David Miller wrote:
> From: Andrew Morton
> Date: Mon, 27 Oct 2014 14:09:38 -0700
>
> > Perhaps sparc should be defining CONFIG_HAVE_GENERIC_RCU_GUP.
> >
> > We really should switch x86 to the generic version - from a quick read
> > it looks like it will
On Mon, Oct 27, 2014 at 06:32:41PM -0700, Andrew Morton wrote:
> On Tue, 28 Oct 2014 12:20:29 +1100 Michael Ellerman
> wrote:
>
> > On Mon, 2014-10-27 at 16:06 -0700, Andrew Morton wrote:
> > > On Sat, 25 Oct 2014 16:14:19 +0530 "Aneesh Kumar K.V"
> > > wrote:
> > >
> > > > Update generic gup
if (pgd_none(*pgdp))
> + if (pgd_none(pgd))
> break;
> - else if (!gup_pud_range(pgdp, addr, next, write, pages, &nr))
> + if (unlikely(pgd_huge(pgd))) {
> + if (!gup_huge_pte(__pte(pgd_val(pgd)
On 24 October 2014 00:40, Benjamin Herrenschmidt
wrote:
> On Thu, 2014-10-23 at 18:40 -0400, David Miller wrote:
>> Hey guys, was looking over the generic GUP while working on a sparc64
>> issue and I noticed that you guys do speculative page gets, and after
>> talking with Johannes Weiner (CC:'d)
t; mm/gup.c | 113
> +++
> 4 files changed, 84 insertions(+), 59 deletions(-)
>
Hi Aneesh,
Thanks for coding this up. I've tested this for arm (Arndale board) and
arm64 (Juno); it builds without any issues and passes my futex on THP
tail
On Thu, Oct 16, 2014 at 08:48:20PM +0530, Aneesh Kumar K.V wrote:
> Steve Capper writes:
>
> > On Wed, Oct 15, 2014 at 10:04:47PM +0530, Aneesh Kumar K.V wrote:
> >> Update generic gup implementation with powerpc specific details.
> >> On powerpc at pmd level w
.
Cheers,
--
Steve
>From 2fb7b0308f0aca94c50611257ba82d656abb0768 Mon Sep 17 00:00:00 2001
From: Steve Capper
Date: Thu, 16 Oct 2014 09:09:48 +0100
Subject: [PATCH] Fixup for Update generic gup implementation
The patch:
mm: Update generic gup implementation to handle hugepage directory
will
On Tue, Oct 14, 2014 at 05:38:43PM +0530, Aneesh Kumar K.V wrote:
> Steve Capper writes:
>
> > On Tue, Oct 14, 2014 at 04:27:53PM +0530, Aneesh Kumar K.V wrote:
> >> get_user_pages_fast attempts to pin user pages by walking the page
> >> tables directly and avoids
On Tue, Oct 14, 2014 at 04:27:53PM +0530, Aneesh Kumar K.V wrote:
> get_user_pages_fast attempts to pin user pages by walking the page
> tables directly and avoids taking locks. Thus the walker needs to be
> protected from page table pages being freed from under it, and needs
> to block any THP spl
On Thu, Sep 04, 2014 at 10:41:52AM +0100, Catalin Marinas wrote:
> Hi Zhichang,
>
> (cc'ing Steve Capper for the huge page stuff)
>
> On Fri, Aug 22, 2014 at 01:38:26PM +0100, zhichang.yuan wrote:
> > I am working to implement the DEBUG_PAGEALLOC on ARMv8.
>
>
; support.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Steve Capper
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Acked-by: Catalin Marinas
> Signed-off-by: Minchan Kim
Acked-by: Steve Capper
--
To unsubscribe from this list: send the line "uns
; support.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Steve Capper
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Minchan Kim
This patch looks good to me:
Acked-by: Steve Capper
There is another patch that introduces a helper function
; support.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Steve Capper
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Minchan Kim
> ---
> arch/arm/include/asm/pgtable-3level.h | 3 +++
> arch/arm64/include/asm/pgtable.h | 2 ++
; support.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Steve Capper
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Minchan Kim
> ---
> arch/arm64/include/asm/pgtable.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --
time).
> >
> > I'm happy for any fix which can be included in 3.16.
>
> Steve Capper made a point about performance. He'll follow up.
Hi :-).
My concern was initially about splitting THPs, as with a 64K granule,
we will have 2048 calls to set_pte_at in a loop. Having thou
On 15 May 2014 17:27, Mark Salter wrote:
> On Thu, 2014-05-15 at 15:44 +0100, Steve Capper wrote:
>> On Thu, May 15, 2014 at 10:19:22AM -0400, Mark Salter wrote:
>> > The following happens when trying to run a kvm guest on a kernel
>> > configured for 64k pages. This d
On Thu, May 15, 2014 at 10:19:22AM -0400, Mark Salter wrote:
> The following happens when trying to run a kvm guest on a kernel
> configured for 64k pages. This doesn't happen with 4k pages:
>
> BUG: failure at include/linux/mm.h:297/put_page_testzero()!
> Kernel panic - not syncing: BUG!
>
64_4_LEVELS
> +static inline void __pud_free_tlb(struct mmu_gather *tlb, pmd_t *pudp,
> + unsigned long addr)
The second parameter needs to be a pointer to pud_t ?
(this fires up a warning with STRICT_MM_TYPECHECKS).
With that and Christoffer's feedback about expanding the comments on
create_
On Fri, May 02, 2014 at 11:20:33AM -0400, Mark Salter wrote:
> As explained in more detail in the second patch, I have observed a soft
> lockup under some loads. These lockups were in flush_tlb_kernel_range()
> which was looping through a very large address range. While looking into
> this, I also
On Sun, Apr 27, 2014 at 12:37:35PM +0900, Jungseok Lee wrote:
> On Thursday, April 24, 2014 1:02 AM, Steve Capper wrote:
> > On Fri, Apr 18, 2014 at 04:59:20PM +0900, Jungseok Lee wrote:
[ ... ]
> >
> > This is overly complicated. For <4 levels we set x0 to be:
> &
On 24 April 2014 12:03, Russell King - ARM Linux wrote:
> On Thu, Apr 24, 2014 at 11:55:56AM +0100, Steve Capper wrote:
>> On 24 April 2014 11:42, Russell King - ARM Linux
>> wrote:
>> > On Thu, Apr 24, 2014 at 11:36:39AM +0100, Will Deacon wrote:
>> >> I
On 24 April 2014 11:42, Russell King - ARM Linux wrote:
> On Thu, Apr 24, 2014 at 11:36:39AM +0100, Will Deacon wrote:
>> I guess I'm after some commitment that this is (a) useful to somebody and
>> (b) going to be tested regularly, otherwise it will go the way of things
>> like big-endian, where
On Wed, Apr 16, 2014 at 12:46:38PM +0100, Steve Capper wrote:
> Hello,
> This series brings HugeTLB pages and Transparent Huge Pages (THP) to
> ARM on short descriptors.
>
> Russell, Andrew,
> I would like to get this in next (and hopefully 3.16 if no problems
> arise) if t
On Fri, Apr 18, 2014 at 04:59:20PM +0900, Jungseok Lee wrote:
> This patch implements 4 levels of translation tables since 3 levels
> of page tables with 4KB pages cannot support 40-bit physical address
> space described in [1] due to the following issue.
>
> It is a restriction that kernel logica
1 - 100 of 122 matches
Mail list logo
