From: Balbir Singh
I ran into this issue while debugging an early boot problem.
The system hit a BUG_ON() but report bug failed to print the
line number and file name. The reason being that the system
was running in real mode and report_bug() searches for
addresses in the PAGE_OFFSET+ region
bug failed to print the
line number and file name. The reason being that the system
was running in real mode and report_bug() searches for
addresses in the PAGE_OFFSET+ region
Suggested-by: Paul Mackerras
Signed-off-by: Balbir Singh
---
arch/powerpc/kernel/traps.c | 7 ++-
1 file changed,
eason being that the system
was running in real mode and report_bug() searches for
addresses in the PAGE_OFFSET+ region
Suggested-by: Paul Mackerras
Signed-off-by: Balbir Singh
---
arch/powerpc/kernel/traps.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/k
at the system
>> was running in real mode and report_bug() searches for
>> addresses in the PAGE_OFFSET+ region
>>
>> Suggested-by: Paul Mackerras
>> Signed-off-by: Balbir Singh
> Can we add some comments around this. When i looked at this first, i was
>
system
was running in real mode and report_bug() searches for
addresses in the PAGE_OFFSET+ region
Suggested-by: Paul Mackerras
Signed-off-by: Balbir Singh
---
arch/powerpc/kernel/traps.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/traps.c b/ar
e/asm/{pte-hash64.h => book3s/64/hash.h} (100%)
Why not pte-hash.h?
Balbir Singh.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Tue, 2015-12-01 at 09:06 +0530, Aneesh Kumar K.V wrote:
> Keep it seperate to make rebasing easier
>
> Acked-by: Scott Wood
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/include/asm/book3s/32/pgtable.h | 6 +++---
> arch/powerpc/include/asm/book3s/64/pgtable.h | 6 +++---
> arch/pow
On 01/12/15 14:36, Aneesh Kumar K.V wrote:
> This further make a copy of pte defines to book3s/64/hash*.h. This
> remove the dependency on pgtable-ppc64-4k.h and pgtable-ppc64-64k.h
>
> Acked-by: Scott Wood
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/include/asm/book3s/64/hash-4k.h
to the page table for the process.
> - * We use it to ensure coherency between the i-cache and d-cache
> - * for the page which has just been mapped in.
> - * On machines which use an MMU hash table, we use this to put a
> - * corresponding HPTE into the hash table ahead of time, instead of
> - * waiting for the inevitable extra hash-table miss exception.
> - */
> -extern void update_mmu_cache(struct vm_area_struct *, unsigned long, pte_t
> *);
> -
> -extern int gup_hugepte(pte_t *ptep, unsigned long sz, unsigned long addr,
> -unsigned long end, int write,
> -struct page **pages, int *nr);
> -#ifndef CONFIG_TRANSPARENT_HUGEPAGE
> -#define pmd_large(pmd) 0
> -#define has_transparent_hugepage() 0
> -#endif
> -pte_t *__find_linux_pte_or_hugepte(pgd_t *pgdir, unsigned long ea,
> -bool *is_thp, unsigned *shift);
> -static inline pte_t *find_linux_pte_or_hugepte(pgd_t *pgdir, unsigned long
> ea,
> -bool *is_thp, unsigned *shift)
> -{
> - if (!arch_irqs_disabled()) {
> - pr_info("%s called with irq enabled\n", __func__);
> - dump_stack();
> - }
> - return __find_linux_pte_or_hugepte(pgdir, ea, is_thp, shift);
> -}
Where's this function gone?
>
Balbir Singh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
default "9" if PPC64 && PPC_64K_PAGES
> range 13 64 if PPC64 && !PPC_64K_PAGES
Should this be fixed as well?
range 9 13?
> default "13" if PPC64 && !PPC_64K_PAGES
Please check my calculations
Reviewed-by: Balbir Singh
Balbir Singh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ble) or
> 8 (64K hash or no hash 64K pgtable).
> Thus a min value of 8 for 64K pages and 9 for 4K pages is reasonable.
>
> So, update the range of FORCE_MAX_ZONEORDER from 9-64 to 8-9 for 64K pages
> and from 13-64 to 9-13 for 4K pages.
>
> Signed-off-by: Rashmica Gup
On 19/02/16 03:44, Aneesh Kumar K.V wrote:
> We can get a hash pte fault with 4k base page size and find the pte
> already inserted with 64K base page size. In that case we need to clear
> the existing slot information from the old pte. Fix this correctly
>
> With THP, we also clear the slot infor
On 24/02/16 04:00, Torsten Duwe wrote:
> On Wed, Feb 17, 2016 at 02:08:41PM +1100, Michael Ellerman wrote:
>> That stub uses r2 to find the location of itself, but it only works if r2
>> holds
>> the TOC for scsi_mod.ko. In this case r2 still contains ibmvscsi.ko's TOC.
> Here's my solution, a b
o_handler+0x0/0x58 (inet_sendmsg+0xd8/0x100)'
[ 77.185342] b'[c0003e8c7e30] [c0009f7c]
return_to_handler+0x0/0x58 (sock_sendmsg+0x38/0x60)'
[ 77.185416] b'Instruction dump:'
[ 77.185469] b'6000 4bfe3b89 6000 e8610020 38210030 e8010010 7c0803a6
4b40 '
[ 77.185566] b'6042 3c4c00fa 3842e750 3d220015 <88695e30> 4e800020
6000 6000 '
[ 77.185668] b'---[ end trace 78e882547ec0a563 ]---'
[ 79.191159] b'Kernel panic - not syncing: Fatal exception in interrupt'
Warm Regards,
Balbir Singh.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 24/02/16 20:23, Torsten Duwe wrote:
> On Wed, Feb 24, 2016 at 05:55:35PM +1100, Balbir Singh wrote:
>>
>>
>> We need to remove the SQUASH_TOC_SAVE_INSNS bits as well, now that the
>> ppc64_profile_stub_insns does not save r2
> Sure -- this was meant to _repla
--
> 1 file changed, 14 insertions(+), 16 deletions(-)
>
> Squash.
>
>
Do we even need to do this anymore?
Balbir Singh.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
tub multiple times.
This makes sense
Reviewed-by: Balbir Singh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
+int module_trampoline_target(struct module *mod, unsigned long addr,
> + unsigned long *target)
> {
> - unsigned int i;
> - u32 insns[ARRAY_SIZE(ppc64_stub_insns)];
> -
> - BUILD_BUG_ON(sizeof(ppc64_stub_
t;magic = STUB_MAGIC;
> +
> + return (unsigned long)entry;
> +}
> +
> int module_finalize_ftrace(struct module *mod, const Elf_Shdr *sechdrs)
> {
> mod->arch.toc = my_r2(sechdrs, mod);
> - mod->arch.tramp = stub_for_addr(sechdrs, (unsigned long)ftrace_caller,
> mod);
> + mod->arch.tramp = create_ftrace_stub(sechdrs, mod);
>
> if (!mod->arch.tramp)
> return -ENOENT;
Reviewed-by: Balbir Singh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
> + */
> + return 1;
> + }
> + return 0;
> +}
> +#else
> +/* without -mprofile-kernel, mcount calls are never early */
> +static int is_early_mcount_callsite(u32 *instruction)
> +{
> + return 0;
> +}
> +#endif
> +
> /* We expect a
mflrr3 /* ftrace_caller has restored LR from stack */
> @@ -1262,6 +1267,9 @@ _GLOBAL(ftrace_graph_caller)
> ld r4, 56(r1)
> ld r3, 48(r1)
>
> + /* Restore callee's TOC */
> + ld r2, 24(r1)
> +
> addi
On 25/02/16 01:28, Michael Ellerman wrote:
> From: Torsten Duwe
>
> Implement FTRACE_WITH_REGS for powerpc64, on ELF ABI v2.
> Initial work started by Vojtech Pavlik, used with permission.
>
> * arch/powerpc/kernel/entry_64.S:
> - Implement an effective ftrace_caller that works from
>
*/
> - mtlrr12
> - mr r2,r0 /* restore callee's TOC */
> + /* Restore original LR for return to B */
> + ld r0, LRSAVE(r1)
> + mtlrr0
>
> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
> stdur1, -112(r1)
> @@ -1240,9 +1273,6 @@ _GLOBAL(ftrace_graph_stub)
> addir1, r1, 112
> #endif
>
> - mflrr0 /* move this LR to CTR */
> - mtctr r0
> -
> ld r0,LRSAVE(r1) /* restore callee's lr at _mcount site */
> mtlrr0
> bctr/* jump after _mcount site */
Reviewed-by: Balbir Singh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
; - else if (command & FTRACE_STOP_FUNC_RET)
> - ftrace_disable_ftrace_graph_caller();
> + ftrace_modify_all_code(command);
> }
>
> int __init ftrace_dyn_arch_init(void)
Reviewed-by: Balbir Singh
Balbir
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 25/02/16 01:28, Michael Ellerman wrote:
> From: Torsten Duwe
>
> * arch/powerpc/Makefile:
> - globally use -mprofile-kernel in case it's configured,
> available and bug-free.
> * arch/powerpc/gcc-mprofile-kernel-notrace.sh:
> - make sure -mprofile-kernel works and has none of
FLAGS_REMOVE_code-patching.o = -pg -mprofile-kernel
> +CFLAGS_REMOVE_feature-fixups.o = -pg -mprofile-kernel
>
> obj-y += string.o alloc.o crtsavres.o ppc_ksyms.o code-patching.o \
>feature-fixups.o
Reviewed-by: Balbir Singh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 25/02/16 10:55, Balbir Singh wrote:
>
> On 25/02/16 01:28, Michael Ellerman wrote:
>> Currently we generate the module stub for ftrace_caller() at the bottom
>> of apply_relocate_add(). However apply_relocate_add() is potentially
>> called more than once per module, wh
2MB for
> Radix model. Hence make HPAGE_PMD related values as a variable.
>
> Actual conversion of HPAGE_PMD to a variable for ppc64 happens in a
> followup patch.
>
> [1] http://ibm.biz/power-isa3 (Needs registration).
>
> Signed-off-by: K
ge only code movement.
>>
>> Signed-off-by: Aneesh Kumar K.V
> Reviewed-by: Paul Mackerras
>
> We may end up using a big-endian Linux page table even on hash,
> for the sake of simplicity.
>
Doesn't the series you posted, do that? Assuming
On 23/02/16 15:48, Aneesh Kumar K.V wrote:
> We remove real_pte_t out of STRICT_MM_TYPESCHECK.
>
> Signed-off-by: Aneesh Kumar K.V
>
The changelog does not explain why
Balbir
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozl
. https://patchwork.ozlabs.org/patch/587464/
Signed-off-by: Torsten Duwe
Signed-off-by: Balbir Singh
---
arch/powerpc/Kconfig| 3 ++
arch/powerpc/gcc-mprofile-kernel-notrace.sh | 7
arch/powerpc/include/asm/livepatch.h| 61 +
arch
ng set)
> {
> -
> - unsigned long old, tmp;
> + pmd_t pmd;
> + unsigned long old_pmd, new_pmd;
>
> #ifdef CONFIG_DEBUG_VM
> WARN_ON(!pmd_trans_huge(*pmdp));
> assert_spin_locked(&mm->page_table_lock);
> #endif
> -
> -#ifdef PTE_ATOMIC_UPDATES
> -
On 29/02/16 12:59, Balbir Singh wrote:
>
> On 26/02/16 14:53, Aneesh Kumar K.V wrote:
>> This enables us to share the same page table code for
>> both radix and hash. Radix use a hardware defined big endian
> ^uses
>> page table
>>
tested the sample in the livepatch
directory
References
1. https://patchwork.ozlabs.org/patch/581521/
2. https://patchwork.ozlabs.org/patch/587464/
Signed-off-by: Torsten Duwe
Signed-off-by: Balbir Singh
---
arch/powerpc/Kconfig | 3 ++
arch/powerpc/include/asm/livepatch.h | 41
Signed-off-by: Balbir Singh
---
arch/powerpc/Kconfig | 3 ++
arch/powerpc/include/asm/livepatch.h | 41 +++
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/kernel/entry_64.S | 50 +
arch/powerpc/kernel/kgdb.c
On 03/03/16 23:46, Balbir Singh wrote:
> Changelog v3:
> 1. Removed spurious kgdb patch
> 2. Moved -ENOSYS to -EINVAL in klp_write_module_reloc
> 3. Moved klp_matchaddr to use ftrace_location_range
>
Please ignore -- wrong
livepatch with ftrace_location_range.
I tested the sample in the livepatch
References
1. https://patchwork.ozlabs.org/patch/581521/
Signed-off-by: Torsten Duwe
Signed-off-by: Balbir Singh
---
arch/powerpc/Kconfig | 3 ++
arch/powerpc/include/asm/livepatch.h | 41
On 4 Mar 2016 03:52, "Petr Mladek" wrote:
>
> From: Balbir Singh
>
> Changelog v4:
> 1. Renamed klp_matchaddr() to klp_get_ftrace_location()
>and used it just to convert the function address.
> 2. Synced klp_write_modu
erman
>
Reviewed-by: Balbir Singh
Balbir
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
odule
>stub when calling mcount with the new ABI.
>
> Signed-off-by: Torsten Duwe
> Signed-off-by: Michael Ellerman
> ---
>
Reviewed-by: Balbir Singh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
s on the stack, the extra stack frame needs to
> be accounted for.
>
> Where shall we put this warning?
Good catch! We should just document it in livepatch.c (I suppose). I wonder if
we can reuse the previous stack frame -- the caller into ftrace_caller. I think
our arch.trampoline does bunch of the work anyway, klp_return_helper would just
need to restore the right set of values
I hope I am thinking clearly on a Monday morning
Balbir Singh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
lun. I'll post out that sample if there
is interest later. I also tested ftrace functionality on the
command line to check for breakage
Signed-off-by: Torsten Duwe
Signed-off-by: Balbir Singh
Signed-off-by: Petr Mladek
---
arch/powerpc/Kconfig | 3 ++
arch/powerpc/inc
On 08/03/16 21:45, Torsten Duwe wrote:
> On Tue, Mar 08, 2016 at 06:33:57PM +1100, Balbir Singh wrote:
>> Changelog v5:
>> 1. Removed the mini-stack frame created for klp_return_helper.
>> As a result of the mini-stack frame, function with > 8
>>
ut 8GB before calling
deferred init?
Don't we need at-least 32GB + space for other early hash allocations
BTW, My expectation was that 32TB would imply 32GB+32GB of large hash
allocations early on
Balbir Singh.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 09/03/16 03:02, Petr Mladek wrote:
> On Tue 2016-03-08 18:33:57, Balbir Singh wrote:
>> Changelog v5:
>> 1. Removed the mini-stack frame created for klp_return_helper.
>> As a result of the mini-stack frame, function with > 8
>> arguments
On 09/03/16 02:34, Torsten Duwe wrote:
> On Wed, Mar 09, 2016 at 12:52:03AM +1100, Balbir Singh wrote:
>> On 08/03/16 21:45, Torsten Duwe wrote:
>>> To be fair, my last mail still was not 100% correct, but the conclusion
> Wrote a correction to the correction. It should be
On 09/03/16 15:17, Li Zhang wrote:
> On Tue, Mar 8, 2016 at 10:45 PM, Balbir Singh wrote:
>>
>> On 08/03/16 14:55, Li Zhang wrote:
>>> From: Li Zhang
>>>
>>> Uptream has supported page parallel initialisation for X86 and the
>>> boot time
also tested ftrace functionality on the
command line to check for breakage
Signed-off-by: Torsten Duwe
Signed-off-by: Balbir Singh
Signed-off-by: Petr Mladek
---
arch/powerpc/Kconfig | 3 ++
arch/powerpc/include/asm/livepatch.h | 47 +++
arch/powerpc/kernel/Makefile
On 09/03/16 20:19, Torsten Duwe wrote:
> On Wed, Mar 09, 2016 at 05:59:40PM +1100, Balbir Singh wrote:
>> The previous revision was nacked by Torsten, but compared to the alternatives
> I nacked it because I was confident it couldn't work. Same goes
> for this one, sorry. M
Hopefully I'll get a chance over the weekend.
Have you tested this against Petr's sample changes to patch printk?
Balbir Singh.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 15/03/16 12:27, Jiri Kosina wrote:
> On Mon, 14 Mar 2016, Michael Ellerman wrote:
>
>>> Move the logic to work out the kernel toc pointer into a header. This is
>>> a good cleanup, and also means we can use it elsewhere in future.
>>>
>>> Reviewed-by: Kamalesh Babulal
>>> Reviewed-by: Torsten
hing in mind?
> Can you give us a hint?
>
>
We need extra space in the stack, it can be on top of the stack with a pointer
in PACA, we could use a fixed set size stack for only LR restore, if required
TOC restore, but I think we only need LR space
Balbir Singh.
in the git history.
and older kernels :)
>
> Signed-off-by: Michael Ellerman
>
Makes sense, given that none of the code is exercised, it makes sense to remove
it or keep it tested and updated. Removal makes more sense
Acked-by: Balbir Singh
_
s soon - hopefully
tonight, but we have a long weekend coming up, so there might be delays. In the
meanwhile feel free to add my signed-off-by for the CR+4 code. I am also
looking at a different approach -- per thread lr0 stack.
Balbir Singh.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
probably have
CONFIG_SCSI=y, make it M or you can fix the code yourself. I had the
same issue while testing
BTW, the tests worked fine with the changes proposed by Michael.
Balbir Singh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://l
orms. However,
> I don't have machine for testing. So that would be something later
> when I have hardware to test.
>
Balbir Singh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 24/03/16 22:04, Michael Ellerman wrote:
> In order to support live patching we need to maintain an alternate
> stack of TOC & LR values. We use the base of the stack for this, and
> store the "live patch stack pointer" in struct thread_info.
>
> Unlike the other fields of thread_info, we can n
>> At this point ti->livepatch_sp points to the next CPUs thread_info for
>> softirq_ctx?
> Sorry I'm not sure what you mean.
>
> None of this relates to the current CPUs thread info.
Oh! I meant that klp_init_thread_info points to the end of (struct thread_info
{} + 1) in the stack of the threa
f the kernel pagetables to a
> + debugfs file. This is only useful for kernel developers who are
> + working in architecture specific areas of the kernel - probably
> + not a good idea to enable this feature in a production kernel.
> +
> + If you are unsure, say
_psize);
> +}
> +
> +static void walk_pagetables(struct pg_state *st)
> +{
> + pgd_t *pgd = pgd_offset_k(0UL);
> + unsigned i;
> + unsigned long addr;
> +
> + /* Traverse the linux pagetable structure and dump pages that are in
> + * the hash pagetable.
> + */
> + for (i = 0; i < PTRS_PER_PGD; i++, pgd++) {
> + addr = VMALLOC_START + i * PGDIR_SIZE;
> + if (!pgd_none(*pgd))
> + /* pgd exists */
> + walk_pud(st, pgd, addr);
> + }
> +}
> +
> +static void walk_vmemmap(struct pg_state *st)
> +{
> + struct vmemmap_backing *ptr = vmemmap_list;
> +
> + /* Traverse the vmemmaped memory and dump pages that are in the hash
> + * pagetable.
> + */
> + while (ptr->list) {
> + hpte_find(st, ptr->virt_addr, mmu_vmemmap_psize);
> + ptr = ptr->list;
> + }
> + seq_puts(st->seq, "---[ vmemmap end ]---\n");
> +}
> +
> +static int ptdump_show(struct seq_file *m, void *v)
> +{
> + struct pg_state st = {
> + .seq = m,
> + .start_address = PAGE_OFFSET,
> + .marker = address_markers,
> + };
> + /* Traverse the 0xc, 0xd and 0xf areas of the kernel virtual memory and
> + * dump pages that are in the hash pagetable.
> + */
> + walk_linearmapping(&st);
> + walk_pagetables(&st);
> + walk_vmemmap(&st);
> + return 0;
> +}
> +
> +static int ptdump_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, ptdump_show, NULL);
> +}
> +
> +static const struct file_operations ptdump_fops = {
> + .open = ptdump_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release= single_release,
> +};
> +
> +
> +static int ptdump_init(void)
> +{
> + struct dentry *debugfs_file;
> +
> + debugfs_file = debugfs_create_file("kernel_hash_pagetable", 0400,
> + NULL, NULL, &ptdump_fops);
> + return debugfs_file ? 0 : -ENOMEM;
> +}
> +device_initcall(ptdump_init);
Otherwise (also check the _PAGE_COMBO build failure reports)
Acked-by: Balbir Singh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 27/03/16 19:23, Aneesh Kumar K.V wrote:
> This enables us to share the same page table code for
> both radix and hash. Radix use a hardware defined big endian
> page table
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/include/asm/book3s/64/hash.h | 16 +++--
> arch/powerpc/inclu
On 27/03/16 19:23, Aneesh Kumar K.V wrote:
> This split _PAGE_RW bit to _PAGE_READ and _PAGE_WRITE. It also remove
> the dependency on _PAGE_USER for implying read only. Few things to note
> here is that, we have read implied with write and execute permission.
> Hence we should always find _PAGE_
On 27/03/16 19:23, Aneesh Kumar K.V wrote:
> Subpage protection used to depend on _PAGE_USER bit to implement no
> access mode. This patch switch that to use _PAGE_RWX. We clear READ,
> Write and Execute access from pte instead of clearing _PAGE_USER now.
> This was done so that we can switch to
(!pte_present(pte) || !(pte_val(pte) & _PAGE_USER))
> + if (!pte_present(pte) || !pte_user(pte))
> goto err_out;
> pfn = pte_pfn(pte);
> if (!page_is_ram(pfn))
Makes sense
Acked-by: Balbir Singh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
---
> arch/powerpc/include/asm/livepatch.h | 8
> arch/powerpc/include/asm/thread_info.h | 4 +++-
> arch/powerpc/kernel/irq.c | 3 +++
> arch/powerpc/kernel/process.c | 6 +-
> arch/powerpc/kernel/setup_64.c | 17 ++---
> 5 f
egular stack, and is used to store the TOC & LR when
> calling a live patched function.
>
> When the patched function returns, we retrieve the real LR & TOC from
> the livepatch stack, restore them, and pop the livepatch "stack frame".
>
> Signed-off-by: Michael Eller
On 05/04/16 00:55, Aneesh Kumar K.V wrote:
> Balbir Singh writes:
>
>> [ text/plain ]
>>
>>
>> On 27/03/16 19:23, Aneesh Kumar K.V wrote:
>>> This split _PAGE_RW bit to _PAGE_READ and _PAGE_WRITE. It also remove
>>> the dependency on _PAGE
On 05/04/16 00:59, Aneesh Kumar K.V wrote:
> Balbir Singh writes:
>
>> [ text/plain ]
>>
>>
>> On 27/03/16 19:23, Aneesh Kumar K.V wrote:
>>> Subpage protection used to depend on _PAGE_USER bit to implement no
>>> access mode. This patch switch
apping. This means the area
> can be accessed by user space, but kernel will never return such an
> address to user space.
>
> But we can do better by implementing a read only kernel mapping using
> PPP bits 0b110
Looks good!
Acked-by: Balbir Singh
_
On 27/03/16 19:23, Aneesh Kumar K.V wrote:
> Use helper instead of opencoding with constants. Later patch will
> drop the WIMG bits and use PowerISA 3.0 defines
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/kernel/btext.c | 2 +-
> arch/powerpc/kernel/isa-bridge.c | 4 ++--
> ar
On 27/03/16 19:23, Aneesh Kumar K.V wrote:
> PowerISA 3.0 introduce two pte bits with the below meaning w.r.t Radix
> 00 -> Normal Memory
> 01 -> Strong Access Order
> 10 -> Non idempotent I/O (Cache inhibited and guarded)
> 11 -> Tolerant I/O (Cache inhibited)
>
> We drop the existing WIMG bit
;
Make sense, what happens to the HPTE variant?
Balbir Singh.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 27/03/16 19:23, Aneesh Kumar K.V wrote:
> The radix variant is going to require a flush_tlb_range. With
> flush_tlb_range added, ptep_clear_flush_young is same as the generic
> version. So drop the powerpc specific variant
>
> Signed-off-by: Aneesh Kumar K.V
>
The changelog is same as 11/65..
On 27/03/16 19:23, Aneesh Kumar K.V wrote:
> We also add mach dep call back for updating partition table entry.
The changelog needs to be enhanced.
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/include/asm/book3s/64/mmu.h | 31 +--
> arch/powerpc/include/asm
larify.
> 3. perf probe failure with kretprobe when using kallsyms. This was
> failing as we were specifying an offset. This is fixed in patch 1.
>
Balbir Singh.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
_MASK flag sounds more appropriate than the other one
> in the context. Hence change it back.
>
> Signed-off-by: Anshuman Khandual
Acked-by: Balbir Singh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 07/04/16 15:37, Anshuman Khandual wrote:
> Currently the config ARCH_WANT_GENERAL_HUGETLB enabled functions like
> 'huge_pte_alloc' and 'huge_pte_offset' dont take into account HugeTLB
> page implementation at the PGD level. This is also true for functions
> like 'follow_page_mask' which is ca
On 07/04/16 15:37, Anshuman Khandual wrote:
> follow_huge_(pmd|pud|pgd) functions are used to walk the page table and
> fetch the page struct during 'follow_page_mask' call. There are possible
> race conditions faced by these functions which arise out of simultaneous
> calls of move_pages() and f
On Thu, 2016-04-07 at 14:56 +0530, Naveen N. Rao wrote:
> On 2016/04/07 06:19PM, Balbir Singh wrote:
> >
> >
> > On 06/04/16 22:32, Naveen N. Rao wrote:
> > >
> > > This patchset fixes three issues found with perf probe on ppc64le:
> > > 1.
On 09/04/16 16:13, Aneesh Kumar K.V wrote:
> We also add mach dep call back for updating partition table entry.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/include/asm/book3s/64/mmu.h | 31 +--
> arch/powerpc/include/asm/machdep.h | 1 +
> arch/p
SHIFT - 12));
> +
> +}
> +
> static void __init htab_initialize(void)
> {
> unsigned long table;
> @@ -742,8 +777,11 @@ static void __init htab_initialize(void)
> /* Initialize the HPT with no entries */
&
pgd_populate(&init_mm, pgdp, pudp);
> - }
> -#endif /* PUD_TABLE_SIZE */
> - pudp = pud_offset(pgdp, ea);
> - if (pud_none(*pudp)) {
> - pmdp = early_alloc_pgtable(PMD_TABLE_SIZE);
> - BUG_ON(pmdp == NULL);
>
On 09/04/16 16:13, Aneesh Kumar K.V wrote:
> I am splitting this as a separate patch to get better review. If ok
> we should merge this with previous patch.
>
> Signed-off-by: Aneesh Kumar K.V
I think the merge makes more sense
Balbir
___
Linuxppc-de
On 11/04/16 15:39, Anshuman Khandual wrote:
> On 04/07/2016 02:56 PM, Balbir Singh wrote:
>>
>> On 07/04/16 15:37, Anshuman Khandual wrote:
>>>> follow_huge_(pmd|pud|pgd) functions are used to walk the page table and
>>>> fetch the page struct during
On 07/04/16 15:37, Anshuman Khandual wrote:
> Currently the function 'huge_pte_alloc' has got two versions, one for the
> BOOK3S server and the other one for the BOOK3E embedded platforms. This
> change splits only the BOOK3S server version into two parts, one for the
> ARCH_WANT_GENERAL_HUGETLB
/book3s/64/hash-64k.h
> +++ b/arch/powerpc/include/asm/book3s/64/hash-64k.h
> @@ -1,34 +1,14 @@
> #ifndef _ASM_POWERPC_BOOK3S_64_HASH_64K_H
> #define _ASM_POWERPC_BOOK3S_64_HASH_64K_H
>
> -#define PTE_INDEX_SIZE 8
> -#define PMD_INDEX_SIZE 5
> -#define PUD_INDEX_SIZE 5
> -#define PGD_INDEX_SIZE 12
> -
Each PMD is 16M
Each PUD is 512M
Each PGD is 16G
Looks good! We need some more comments eventually :)
Balbir Singh.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 12/04/16 14:38, Oliver O'Halloran wrote:
> POWER ISA v3 adds large decrementer (LD) mode of operation which increases
> the size of the decrementer register from 32 bits to an implementation
> defined with of up to 64 bits.
>
> This patch adds support for the LD on processors with the CPU_FTR
On 12/04/16 14:38, Oliver O'Halloran wrote:
> Power ISAv3 extends the width of the decrementer register from 32 bits.
> The enlarged register width is implementation dependent, but reads from
> these registers are automatically sign extended to produce a 64 bit output
> when operating in large mo
ms in patch 1 and for symbol table in patch 2.
> 3. perf probe failure with kretprobe when using kallsyms. This was
> failing as we were specifying an offset. This is fixed in patch 1.
>
> A few examples demonstrating the issues and the fix:
>
Given the choic
(policy->cpu);
> + del_timer_sync(&gpstates->timer);
> + kfree(policy->driver_data);
> + pr_info("freed driver_data cpu %d\n", base);
> return 0;
> }
>
> @@ -456,6 +674,7 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_po
On 09/04/16 16:13, Aneesh Kumar K.V wrote:
> Only code movement. No functionality change.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/include/asm/book3s/64/pgtable.h | 142
> +--
> 1 file changed, 71 insertions(+), 71 deletions(-)
A
esult as possible on ppc64 would be
> appreciated.
Thanks, do we have a summary of what the relocation changes look like?
Balbir Singh.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
mpile error.
>>>
>> ...
>>> So, update the range of FORCE_MAX_ZONEORDER from 9-64 to 8-9 for 64K pages
>>> and from 13-64 to 9-13 for 4K pages.
>>>
>>> Signed-off-by: Rashmica Gupta
>>> Reviewed-by: Balbir Singh
>>
>&
>>> + if (htab_bolt_mapping(ea, ea + PAGE_SIZE, pa, flags,
>>> + mmu_io_psize, mmu_kernel_ssize)) {
>>> + printk(KERN_ERR "Failed to do bolted mapping IO "
>>> + "memory at %016lx !\n", pa);
>>> +
On 17/04/16 20:27, Aneesh Kumar K.V wrote:
> Balbir Singh writes:
>
>>> index 2f818cbd8aa6..dcb9d6e94a0c 100644
>>> --- a/arch/powerpc/include/asm/book3s/64/hash-4k.h
>>> +++ b/arch/powerpc/include/asm/book3s/64/hash-4k.h
>>> @@ -5,48 +5,20 @@
>&
On 09/04/16 16:13, Aneesh Kumar K.V wrote:
> This add PowerISA 3.0 specific pte defines. We share most of the
> details with hash linux page table format. This patch indicate only
> things where we differ
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> arch/powerpc/include/asm/book3s/64/pgtable.h
Should we wait for Aneesh's patches before merging this in. I like the reduction
in the definition of page level metadata so for that
Acked-by: Balbir Singh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 09/04/16 16:13, Aneesh Kumar K.V wrote:
> In this patch we add the radix Kconfig and conditional check.
> radix_enabled is written to always return 0 here. Once we have
> all needed radix changes added, we will update this to mmu_feature
> check.
>
> We need to addt this early so that we can
On 09/04/16 16:13, Aneesh Kumar K.V wrote:
> For those pte accessors, that operate on a different set of pte bits
> between hash/radix, we add a generic variant that does a conditional
> to hash linux or radix variant.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
Looks good!
Balbir
_
a way that we can optimize away code block at build time
> + * if CONFIG_HUGETLB_PAGE=n.
> + */
> +static inline int pmd_huge(pmd_t pmd)
> +{
> + /*
> + * leaf pte for huge page
> + */
> + return !!(pmd_val(pmd) & _PAGE_PTE);
> +}
> +
> +static inline int pud_huge(pud_t pud)
> +{
> + /*
> + * leaf pte for huge page
> + */
> + return !!(pud_val(pud) & _PAGE_PTE);
> +}
> +
> +static inline int pgd_huge(pgd_t pgd)
> +{
> + /*
> + * leaf pte for huge page
> + */
> + return !!(pgd_val(pgd) & _PAGE_PTE);
> +}
> +#define pgd_huge pgd_huge
> +
??
Balbir Singh.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
1 - 100 of 1079 matches
Mail list logo
