Re: [PATCH v2 2/5] powerpc: kretprobes: override default function entry offset

On Wed, Feb 22, 2017 at 07:23:38PM +0530, Naveen N. Rao wrote: > With ABIv2, we offset 8 bytes into a function to get at the local entry > point. > Looks good. > Signed-off-by: Naveen N. Rao Acked-by: Ananth N Mavinakayanahalli

Re: [PATCH v2 4/5] perf: kretprobes: offset from reloc_sym if kernel supports it

On Fri, 24 Feb 2017 17:11:03 -0300 Arnaldo Carvalho de Melo wrote: > Em Sat, Feb 25, 2017 at 02:29:17AM +0900, Masami Hiramatsu escreveu: > > On Fri, 24 Feb 2017 00:46:08 +0530 > > "Naveen N. Rao" wrote: > > > Thanks. I hope that's an Ack for

Re: [RFC] Remove memory from nodes for memtrace.

On Thu, Feb 23, 2017 at 8:39 AM, Rashmica Gupta wrote: > Some powerpc hardware features may want to gain access to a > chunk of undisturbed real memory. This update provides a means to unplug > said memory from the kernel with a set of sysfs calls. By writing an integer

Re: [PATCH v2 4/5] perf: kretprobes: offset from reloc_sym if kernel supports it

Em Sat, Feb 25, 2017 at 02:29:17AM +0900, Masami Hiramatsu escreveu: > On Fri, 24 Feb 2017 00:46:08 +0530 > "Naveen N. Rao" wrote: > > Thanks. I hope that's an Ack for this patchset? > > OK, for 1/5, 2/5, 3/5, and 5/5; > > Acked-by: Masami Hiramatsu

Re: [PATCH v3 1/2] perf: probe: generalize probe event file open routine

Em Sat, Feb 25, 2017 at 01:46:01AM +0900, Masami Hiramatsu escreveu: > On Thu, 23 Feb 2017 17:07:23 +0530 > "Naveen N. Rao" wrote: > > > ...into a generic function for opening trace files. > > Even if it repeats subject, please write complete description... > >

Re: [PATCH v2 2/5] powerpc: kretprobes: override default function entry offset

Em Wed, Feb 22, 2017 at 07:23:38PM +0530, Naveen N. Rao escreveu: > With ABIv2, we offset 8 bytes into a function to get at the local entry > point. So, I think I can carry the first one via Ingo, etc, what about this one? Is it ok for me to process it? Seems simple enough, has been thru a lot

[RFT PATCH] tpm: ibmvtpm: simplify crq initialization and document crq format

The crq is passed in registers and is the same on BE and LE hosts. However, current implementation allocates a structure on-stack to represent the crq, initializes the members swapping them to BE, and loads the structure swapping it from BE. This is pointless and causes GCC warnings about

Re: [PATCH v2 4/5] perf: kretprobes: offset from reloc_sym if kernel supports it

On Fri, 24 Feb 2017 00:46:08 +0530 "Naveen N. Rao" wrote: > On 2017/02/23 06:10PM, Masami Hiramatsu wrote: > > On Wed, 22 Feb 2017 19:23:40 +0530 > > "Naveen N. Rao" wrote: > > > > > We indicate support for accepting sym+offset

Re: [PATCH v3 2/2] perf: kretprobes: offset from reloc_sym if kernel supports it

On Thu, 23 Feb 2017 17:07:24 +0530 "Naveen N. Rao" wrote: > We indicate support for accepting sym+offset with kretprobes through a > line in ftrace README. Parse the same to identify support and choose the > appropriate format for kprobe_events. > >

Re: [RFC PATCH] memory-hotplug: Use dev_online for memhp_auto_offline

Michal Hocko writes: > On Fri 24-02-17 17:40:25, Vitaly Kuznetsov wrote: >> Michal Hocko writes: >> >> > On Fri 24-02-17 17:09:13, Vitaly Kuznetsov wrote: > [...] >> >> While this will most probably work for me I still disagree with the >> >> concept of

Re: [RFC PATCH] memory-hotplug: Use dev_online for memhp_auto_offline

On Fri 24-02-17 17:40:25, Vitaly Kuznetsov wrote: > Michal Hocko writes: > > > On Fri 24-02-17 17:09:13, Vitaly Kuznetsov wrote: [...] > >> While this will most probably work for me I still disagree with the > >> concept of 'one size fits all' here and the default 'false' for

Re: [PATCH v3 1/2] perf: probe: generalize probe event file open routine

On Thu, 23 Feb 2017 17:07:23 +0530 "Naveen N. Rao" wrote: > ...into a generic function for opening trace files. Even if it repeats subject, please write complete description... Patch itself is OK to me. Thanks, > > Signed-off-by: Naveen N. Rao

Re: [RFC PATCH] memory-hotplug: Use dev_online for memhp_auto_offline

Michal Hocko writes: > On Fri 24-02-17 17:09:13, Vitaly Kuznetsov wrote: >> I have a smal guest and I want to add more memory to it and the >> result is ... OOM. Not something I expected. > > Which is not all that unexpected if you use a technology which has to > allocated

Re: [RFC PATCH] memory-hotplug: Use dev_online for memhp_auto_offline

On Fri 24-02-17 17:09:13, Vitaly Kuznetsov wrote: > Michal Hocko writes: > > > On Fri 24-02-17 16:05:18, Vitaly Kuznetsov wrote: > >> Michal Hocko writes: > >> > >> > On Fri 24-02-17 15:10:29, Vitaly Kuznetsov wrote: > > [...] > >> >> Just did a quick (and

Re: [RFC PATCH] memory-hotplug: Use dev_online for memhp_auto_offline

Michal Hocko writes: > On Fri 24-02-17 16:05:18, Vitaly Kuznetsov wrote: >> Michal Hocko writes: >> >> > On Fri 24-02-17 15:10:29, Vitaly Kuznetsov wrote: > [...] >> >> Just did a quick (and probably dirty) test, increasing guest memory from >> >> 4G to 8G

Re: [RFC PATCH] memory-hotplug: Use dev_online for memhp_auto_offline

On Fri 24-02-17 16:05:18, Vitaly Kuznetsov wrote: > Michal Hocko writes: > > > On Fri 24-02-17 15:10:29, Vitaly Kuznetsov wrote: [...] > >> Just did a quick (and probably dirty) test, increasing guest memory from > >> 4G to 8G (32 x 128mb blocks) require 68Mb of memory, so

Re: [RESEND PATCH] cxl: Route eeh events to all slices for pci_channel_io_perm_failure state

Le 23/02/2017 à 04:27, Vaibhav Jain a écrit : Fix a boundary condition where in some cases an eeh event with state == pci_channel_io_perm_failure wont be passed on to a driver attached to the virtual pci device associated with a slice. This will happen in case the slice just before (n-1)

Re: [RFC PATCH] memory-hotplug: Use dev_online for memhp_auto_offline

Michal Hocko writes: > On Fri 24-02-17 15:10:29, Vitaly Kuznetsov wrote: >> Michal Hocko writes: >> >> > On Thu 23-02-17 19:14:27, Vitaly Kuznetsov wrote: > [...] >> >> Virtual guests under stress were getting into OOM easily and the OOM >> >> killer was

Re: [RFC PATCH] memory-hotplug: Use dev_online for memhp_auto_offline

On Fri 24-02-17 15:10:29, Vitaly Kuznetsov wrote: > Michal Hocko writes: > > > On Thu 23-02-17 19:14:27, Vitaly Kuznetsov wrote: [...] > >> Virtual guests under stress were getting into OOM easily and the OOM > >> killer was even killing the udev process trying to online the >

[PATCH v2 1/2] crypto: vmx - Use skcipher for cbc fallback

Signed-off-by: Paulo Flabiano Smorigo --- drivers/crypto/vmx/aes_cbc.c | 44 ++-- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/drivers/crypto/vmx/aes_cbc.c b/drivers/crypto/vmx/aes_cbc.c index

[PATCH v2 2/2] crypto: vmx - Use skcipher for xts fallback

Signed-off-by: Paulo Flabiano Smorigo --- drivers/crypto/vmx/aes_xts.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/crypto/vmx/aes_xts.c b/drivers/crypto/vmx/aes_xts.c index 24353ec3..a1e653a 100644 ---

Re: [RFC PATCH] memory-hotplug: Use dev_online for memhp_auto_offline

Michal Hocko writes: > On Thu 23-02-17 19:14:27, Vitaly Kuznetsov wrote: >> Michal Hocko writes: >> >> > On Thu 23-02-17 17:36:38, Vitaly Kuznetsov wrote: >> >> Michal Hocko writes: >> > [...] >> >> > Is a grow from 256M -> 128GB really

[RFC][PATCH][OPAL] cpufeatures: add base and POWER8 dt

With this patch and the Linux one, I can boot (in mambo) a POWER8 without looking up any cpu tables. It's not quite complete, but getting close. Main questions are what features do we add, and what "base" feature set do we start with. Where to discuss and document these features. OPAL firmware

[RFC][PATCH][Linux] powerpc/64s: cpufeatures: add initial implementation for cpufeatures

The /cpus/features dt binding describes architected CPU features along with some compatibility, privilege, and enablement properties that allow flexibility with discovering and enabling capabilities. Presence of this feature implies a base level of functionality, then additional feature nodes

Re: [RFC PATCH] memory-hotplug: Use dev_online for memhp_auto_offline

On Thu 23-02-17 19:14:27, Vitaly Kuznetsov wrote: > Michal Hocko writes: > > > On Thu 23-02-17 17:36:38, Vitaly Kuznetsov wrote: > >> Michal Hocko writes: > > [...] > >> > Is a grow from 256M -> 128GB really something that happens in real life? > >> > Don't

[PATCH v2] powerpc/fadump: set an upper limit for boot memory size

By default, 5% of system RAM is reserved for preserving boot memory. Alternatively, a user can specify the amount of memory to reserve. See Documentation/powerpc/firmware-assisted-dump.txt for details. In addition to the memory reserved for preserving boot memory, some more memory is reserved, to

RE: [PATCH v2 0/2] Allow configurable stack size (especially 32k on PPC64)

From: Hamish Martin > Sent: 24 February 2017 00:52 > This patch series adds the ability to configure the THREAD_SHIFT value and > thereby alter the stack size on powerpc systems. We are particularly > interested > in configuring for a 32k stack on PPC64. > > Using an NXP T2081 (e6500 PPC64

Re: [kernel-hardening] Re: [PATCH 1/2] powerpc: mm: support ARCH_MMAP_RND_BITS

On 24 February 2017 6:32:13 pm AEDT, Bhupesh Sharma wrote: >Hi Michael, > >On Thu, Feb 16, 2017 at 10:19 AM, Bhupesh Sharma >wrote: >> Hi Michael, >> >> On Fri, Feb 10, 2017 at 4:41 PM, Bhupesh Sharma >wrote: >>> On Fri, Feb 10,

RE: [PATCH 12/12] drm/ast: Call open_key before enable_mmio in POST code

Tested-by: Y.C. Chen -Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Friday, February 24, 2017 6:54 AM To: dri-de...@lists.freedesktop.org Cc: YC Chen ; airl...@redhat.com; e...@suse.come;

RE: [PATCH 11/12] drm/ast: Fix test for VGA enabled

Tested-by: Y.C. Chen -Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Friday, February 24, 2017 6:54 AM To: dri-de...@lists.freedesktop.org Cc: YC Chen ; airl...@redhat.com; e...@suse.come;

RE: [PATCH 09/12] drm/ast: Rename ast_init_dram_2300 to ast_post_chip_2300

Tested-by: Y.C. Chen -Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Friday, February 24, 2017 6:54 AM To: dri-de...@lists.freedesktop.org Cc: YC Chen ; airl...@redhat.com; e...@suse.come;

RE: [PATCH 08/12] drm/ast: Factor mmc_test code in POST code

Tested-by: Y.C. Chen -Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Friday, February 24, 2017 6:54 AM To: dri-de...@lists.freedesktop.org Cc: YC Chen ; airl...@redhat.com; e...@suse.come;

RE: [PATCH 07/12] drm/ast: Fixed vram size incorrect issue on POWER

Tested-by: Y.C. Chen -Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Friday, February 24, 2017 6:54 AM To: dri-de...@lists.freedesktop.org Cc: YC Chen ; airl...@redhat.com; e...@suse.come;

RE: [PATCH 05/12] drm/ast: Fix calculation of MCLK

Tested-by: Y.C. Chen -Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Friday, February 24, 2017 6:54 AM To: dri-de...@lists.freedesktop.org Cc: YC Chen ; airl...@redhat.com; e...@suse.come;

RE: [PATCH 02/12] drm/ast: Handle configuration without P2A bridge

Tested-by: Y.C. Chen -Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Friday, February 24, 2017 6:54 AM To: dri-de...@lists.freedesktop.org Cc: YC Chen ; airl...@redhat.com; e...@suse.come;

RE: [PATCH 01/12] drm/ast: Fix AST2400 POST failure without BMC FW or VBIOS

Tested-by: Y.C. Chen -Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Friday, February 24, 2017 6:54 AM To: dri-de...@lists.freedesktop.org Cc: YC Chen ; airl...@redhat.com; e...@suse.come;