Re: [PATCH 2/2] ppc64le save_stack_trace_tsk_reliable (Was: HAVE_RELIABLE_STACKTRACE)

trace->skip--; > + > + if (newsp > stack_page + THREAD_SIZE - STACK_FRAME_OVERHEAD) > + break; /* hit the window for last frame */ > + > + if (trace->nr_entries >= trace->max_entries) > + return -E2BIG; > + > + sp = newsp; > + } > + return 0; > +} > +#endif /* CONFIG_HAVE_RELIABLE_STACKTRACE */ > Looks good to me otherwise. Acked-by: Balbir Singh <bsinghar...@gmail.com>

Re: [PATCH 2/2] ppc64le save_stack_trace_tsk_reliable (Was: HAVE_RELIABLE_STACKTRACE)

if (newsp > stack_page + THREAD_SIZE - STACK_FRAME_OVERHEAD) > + break; /* hit the window for last frame */ > + > + if (trace->nr_entries >= trace->max_entries) > + return -E2BIG; > + > + sp = newsp; > + } > + return 0; > +} > +#endif /* CONFIG_HAVE_RELIABLE_STACKTRACE */ > Looks good to me otherwise. Acked-by: Balbir Singh

Re: [PATCH v2] xmon: Setup xmon debugger hooks when first break-point is set

oint trap > > To fix this the patch checks and enables debugger hooks when an > instruction or data break-point is set via xmon console. > > Signed-off-by: Vaibhav Jain <vaib...@linux.vnet.ibm.com> > --- Reviewed-by: Balbir Singh <bsinghar...@gmail.com>

Re: [PATCH v2] xmon: Setup xmon debugger hooks when first break-point is set

tch checks and enables debugger hooks when an > instruction or data break-point is set via xmon console. > > Signed-off-by: Vaibhav Jain > --- Reviewed-by: Balbir Singh

Re: [PATCH] xmon: Clear all breakpoints when xmon is disabled via debugfs

...@linux.vnet.ibm.com> > --- Reviewed-by: Balbir Singh <bsinghar...@gmail.com> Balbir

Re: [PATCH] xmon: Clear all breakpoints when xmon is disabled via debugfs

d. > > Hence this patch introduces a new function named clear_all_bpt() > which is called when xmon is disabled via debugfs. The function will > unpatch/clear all the trap and ciabr/dab based breakpoints. > > Signed-off-by: Vaibhav Jain > --- Reviewed-by: Balbir Singh Balbir

Re: [PATCH v12 22/22] selftests/vm: Fix deadlock in protection_keys.c

1, args) But both are equivalent I guess, so Acked-by: Balbir Singh <bsinghar...@gmail.com>

Re: [PATCH v12 22/22] selftests/vm: Fix deadlock in protection_keys.c

(level <= DEBUG_LEVEL) \ sigsafe_printf(args); \ - fflush(NULL); \ } while (0) #define dprintf0(args...) dprintf_level(0, args) #define dprintf1(args...) dprintf_level(1, args) But both are equivalent I guess, so Acked-by: Balbir Singh

Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace

On Thu, Feb 22, 2018 at 2:51 PM, Alastair D'Silva <alast...@au1.ibm.com> wrote: > On Thu, 2018-02-22 at 14:46 +1100, Balbir Singh wrote: > >> lpc_size could be added. It's currently useless to the library, but >> > doesn't >> > hurt. The one which was givi

Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace

On Thu, Feb 22, 2018 at 2:51 PM, Alastair D'Silva wrote: > On Thu, 2018-02-22 at 14:46 +1100, Balbir Singh wrote: > >> lpc_size could be added. It's currently useless to the library, but >> > doesn't >> > hurt. The one which was giving me troubles on a previous v

Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace

On Wed, Feb 21, 2018 at 10:25 PM, Frederic Barrat <fbar...@linux.vnet.ibm.com> wrote: > > > Le 21/02/2018 à 07:43, Balbir Singh a écrit : >> >> On Wed, Feb 21, 2018 at 3:57 PM, Alastair D'Silva <alast...@au1.ibm.com> >> wrote: >>> >>> F

Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace

On Wed, Feb 21, 2018 at 10:25 PM, Frederic Barrat wrote: > > > Le 21/02/2018 à 07:43, Balbir Singh a écrit : >> >> On Wed, Feb 21, 2018 at 3:57 PM, Alastair D'Silva >> wrote: >>> >>> From: Alastair D'Silva >>> >>> Some

Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace

On Thu, Feb 22, 2018 at 10:32 AM, Alastair D'Silva <alast...@au1.ibm.com> wrote: > > On Wed, 2018-02-21 at 17:43 +1100, Balbir Singh wrote: >> On Wed, Feb 21, 2018 at 3:57 PM, Alastair D'Silva <alast...@au1.ibm.c >> om> wrote: >> > From: Alastair D'Silv

Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace

On Thu, Feb 22, 2018 at 10:32 AM, Alastair D'Silva wrote: > > On Wed, 2018-02-21 at 17:43 +1100, Balbir Singh wrote: >> On Wed, Feb 21, 2018 at 3:57 PM, Alastair D'Silva > om> wrote: >> > From: Alastair D'Silva >> > >> > Some required information i

Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace

ersion; > + > + // Version 0 fields > + __u8 afu_version_major; > + __u8 afu_version_minor; > + __u32 pasid; > + > + __u64 pp_mmio_size; > + __u64 global_mmio_size; > + Should we document the fields? pp_ stands for per process, but is not very clear at first look. Why do we care to return only the size, what about lpc size? > + // End version 0 fields > + > + __u64 reserved[13]; // Total of 16*u64 > +}; Balbir Singh.

Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace

u_version_major; > + __u8 afu_version_minor; > + __u32 pasid; > + > + __u64 pp_mmio_size; > + __u64 global_mmio_size; > + Should we document the fields? pp_ stands for per process, but is not very clear at first look. Why do we care to return only the size, what about lpc size? > + // End version 0 fields > + > + __u64 reserved[13]; // Total of 16*u64 > +}; Balbir Singh.

Re: [PATCH 1/2] powerpc/kdump: Add missing optional dummy functions

On Mon, 12 Feb 2018 15:25:51 -0800 Guenter Roeck <li...@roeck-us.net> wrote: > On Tue, Feb 13, 2018 at 10:01:57AM +1100, Balbir Singh wrote: > > On Tue, Feb 13, 2018 at 9:34 AM, Guenter Roeck <li...@roeck-us.net> wrote: > > > If KEXEC_CORE is not enabled,

Re: [PATCH 1/2] powerpc/kdump: Add missing optional dummy functions

On Mon, 12 Feb 2018 15:25:51 -0800 Guenter Roeck wrote: > On Tue, Feb 13, 2018 at 10:01:57AM +1100, Balbir Singh wrote: > > On Tue, Feb 13, 2018 at 9:34 AM, Guenter Roeck wrote: > > > If KEXEC_CORE is not enabled, PowerNV builds fail as follows. > > > > >

Re: [PATCH] powerpc/xmon: Dont register sysrq key when kernel param xmon=off

On Mon, Feb 12, 2018 at 11:35 PM, Vaibhav Jain <vaib...@linux.vnet.ibm.com> wrote: > Thanks for reviewing this patch Balbir > > Balbir Singh <bsinghar...@gmail.com> writes: > >> Any specific issue you've run into without this patch? > Without this patch since x

Re: [PATCH] powerpc/xmon: Dont register sysrq key when kernel param xmon=off

On Mon, Feb 12, 2018 at 11:35 PM, Vaibhav Jain wrote: > Thanks for reviewing this patch Balbir > > Balbir Singh writes: > >> Any specific issue you've run into without this patch? > Without this patch since xmon is still accessible via sysrq and there is > no indica

Re: [PATCH 1/2] powerpc/kdump: Add missing optional dummy functions

> implicit declaration of function 'crash_ipi_callback' > > Add dummy function calls, similar to kdump_in_progress(), to solve the > problem. > > Fixes: 4145f358644b ("powernv/kdump: Fix cases where the kdump kernel ...") > Cc: Balbir Singh <bsinghar...@gmail.co

Re: [PATCH 1/2] powerpc/kdump: Add missing optional dummy functions

ion of function 'crash_ipi_callback' > > Add dummy function calls, similar to kdump_in_progress(), to solve the > problem. > > Fixes: 4145f358644b ("powernv/kdump: Fix cases where the kdump kernel ...") > Cc: Balbir Singh > Cc: Michael Ellerman > Cc: Nicholas Pigg

Re: [PATCH] powerpc/xmon: Dont register sysrq key when kernel param xmon=off

we don't want xmon to take over in case of panic/die/oops, why are we tying this to sysrq? Balbir Singh.

Re: [PATCH] powerpc/xmon: Dont register sysrq key when kernel param xmon=off

are we tying this to sysrq? Balbir Singh.

Re: [PATCH v2] delayacct: Account blkio completion on the correct task

> io_schedule_timeout() into scheduler") > Signed-off-by: Josh Snyder <jo...@netflix.com> > --- Acked-by: Balbir Singh <bsinghar...@gmail.com>

Re: [PATCH v2] delayacct: Account blkio completion on the correct task

gt; accounting statistics updated. > > Instead of doing that, pass the task_struct being woken to > delayacct_blkio_end, so that it can update the statistics of the correct > task. > > Fixes: e33a9bba85a8 ("sched/core: move IO scheduling accounting from > io_schedule_timeout(

Re: [PATCH] powerpc: restore alphabetic order in Kconfig

eb2b0 ("powerpc/Kconfig: Enable STRICT_KERNEL_RWX for some > configs") > Signed-off-by: Christophe Leroy <christophe.le...@c-s.fr> > --- Acked-by: Balbir Singh <bsinghar...@gmail.com>

Re: [PATCH] powerpc: restore alphabetic order in Kconfig

KERNEL_RWX for some > configs") > Signed-off-by: Christophe Leroy > --- Acked-by: Balbir Singh

Re: [v3 PATCH 2/3] powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous pstates

On Wed, Jan 3, 2018 at 11:07 PM, Rafael J. Wysocki <r...@rjwysocki.net> wrote: > On Monday, December 18, 2017 9:38:20 AM CET Gautham R Shenoy wrote: >> Hi Balbir, >> >> On Sun, Dec 17, 2017 at 02:15:25PM +1100, Balbir Singh wrote: >> > On Wed, Dec 13, 2017 a

Re: [v3 PATCH 2/3] powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous pstates

On Wed, Jan 3, 2018 at 11:07 PM, Rafael J. Wysocki wrote: > On Monday, December 18, 2017 9:38:20 AM CET Gautham R Shenoy wrote: >> Hi Balbir, >> >> On Sun, Dec 17, 2017 at 02:15:25PM +1100, Balbir Singh wrote: >> > On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. S

Re: [PATCH] cpufreq: powernv: Add support of frequency domain

ding the extra IPIs only in the > presence of the quirk which can be indicated through a device-tree > parameter. If the future implementation fix this, then we won't need > the extra IPIs. Balbir Singh.

Re: [PATCH] cpufreq: powernv: Add support of frequency domain

y in the > presence of the quirk which can be indicated through a device-tree > parameter. If the future implementation fix this, then we won't need > the extra IPIs. Balbir Singh.

Re: [PATCH] powerpc/perf: Dereference bhrb entries safely

On Tue, Dec 19, 2017 at 6:23 PM, Ravi Bangoria <ravi.bango...@linux.vnet.ibm.com> wrote: > Hi Balbir, > > Sorry was away for few days. > No problem at all > On 12/14/2017 05:54 PM, Balbir Singh wrote: >> On Tue, Dec 12, 2017 at 11:29 PM, Ravi Bangoria >> <rav

Re: [PATCH] powerpc/perf: Dereference bhrb entries safely

On Tue, Dec 19, 2017 at 6:23 PM, Ravi Bangoria wrote: > Hi Balbir, > > Sorry was away for few days. > No problem at all > On 12/14/2017 05:54 PM, Balbir Singh wrote: >> On Tue, Dec 12, 2017 at 11:29 PM, Ravi Bangoria >> wrote: >>> It may very well happ

Re: [PATCH] On ppc64le we HAVE_RELIABLE_STACKTRACE

rted to livepatch as unreliable. >> >> I don't think there is much problem there for powerpc. Stack frame >> creation and function call with return pointer are each atomic. > > What if the function is interrupted before it creates the stack frame? > If it is interrupted, the exception handler will establish a new stack frame. >From a consistency viewpoint, I guess the question is -- has the function been entered or considered to be entered when a stack frame has not yet been established Balbir Singh.

Re: [PATCH] On ppc64le we HAVE_RELIABLE_STACKTRACE

nk there is much problem there for powerpc. Stack frame >> creation and function call with return pointer are each atomic. > > What if the function is interrupted before it creates the stack frame? > If it is interrupted, the exception handler will establish a new stack frame. >From a consistency viewpoint, I guess the question is -- has the function been entered or considered to be entered when a stack frame has not yet been established Balbir Singh.

Re: [v3 PATCH 3/3] powernv-cpufreq: Treat pstates as opaque 8-bit values

64 pmsr_val, unsigned int shift) > { > - int ret = ((pmsr_val >> shift) & 0xFF); > - > - if (!ret) > - return ret; > - > - return (pstate_sign_prefix | ret); > + return ((pmsr_val >> shift) & 0xFF); > } So we just added this and moved from an int to u8. I was going to ask if we still need an int in patch1, but I thought the driver dealt with just integers because of the larger framework. Balbir Singh.

Re: [v3 PATCH 3/3] powernv-cpufreq: Treat pstates as opaque 8-bit values

& 0xFF); > - > - if (!ret) > - return ret; > - > - return (pstate_sign_prefix | ret); > + return ((pmsr_val >> shift) & 0xFF); > } So we just added this and moved from an int to u8. I was going to ask if we still need an int in patch1, but I thought the driver dealt with just integers because of the larger framework. Balbir Singh.

Re: [v3 PATCH 2/3] powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous pstates

the complexity. Pstates are contiguous because they define transitions in incremental value of change in frequency and I can't see how this can be broken in the future? Balbir Singh.

Re: [v3 PATCH 2/3] powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous pstates

nsitions in incremental value of change in frequency and I can't see how this can be broken in the future? Balbir Singh.

Re: [v3 PATCH 1/3] powernv-cpufreq: Add helper to extract pstate from PMSR

it to be > consistent with the values provided by the device-tree. > > Signed-off-by: Gautham R. Shenoy <e...@linux.vnet.ibm.com> > --- This looks better Acked-by: Balbir Singh <bsinghar...@gmail.com> Balbir Singh

Re: [v3 PATCH 1/3] powernv-cpufreq: Add helper to extract pstate from PMSR

hereby > treating a legitimate pstate (say 130) as an invalid pstates (since it > is interpreted as -126). > > This patch fixes the issue by implementing a helper function to > extract Pstates from PMSR register, and correctly sign-extend it to be > consistent with the values provided by the devic

Re: powerpc64 kernel panic if you disable CONFIG_PPC_TRANSACTIONAL_MEM?

0004 > what does the instruction at 10001a04 look like? Balbir Singh.

Re: powerpc64 kernel panic if you disable CONFIG_PPC_TRANSACTIONAL_MEM?

truction at 10001a04 look like? Balbir Singh.

Re: [PATCH] powerpc/perf: Dereference bhrb entries safely

t(); > + } > > /* Userspace: need copy instruction here then translate it */ > pagefault_disable(); Otherwise, Reviewed-by: Balbir Singh <bsinghar...@gmail.com>

Re: [PATCH] powerpc/perf: Dereference bhrb entries safely

xt. It would be nice to catch such cases. > + if (probe_kernel_address((void *)addr, instr)) > + return 0; > + return branch_target(); > + } > > /* Userspace: need copy instruction here then translate it */ > pagefault_disable(); Otherwise, Reviewed-by: Balbir Singh

Re: [v2 PATCH] cpufreq: powernv: Correctly parse the sign of pstates on POWER8 vs POWER9

;> GPSTATE_SHIFT) & 0xFF) > +#define GET_PMSR_MAX(x)EXTRACT_BYTE(x, MAX_SHIFT) > +#define GET_LPSTATE(x) EXTRACT_BYTE(x, LPSTATE_SHIFT) > +#define GET_GPSTATE(x) EXTRACT_BYTE(x, GPSTATE_SHIFT) > + Can you hide all of this in pstate_to_idx(), do the casting inside? I was reviewing this code earlier before being distracted with something else, this did come across as strange and I was looking at using abs values to simplify the code, but I did not get to it. Balbir Singh.

Re: [v2 PATCH] cpufreq: powernv: Correctly parse the sign of pstates on POWER8 vs POWER9

EXTRACT_BYTE(x, GPSTATE_SHIFT) > + Can you hide all of this in pstate_to_idx(), do the casting inside? I was reviewing this code earlier before being distracted with something else, this did come across as strange and I was looking at using abs values to simplify the code, but I did not get to it. Balbir Singh.

Re: [PATCH] powerpc/xmon: use ARRAY_SIZE on various array sizing calculations

om binutils and re-licensed. Keeping the file as-is helps apply newer patches easily on top as opposed to redoing the changes. I would prefer not to move to ARRAY_SIZE and stick to what's already in the file. Balbir Singh.

Re: [PATCH] powerpc/xmon: use ARRAY_SIZE on various array sizing calculations

patches easily on top as opposed to redoing the changes. I would prefer not to move to ARRAY_SIZE and stick to what's already in the file. Balbir Singh.

Re: [PATCH 1/2] powerpc/lib/code-patching: refactor patch_instruction()

code. > > Signed-off-by: Christophe Leroy <christophe.le...@c-s.fr> > --- Acked-by: Balbir Singh <bsinghar...@gmail.com>

Re: [PATCH 1/2] powerpc/lib/code-patching: refactor patch_instruction()

-by: Christophe Leroy > --- Acked-by: Balbir Singh

Re: [PATCH v2] powerpc: fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX

On Thu, Nov 23, 2017 at 11:04 PM, Michael Ellerman <m...@ellerman.id.au> wrote: > Christophe LEROY <christophe.le...@c-s.fr> writes: >> Le 22/11/2017 à 12:48, Michael Ellerman a écrit : >>> Christophe LEROY <christophe.le...@c-s.fr> writes: >>>

Re: [PATCH v2] powerpc: fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX

On Thu, Nov 23, 2017 at 11:04 PM, Michael Ellerman wrote: > Christophe LEROY writes: >> Le 22/11/2017 à 12:48, Michael Ellerman a écrit : >>> Christophe LEROY writes: >>>> Le 22/11/2017 à 00:07, Balbir Singh a écrit : >>>>> On Wed, Nov 22, 2

Re: [PATCH v2] powerpc: fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX

PTRRELOC() > > Fixes: 37bc3e5fd764f ("powerpc/lib/code-patching: Use alternate map > for patch_instruction()") > Reported-by: Meelis Roos <mr...@linux.ee> > Cc: Balbir Singh <bsinghar...@gmail.com> > Signed-off-by: Christophe Leroy <christophe.le...@c-s.fr>

Re: [PATCH v2] powerpc: fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX

e5fd764f ("powerpc/lib/code-patching: Use alternate map > for patch_instruction()") > Reported-by: Meelis Roos > Cc: Balbir Singh > Signed-off-by: Christophe Leroy > --- > v2: Added missing asm/setup.h > > arch/powerpc/lib/code-patching.c | 6 ++ > 1 fi

Re: STRICT_KERNEL_RWX on PPC32 is broken on PowerMac G4

ve there is something wrong with commit > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20171115=37bc3e5fd764fb258ff4fcbb90b6d1b67fb466c1 > > Balbir, do you have any idea ? > Hmm.. interesting, so nobats works, but code-patching has issues? Any chance you can boot with xmon=on on the command line when you drop into the xmon> prompt, type dl to get the kernel log. Balbir Singh.

Re: STRICT_KERNEL_RWX on PPC32 is broken on PowerMac G4

ps://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20171115=37bc3e5fd764fb258ff4fcbb90b6d1b67fb466c1 > > Balbir, do you have any idea ? > Hmm.. interesting, so nobats works, but code-patching has issues? Any chance you can boot with xmon=on on the command line when you drop into the xmon> prompt, type dl to get the kernel log. Balbir Singh.

Re: [PATCH v2] pids: introduce find_get_task_by_vpid helper

gt; --- I did a quick grep and found other similar patterns in kernel/events/core.c, kernel/kcmp.c kernel/sys.c , kernel/time/posix-cpu-timers.c, arch/x86/kernel/cpu/intel_rdt_rdtgroup.c, security/yama/yama_lsm.c, mm/process_vm_access.c, mm/mempolicy.c and arch/ia64/kernel/perfmon.c Balbir Singh.

Re: [PATCH v2] pids: introduce find_get_task_by_vpid helper

n kernel/events/core.c, kernel/kcmp.c kernel/sys.c , kernel/time/posix-cpu-timers.c, arch/x86/kernel/cpu/intel_rdt_rdtgroup.c, security/yama/yama_lsm.c, mm/process_vm_access.c, mm/mempolicy.c and arch/ia64/kernel/perfmon.c Balbir Singh.

Re: [PATCH 1/2] mm/mmu_notifier: avoid double notification when it is useless v2

On Thu, 2017-10-19 at 12:58 -0400, Jerome Glisse wrote: > On Thu, Oct 19, 2017 at 09:53:11PM +1100, Balbir Singh wrote: > > On Thu, Oct 19, 2017 at 2:28 PM, Jerome Glisse <jgli...@redhat.com> wrote: > > > On Thu, Oct 19, 2017 at 02:04:26PM +1100, Balbir Singh wrote: > &

Re: [PATCH 1/2] mm/mmu_notifier: avoid double notification when it is useless v2

On Thu, 2017-10-19 at 12:58 -0400, Jerome Glisse wrote: > On Thu, Oct 19, 2017 at 09:53:11PM +1100, Balbir Singh wrote: > > On Thu, Oct 19, 2017 at 2:28 PM, Jerome Glisse wrote: > > > On Thu, Oct 19, 2017 at 02:04:26PM +1100, Balbir Singh wrote: > > > > On M

Re: [PATCH v2] mm: mlock: remove lru_add_drain_all()

a cgroup. My understanding is that we'll slowly see the unreclaimable stats go up as we drain the pvec's across CPU's I understand the optimization and I can see why lru_add_drain_all() is expensive. Acked-by: Balbir Singh <bsinghar...@gmail.com> Balbir Singh.

Re: [PATCH v2] mm: mlock: remove lru_add_drain_all()

e unreclaimable stats go up as we drain the pvec's across CPU's I understand the optimization and I can see why lru_add_drain_all() is expensive. Acked-by: Balbir Singh Balbir Singh.

Re: [PATCH 1/2] mm/mmu_notifier: avoid double notification when it is useless v2

On Thu, Oct 19, 2017 at 2:28 PM, Jerome Glisse <jgli...@redhat.com> wrote: > On Thu, Oct 19, 2017 at 02:04:26PM +1100, Balbir Singh wrote: >> On Mon, 16 Oct 2017 23:10:02 -0400 >> jgli...@redhat.com wrote: >> >> > Fro

Re: [PATCH 1/2] mm/mmu_notifier: avoid double notification when it is useless v2

On Thu, Oct 19, 2017 at 2:28 PM, Jerome Glisse wrote: > On Thu, Oct 19, 2017 at 02:04:26PM +1100, Balbir Singh wrote: >> On Mon, 16 Oct 2017 23:10:02 -0400 >> jgli...@redhat.com wrote: >> >> > From: Jérôme Glisse >> > >> > +

Re: [PATCH] mm: mlock: remove lru_add_drain_all()

-by: Shakeel Butt <shake...@google.com> > --- Does this perturb statistics around LRU pages in cgroups and meminfo about where the pages actually belong? Balbir Singh.

Re: [PATCH] mm: mlock: remove lru_add_drain_all()

- Does this perturb statistics around LRU pages in cgroups and meminfo about where the pages actually belong? Balbir Singh.

Re: [PATCH 1/2] mm/mmu_notifier: avoid double notification when it is useless v2

> + */ > dec_mm_counter(mm, mm_counter_file(page)); > + } > discard: > + /* > + * No need to call mmu_notifier_invalidate_range() it has be > + * done above for all cases requiring it to happen under page > + * table lock before mmu_notifier_invalidate_range_end() > + * > + * See Documentation/vm/mmu_notifier.txt > + */ > page_remove_rmap(subpage, PageHuge(page)); > put_page(page); > - mmu_notifier_invalidate_range(mm, address, > - address + PAGE_SIZE); > } > > mmu_notifier_invalidate_range_end(vma->vm_mm, start, end); Looking at the patchset, I understand the efficiency, but I am concerned with correctness. Balbir Singh.

Re: [PATCH 1/2] mm/mmu_notifier: avoid double notification when it is useless v2

gt; + * concurrent thread might update its page table to > + * point at new page while a device still is using this > + * page. > + * > + * See Documentation/vm/mmu_notifier.txt > + */ > dec_mm_counter(mm, mm_counter_file(page)); > + } > discard: > + /* > + * No need to call mmu_notifier_invalidate_range() it has be > + * done above for all cases requiring it to happen under page > + * table lock before mmu_notifier_invalidate_range_end() > + * > + * See Documentation/vm/mmu_notifier.txt > + */ > page_remove_rmap(subpage, PageHuge(page)); > put_page(page); > - mmu_notifier_invalidate_range(mm, address, > - address + PAGE_SIZE); > } > > mmu_notifier_invalidate_range_end(vma->vm_mm, start, end); Looking at the patchset, I understand the efficiency, but I am concerned with correctness. Balbir Singh.

Re: [PATCH 0/2] Optimize mmu_notifier->invalidate_range callback

llback to invalidate_range this can be done when clearing a > pte, pmd or pud with notification which call invalidate_range right after > clearing under the page table lock. > Balbir Singh.

Re: [PATCH 0/2] Optimize mmu_notifier->invalidate_range callback

this can be done when clearing a > pte, pmd or pud with notification which call invalidate_range right after > clearing under the page table lock. > Balbir Singh.

Re: [PATCH v2] powerpc: Default to enabling STRICT_KERNEL_RWX

ras <pau...@samba.org> > Cc: Michael Ellerman <m...@ellerman.id.au> > Cc: Christophe LEROY <christophe.le...@c-s.fr> > Cc: Balbir Singh <bsinghar...@gmail.com> > Cc: linuxppc-...@lists.ozlabs.org > Signed-off-by: Kees Cook <keesc...@chromium.org> > -

Re: [PATCH v2] powerpc: Default to enabling STRICT_KERNEL_RWX

On Fri, Oct 6, 2017 at 6:03 AM, Kees Cook wrote: > When available, CONFIG_KERNEL_RWX should be default-enabled for PPC64. > On PPC32, there is a performance trade-off. > > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: Christophe LEROY >

Re: [PATCH] mm/device-public-memory: Fix edge case in _vm_normal_page()

k > accordingly. > > Fixes: df6ad69838fc ("mm/device-public-memory: device memory cache coherent > with CPU") > Cc: Jérôme Glisse <jgli...@redhat.com> > Signed-off-by: Reza Arbab <ar...@linux.vnet.ibm.com> > --- Reviewed-by: Balbir Singh <bsinghar...@gmail.com>

Re: [PATCH] mm/device-public-memory: Fix edge case in _vm_normal_page()

es: df6ad69838fc ("mm/device-public-memory: device memory cache coherent > with CPU") > Cc: Jérôme Glisse > Signed-off-by: Reza Arbab > --- Reviewed-by: Balbir Singh

Re: [PATCH 1/6] mm: introduce an additional vma bit for powerpc pkey

igned-off-by: Ram Pai <linux...@us.ibm.com> > --- Acked-by: Balbir Singh <bsinghar...@gmail.com>

Re: [PATCH 1/6] mm: introduce an additional vma bit for powerpc pkey

On Fri, 15 Sep 2017 18:21:05 -0700 Ram Pai wrote: > Currently only 4bits are allocated in the vma flags to hold 16 > keys. This is sufficient for x86. PowerPC supports 32 keys, > which needs 5bits. This patch allocates an additional bit. > > Signed-off-by: Ram Pai > ---

Re: [PATCH 3/6] mm: display pkey in smaps if arch_pkeys_enabled() is true

On Fri, 15 Sep 2017 18:21:07 -0700 Ram Pai wrote: > +#ifdef CONFIG_ARCH_HAS_PKEYS > + if (arch_pkeys_enabled()) Sorry, I missed this bit in my previous review the patch makes sense > + seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma)); > +#endif > +

Re: [PATCH 3/6] mm: display pkey in smaps if arch_pkeys_enabled() is true

On Fri, 15 Sep 2017 18:21:07 -0700 Ram Pai wrote: > +#ifdef CONFIG_ARCH_HAS_PKEYS > + if (arch_pkeys_enabled()) Sorry, I missed this bit in my previous review the patch makes sense > + seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma)); > +#endif > + Balbir

Re: [PATCH 3/6] mm: display pkey in smaps if arch_pkeys_enabled() is true

On Fri, 15 Sep 2017 18:21:07 -0700 Ram Pai wrote: > Currently the architecture specific code is expected to > display the protection keys in smap for a given vma. > This can lead to redundant code and possibly to divergent > formats in which the key gets displayed. >

Re: [PATCH 3/6] mm: display pkey in smaps if arch_pkeys_enabled() is true

On Fri, 15 Sep 2017 18:21:07 -0700 Ram Pai wrote: > Currently the architecture specific code is expected to > display the protection keys in smap for a given vma. > This can lead to redundant code and possibly to divergent > formats in which the key gets displayed. > > This patch

Re: [PATCH 4/6] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

> --- Just curious, how do you see this being used? For debugging or will applications parse these properties and use them? It's hard for an application to partition its address space among keys at runtime, would you agree? Balbir Singh.

Re: [PATCH 4/6] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

l_keys <== > 1 > > ==> /sys/kernel/mm/protection_keys/usable_keys <== > 0 > > Signed-off-by: Ram Pai > Signed-off-by: Thiago Jung Bauermann > --- Just curious, how do you see this being used? For debugging or will applications parse these properties and use them? It's hard for an application to partition its address space among keys at runtime, would you agree? Balbir Singh.

Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3

t; device and CPU is CCIX capable if so it can use this helper to hotplug it > as device memory. Yep, the arch needs to do the right thing at hotplug time, which is 1. Don't online the memory as a NUMA node 2. Use the HMM-CDM API's to map the memory to ZONE DEVICE via the driver Like Jerome said and we tried as well, the NUMA approach needs more agreement and discussion and probable extensions Balbir Singh

Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3

CIX capable if so it can use this helper to hotplug it > as device memory. Yep, the arch needs to do the right thing at hotplug time, which is 1. Don't online the memory as a NUMA node 2. Use the HMM-CDM API's to map the memory to ZONE DEVICE via the driver Like Jerome said and we tried as well, the NUMA approach needs more agreement and discussion and probable extensions Balbir Singh

Re: [PATCH v3 0/5] powerpc/mm: Fix kernel protection and implement STRICT_KERNEL_RWX on PPC32

/outdated > fixmap stuff. I looked at it, looks good overall, I've reviewed the previous series. Have you checked the series against CONFIG_RELOCATABLE? Balbir Singh.

Re: [PATCH v3 0/5] powerpc/mm: Fix kernel protection and implement STRICT_KERNEL_RWX on PPC32

tuff. I looked at it, looks good overall, I've reviewed the previous series. Have you checked the series against CONFIG_RELOCATABLE? Balbir Singh.

Re: [PATCH 5/6] mm/memcontrol: support MEMORY_DEVICE_PRIVATE and MEMORY_DEVICE_PUBLIC v3

st > - add comments explaining how device memory behave and why > > Signed-off-by: Jérôme Glisse <jgli...@redhat.com> > Cc: Johannes Weiner <han...@cmpxchg.org> > Cc: Michal Hocko <mho...@kernel.org> > Cc: Vladimir Davydov <vdavydov@gmail.com> > Cc: cgro...@vger.kernel.org > --- Acked-by: Balbir Singh <bsinghar...@gmail.com>

Re: [PATCH 5/6] mm/memcontrol: support MEMORY_DEVICE_PRIVATE and MEMORY_DEVICE_PUBLIC v3

st > - add comments explaining how device memory behave and why > > Signed-off-by: Jérôme Glisse > Cc: Johannes Weiner > Cc: Michal Hocko > Cc: Vladimir Davydov > Cc: cgro...@vger.kernel.org > --- Acked-by: Balbir Singh

Re: [PATCH 4/6] mm/memcontrol: allow to uncharge page without using page->lru field

Cc: Vladimir Davydov <vdavydov....@gmail.com> > Cc: cgro...@vger.kernel.org > --- Acked-by: Balbir Singh <bsinghar...@gmail.com>

Re: [PATCH 4/6] mm/memcontrol: allow to uncharge page without using page->lru field

g the lru field of the struct page. > > There is no change to memcontrol logic, it is the same as it was > before this patch. > > Signed-off-by: Jérôme Glisse > Cc: Johannes Weiner > Cc: Michal Hocko > Cc: Vladimir Davydov > Cc: cgro...@vger.kernel.org > --- Acked-by: Balbir Singh

Re: [PATCH 1/6] mm/zone-device: rename DEVICE_PUBLIC to DEVICE_HOST

c: Ross Zwisler <ross.zwis...@linux.intel.com> > --- Acked-by: Balbir Singh <bsinghar...@gmail.com>

Re: [PATCH 1/6] mm/zone-device: rename DEVICE_PUBLIC to DEVICE_HOST

che coherent device memory that has strong tie with the device > on which the memory is (for instance on board GPU memory). > > There is no functional change here. > > Signed-off-by: Jérôme Glisse > Cc: Dan Williams > Cc: Ross Zwisler > --- Acked-by: Balbir Singh

Re: [PATCH 2/6] mm/device-public-memory: device memory cache coherent with CPU v4

g and #if/#else cleanup > > Signed-off-by: Jérôme Glisse <jgli...@redhat.com> > Cc: Balbir Singh <balb...@au1.ibm.com> > Cc: Aneesh Kumar <aneesh.ku...@linux.vnet.ibm.com> > Cc: Paul E. McKenney <paul...@linux.vnet.ibm.com> > Cc: Benjamin Herrenschmidt <b...@k

Re: [PATCH 2/6] mm/device-public-memory: device memory cache coherent with CPU v4

g and #if/#else cleanup > > Signed-off-by: Jérôme Glisse > Cc: Balbir Singh > Cc: Aneesh Kumar > Cc: Paul E. McKenney > Cc: Benjamin Herrenschmidt > Cc: Dan Williams > Cc: Ross Zwisler > --- Acked-by: Balbir Singh

Re: [RFC v5 14/38] powerpc: initial plumbing for key management

On Fri, Jul 14, 2017 at 6:37 AM, Ram Pai <linux...@us.ibm.com> wrote: > On Thu, Jul 13, 2017 at 12:45:00AM -0700, Ram Pai wrote: >> On Wed, Jul 12, 2017 at 01:28:25PM +1000, Balbir Singh wrote: >> > On Wed, 5 Jul 2017 14:21:51 -0700 >> > Ram Pai <linux...@us

Re: [RFC v5 14/38] powerpc: initial plumbing for key management

On Fri, Jul 14, 2017 at 6:37 AM, Ram Pai wrote: > On Thu, Jul 13, 2017 at 12:45:00AM -0700, Ram Pai wrote: >> On Wed, Jul 12, 2017 at 01:28:25PM +1000, Balbir Singh wrote: >> > On Wed, 5 Jul 2017 14:21:51 -0700 >> > Ram Pai wrote: >> > >> > > I

Re: [RFC v5 15/38] powerpc: helper function to read,write AMR,IAMR,UAMOR registers

On Thu, Jul 13, 2017 at 5:55 PM, Ram Pai <linux...@us.ibm.com> wrote: > On Wed, Jul 12, 2017 at 03:26:01PM +1000, Balbir Singh wrote: >> On Wed, 5 Jul 2017 14:21:52 -0700 >> Ram Pai <linux...@us.ibm.com> wrote: >> >> > Implements helper functions to rea

Re: [RFC v5 15/38] powerpc: helper function to read,write AMR,IAMR,UAMOR registers

On Thu, Jul 13, 2017 at 5:55 PM, Ram Pai wrote: > On Wed, Jul 12, 2017 at 03:26:01PM +1000, Balbir Singh wrote: >> On Wed, 5 Jul 2017 14:21:52 -0700 >> Ram Pai wrote: >> >> > Implements helper functions to read and write the key related >> > registers; A

<    1   2   3   4   5   6   7   8   9   10   >