On 18.02.2020 22:21, James Morris wrote:
> On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
>>
>> Introduce CAP_PERFMON capability designed to secure system performance
>> monitoring and observability operations so that CAP_PERFMON would assist
>> CAP_SYS_ADMIN capability in its governing role for
Le 18/02/2020 à 15:39, Naveen N. Rao a écrit :
Christophe Leroy wrote:
At the time being we have something like
if (something) {
p = get();
if (p) {
if (something_wrong)
goto out;
...
return;
} else if (a != b)
On Mon, 2020-02-03 at 15:10 +, Jonathan Cameron wrote:
> On Tue, 3 Dec 2019 14:46:52 +1100
> Alastair D'Silva wrote:
>
> > From: Alastair D'Silva
> >
> > The near storage command 'Secure Erase' overwrites all data on the
> > media.
> >
> > This patch hooks it up to the security function
On Mon, 2020-02-03 at 15:11 +, Jonathan Cameron wrote:
> On Tue, 3 Dec 2019 14:46:50 +1100
> Alastair D'Silva wrote:
>
> > From: Alastair D'Silva
> >
> > The heartbeat admin command is a simple admin command that
> > exercises
> > the communication mechanisms within the controller.
> >
>
On Mon, 2020-02-03 at 14:18 +, Jonathan Cameron wrote:
> On Tue, 3 Dec 2019 14:46:41 +1100
> Alastair D'Silva wrote:
>
> > From: Alastair D'Silva
> >
> > This patch requests the metadata required to issue admin commands,
> > as well
> > as some helper functions to construct and check the
On Mon, 2020-02-03 at 14:22 +, Jonathan Cameron wrote:
> On Tue, 3 Dec 2019 14:46:42 +1100
> Alastair D'Silva wrote:
>
> > From: Alastair D'Silva
> >
> > Similar to the previous patch, this adds support for near storage
> > commands.
> >
> > Signed-off-by: Alastair D'Silva
> > ---
> >
On Mon, 2020-02-03 at 13:23 +, Jonathan Cameron wrote:
> On Tue, 3 Dec 2019 14:46:40 +1100
> Alastair D'Silva wrote:
>
> > From: Alastair D'Silva
> >
> > This patch reads timeouts & firmware version from the controller,
> > and
> > uses those timeouts to wait for the controller to report
On Mon, 2020-02-03 at 13:20 +, Jonathan Cameron wrote:
> On Tue, 3 Dec 2019 14:46:38 +1100
> Alastair D'Silva wrote:
>
> > From: Alastair D'Silva
> >
> > This driver exposes LPC memory on OpenCAPI SCM cards
> > as an NVDIMM, allowing the existing nvram infrastructure
> > to be used.
> >
>
On Mon, 2020-02-03 at 12:53 +, Jonathan Cameron wrote:
> On Tue, 3 Dec 2019 14:46:36 +1100
> Alastair D'Silva wrote:
>
> > From: Alastair D'Silva
> >
> > This patch retrieves the serial number of the card and makes it
> > available
> > to consumers of the ocxl driver via the ocxl_fn
On Mon, 2020-02-03 at 12:49 +, Jonathan Cameron wrote:
> On Tue, 3 Dec 2019 14:46:35 +1100
> Alastair D'Silva wrote:
>
> > From: Alastair D'Silva
> >
> > Add functions to map/unmap LPC memory
> >
> > Signed-off-by: Alastair D'Silva
> > ---
> > drivers/misc/ocxl/config.c| 4 +++
On Wed, Feb 19, 2020 at 9:04 AM Michael Ellerman wrote:
>
> Some of our phony targets are not marked as such. This can lead to
> confusing errors, eg:
>
> $ make clean
> $ touch install
> $ make install
> make: 'install' is up to date.
> $
>
> Fix it by adding them to the PHONY variable
On Tue, Feb 18, 2020 at 02:39:37PM +0800, Shengjiu Wang wrote:
> EASRC (Enhanced Asynchronous Sample Rate Converter) is a new IP module
> found on i.MX8MN. It is different with old ASRC module.
>
> The primary features for the EASRC are as follows:
> - 4 Contexts - groups of channels with an
On Tue, 18 Feb 2020 19:38:27 + (UTC)
Christophe Leroy wrote:
> When a program check exception happens while MMU translation is
> disabled, following Oops happens in kprobe_handler() in the following
> code:
>
> } else if (*addr != BREAKPOINT_INSTRUCTION) {
>
> [ 33.098554]
Some of our phony targets are not marked as such. This can lead to
confusing errors, eg:
$ make clean
$ touch install
$ make install
make: 'install' is up to date.
$
Fix it by adding them to the PHONY variable which is marked phony in
the top-level Makefile, or in
On Mon, 2020-02-03 at 12:37 +, Jonathan Cameron wrote:
> On Tue, 3 Dec 2019 14:46:34 +1100
> Alastair D'Silva wrote:
>
> > From: Alastair D'Silva
> >
> > Tally up the LPC memory on an OpenCAPI link & allow it to be mapped
> >
> > Signed-off-by: Alastair D'Silva
> Hi Alastair,
>
> A few
On Fri, 2020-02-14 at 12:09 +0100, Frederic Barrat wrote:
>
> Le 03/12/2019 à 04:46, Alastair D'Silva a écrit :
> > From: Alastair D'Silva
> >
> > This patch adds platform support to map & release LPC memory.
> >
> > Signed-off-by: Alastair D'Silva
> > ---
> >
On Tue, Feb 18, 2020 at 8:19 PM Michael Ellerman wrote:
>
> Some of our phony targets are not marked as such. This can lead to
> confusing errors, eg:
>
> $ make clean
> $ touch install
> $ make install
> make: 'install' is up to date.
> $
>
> Fix it by adding them to the PHONY variable
On Tue, Feb 18, 2020 at 02:39:36PM +0800, Shengjiu Wang wrote:
> EASRC (Enhanced Asynchronous Sample Rate Converter) is a new
> IP module found on i.MX8MN.
>
> Signed-off-by: Shengjiu Wang
> ---
> .../devicetree/bindings/sound/fsl,easrc.txt | 57 +++
> 1 file changed, 57
Hi,
On 02/17/2020 04:37 AM, Segher Boessenkool wrote:
On Mon, Feb 17, 2020 at 05:23:07PM +1100, Michael Neuling wrote:
Hence, we should NOP this, not generate an illegal.
It is not a reserved bit.
The IMC entry for it matches op1=01 op2=101110 presumably, which
catches all TM
On P9 DD2.2 due to a CPU defect some TM instructions need to be emulated by
KVM. This is handled at first by the hardware raising a softpatch interrupt
when certain TM instructions that need KVM assistance are executed in the
guest. Althought some TM instructions per Power ISA are invalid forms
On Tue, Feb 18, 2020 at 1:00 PM Jeff Moyer wrote:
>
> Vaibhav Jain writes:
>
> > Presently the error code returned via out variable 'cmd_rc' from the
> > nvdimm-bus controller function is ignored when called from
> > __nd_ioctl() and never communicated back to user-space code that called
> > an
Vaibhav Jain writes:
> String 'bus_desc.provider_name' allocated inside
> of_pmem_region_probe() will leak in case call to nvdimm_bus_register()
> fails or when of_pmem_region_remove() is called.
>
> This minor patch ensures that 'bus_desc.provider_name' is freed in
> error path for
Vaibhav Jain writes:
> Presently the error code returned via out variable 'cmd_rc' from the
> nvdimm-bus controller function is ignored when called from
> __nd_ioctl() and never communicated back to user-space code that called
> an ioctl on dimm/bus.
>
> This minor patch updates __nd_ioctl() to
On Mon, 17 Feb 2020, Alexey Budankov wrote:
> For backward compatibility reasons access to the monitoring remains
> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
> for secure monitoring is discouraged with respect to CAP_PERFMON
> capability.
>
> Signed-off-by: Alexey
On Mon, 17 Feb 2020, Alexey Budankov wrote:
> For backward compatibility reasons access to the monitoring remains
> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
> for secure monitoring is discouraged with respect to CAP_PERFMON
> capability.
>
> Signed-off-by: Alexey
When a program check exception happens while MMU translation is
disabled, following Oops happens in kprobe_handler() in the following
code:
} else if (*addr != BREAKPOINT_INSTRUCTION) {
[ 33.098554] BUG: Unable to handle kernel data access on read at 0xe268
[ 33.105091]
Le 18/02/2020 à 15:55, Naveen N. Rao a écrit :
Christophe Leroy wrote:
When a program check exception happens while MMU translation is
disabled, following Oops happens in kprobe_handler() in the following
code:
} else if (*addr != BREAKPOINT_INSTRUCTION) {
[ 33.098554] BUG:
On Mon, 17 Feb 2020, Alexey Budankov wrote:
> For backward compatibility reasons access to the monitoring remains
> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
> for secure monitoring is discouraged with respect to CAP_PERFMON
> capability.
>
> Signed-off-by: Alexey
On Mon, 17 Feb 2020, Alexey Budankov wrote:
> For backward compatibility reasons access to the monitoring remains
> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
> for secure monitoring is discouraged with respect to CAP_PERFMON
> capability.
>
> Signed-off-by: Alexey
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Open access to bpf_trace monitoring for CAP_PERFMON privileged process.
> Providing the access under CAP_PERFMON capability singly, without the
> rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
> credentials and makes operation
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Open access to i915_perf monitoring for CAP_PERFMON privileged process.
> Providing the access under CAP_PERFMON capability singly, without the
> rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
> credentials and makes operation
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Extend error messages to mention CAP_PERFMON capability as an option
> to substitute CAP_SYS_ADMIN capability for secure system performance
> monitoring and observability. Make perf_event_paranoid_check() and
> __cmd_ftrace() to be aware of
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Open access to monitoring via kprobes and uprobes and eBPF tracing for
> CAP_PERFMON privileged process. Providing the access under CAP_PERFMON
> capability singly, without the rest of CAP_SYS_ADMIN credentials,
> excludes chances to misuse the
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Open access to monitoring of kernel code, cpus, tracepoints and
> namespaces data for a CAP_PERFMON privileged process. Providing the
> access under CAP_PERFMON capability singly, without the rest of
> CAP_SYS_ADMIN credentials, excludes chances to
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Introduce CAP_PERFMON capability designed to secure system performance
> monitoring and observability operations so that CAP_PERFMON would assist
> CAP_SYS_ADMIN capability in its governing role for performance
> monitoring and observability
On 2/17/20 3:06 AM, Alexey Budankov wrote:
Introduce CAP_PERFMON capability designed to secure system performance
monitoring and observability operations so that CAP_PERFMON would assist
CAP_SYS_ADMIN capability in its governing role for performance
monitoring and observability subsystems.
Le 18/02/2020 à 18:07, Radu Rendec a écrit :
Hi Everyone,
The saved NIP seems to be broken inside machine_check_exception() on
MPC8378, running Linux 4.9.191. The value is 0x900 most of the times,
but I have seen other weird values.
I've been able to track down the entry code to head_32.S
Hi Everyone,
The saved NIP seems to be broken inside machine_check_exception() on
MPC8378, running Linux 4.9.191. The value is 0x900 most of the times,
but I have seen other weird values.
I've been able to track down the entry code to head_32.S (vector 0x200),
but I'm not sure where/how the NIP
On Fri, Jun 28, 2019 at 12:51:19AM +0530, Hari Bathini wrote:
> Currently, if memory_limit is specified and it overlaps with memory to
> be reserved for capture kernel, memory_limit is adjusted to accommodate
> capture kernel. With memory reservation for capture kernel moved later
> (after
From: Hari Bathini
Currently, if memory_limit is specified and it overlaps with memory to
be reserved for capture kernel, memory_limit is adjusted to accommodate
capture kernel. With memory reservation for capture kernel moved later
(after enforcing memory limit), this adjustment no longer holds
From: Hari Bathini
Sometimes, memory reservation for KDump/FADump can overlap with memory
marked for hugepages. This overlap leads to error, hang in KDump case
and copy error reported by f/w in case of FADump, while trying to
capture dump. Report error while setting up memory for the capture
On Tue 18-02-20 20:41:12, Sachin Sant wrote:
>
> >> Yes, I can recreate the same problem with the patch applied on top of
> >> 5.6.0-rc2.
> >
> > And just to make sure. This was with
> > http://lkml.kernel.org/r/fff0e636-4c36-ed10-281c-8cdb0687c...@virtuozzo.com
> > right?
> >
> Yes, the same
>> Yes, I can recreate the same problem with the patch applied on top of
>> 5.6.0-rc2.
>
> And just to make sure. This was with
> http://lkml.kernel.org/r/fff0e636-4c36-ed10-281c-8cdb0687c...@virtuozzo.com
> right?
>
Yes, the same patch.
> If yes, is it possible that the specific node is
Christophe Leroy wrote:
When a program check exception happens while MMU translation is
disabled, following Oops happens in kprobe_handler() in the following
code:
} else if (*addr != BREAKPOINT_INSTRUCTION) {
[ 33.098554] BUG: Unable to handle kernel data access on read at
Christophe Leroy wrote:
if (a) {
if (b)
do_something();
}
Is equivalent to
if (a & b)
do_something();
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/kprobes.c | 58 +--
1
Christophe Leroy wrote:
At the time being we have something like
if (something) {
p = get();
if (p) {
if (something_wrong)
goto out;
...
return;
When a program check exception happens while MMU translation is
disabled, following Oops happens in kprobe_handler() in the following
code:
} else if (*addr != BREAKPOINT_INSTRUCTION) {
[ 33.098554] BUG: Unable to handle kernel data access on read at 0xe268
[ 33.105091]
When a program check exception happens while MMU translation is
disabled, following Oops happens in kprobe_handler() in the following
code:
} else if (*addr != BREAKPOINT_INSTRUCTION) {
[ 33.098554] BUG: Unable to handle kernel data access on read at 0xe268
[ 33.105091]
On Tue 18-02-20 19:30:33, Sachin Sant wrote:
>
>
> > On 18-Feb-2020, at 5:25 PM, Michal Hocko wrote:
> >
> > On Tue 18-02-20 17:10:47, Sachin Sant wrote:
> >>
> could you please test your boot with original patch from here:
>
> https://patchwork.kernel.org/patch/11360007/
>
Fixes: 12c3f1fd87bf ("powerpc/32s: get rid of CPU_FTR_601 feature")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/entry_32.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S
Masami, Christophe,
Apologies for pitching in late here...
Masami Hiramatsu wrote:
On Tue, 18 Feb 2020 12:04:41 +0100
Christophe Leroy wrote:
>> Nevertheless, if one symbol has been forgotten in the blacklist, I think
>> it is a problem if it generate Oopses.
>
> There is a long history
Le 18/02/2020 à 13:33, Masami Hiramatsu a écrit :
On Tue, 18 Feb 2020 12:04:41 +0100
Christophe Leroy wrote:
Nevertheless, if one symbol has been forgotten in the blacklist, I think
it is a problem if it generate Oopses.
There is a long history also on x86 to make a blacklist. Anyway,
pmu_inuse flag is part of lppaca struct which notifies the hypervisor
whether guest/partition is using PMUs. This provides a hint for
save/restore of PMU registers. Currently perf_event_print_debug()
does not check for pmu_inuse flag and it is not safe to use it to
dump PMU SPRs in a
pmu_inuse flag is part of lppaca struct which notifies the hypervisor
whether guest/partition is using PMUs. This provides a hint incase of
save/restore of PMU registers. And in power_pmu_enable(), linux sets
the pmu_inuse flag and then updates the PMU registers. Current sequence
in
On Tue, 18 Feb 2020 12:04:41 +0100
Christophe Leroy wrote:
> >> Nevertheless, if one symbol has been forgotten in the blacklist, I think
> >> it is a problem if it generate Oopses.
> >
> > There is a long history also on x86 to make a blacklist. Anyway, how did
> > you get this error on PPC32?
rence on read at 0x73b0
> [8.868439] Faulting instruction address: 0xc03d55f4
> [8.868444] Oops: Kernel access of bad area, sig: 11 [#1]
> [8.868449] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
> [8.868453] Modules linked in:
> [8.868458]
On 18.02.2020 14:38, Sachin Sant wrote:
>
>
>> On 18-Feb-2020, at 4:20 PM, Kirill Tkhai wrote:
>>
>> Hi, Sachin,
>>
>> On 18.02.2020 13:45, Sachin Sant wrote:
>>>
>>> commit a75056fc1e7c
>>> mm/memcontrol.c: allocate shrinker_map on appropriate NUMA node
>>>
>>> I can boot the kernel
Alexey Kardashevskiy writes:
> On 24/12/2019 10:32, Alexey Kardashevskiy wrote:
...
>>
>> I could rearrange the code even more but since there is no NVLink3
>> coming ever, I'd avoid changing it more than necessary. Thanks,
>
> Repost? Rework?
I'll just take v3.
cheers
o boot
[8.868433] BUG: Kernel NULL pointer dereference on read at 0x73b0
[8.868439] Faulting instruction address: 0xc03d55f4
[8.868444] Oops: Kernel access of bad area, sig: 11 [#1]
[8.868449] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
[8.868453] Modules
> On 18-Feb-2020, at 4:20 PM, Kirill Tkhai wrote:
>
> Hi, Sachin,
>
> On 18.02.2020 13:45, Sachin Sant wrote:
>>
>> commit a75056fc1e7c
>> mm/memcontrol.c: allocate shrinker_map on appropriate NUMA node
>>
>> I can boot the kernel successfully if the patch is reverted.
>
>
> could you
bad area, sig: 11 [#1]
>>> [8.768645] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
>>> [8.768650] Modules linked in:
>>> [8.768655] CPU: 19 PID: 1 Comm: systemd Not tainted
>>> 5.6.0-rc2-next-20200218-autotest #1
>>> [8.76
: 0xc03d55f4
[8.768641] Oops: Kernel access of bad area, sig: 11 [#1]
[8.768645] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
[8.768650] Modules linked in:
[8.768655] CPU: 19 PID: 1 Comm: systemd Not tainted
5.6.0-rc2-next-20200218-autotest #1
[8.768660] NIP: c03d55f4
D: 1 Comm: systemd Not tainted
> 5.6.0-rc2-next-20200218-autotest #1
> [8.768660] NIP: c03d55f4 LR: c03d5b94 CTR:
>
> [8.768666] REGS: c008b37836d0 TRAP: 0300 Not tainted
> (5.6.0-rc2-next-20200218-autotest)
> [8.768671] MSR: 8
Some of our phony targets are not marked as such. This can lead to
confusing errors, eg:
$ make clean
$ touch install
$ make install
make: 'install' is up to date.
$
Fix it by adding them to the PHONY variable which is marked phony in
the top-level Makefile. In
Le 18/02/2020 à 11:29, Masami Hiramatsu a écrit :
On Tue, 18 Feb 2020 06:58:06 +0100
Christophe Leroy wrote:
What do you mean by 'there' ? At the entry of kprobe_handler() ?
That's what my patch does, it checks whether MMU is disabled or not. If
it is, it converts the address to a
R_CPUS=2048 NUMA pSeries
>> [8.768650] Modules linked in:
>> [8.768655] CPU: 19 PID: 1 Comm: systemd Not tainted
>> 5.6.0-rc2-next-20200218-autotest #1
>> [8.768660] NIP: c03d55f4 LR: c03d5b94 CTR:
>>
>> [8.7
On Sun, Feb 16, 2020 at 11:41:07AM +0100, Christophe Leroy wrote:
>
>
> Le 16/02/2020 à 09:18, Mike Rapoport a écrit :
> > From: Mike Rapoport
> >
> > Implement primitives necessary for the 4th level folding, add walks of p4d
> > level where appropriate and replace 5level-fixup.h with
From: Christophe Leroy
Date: 2020-01-21 16:37:07
To:"王文虎" ,Andrew Donnellan
cc: Kate Stewart ,Richard Fontana
,Greg Kroah-Hartman
,linux-ker...@vger.kernel.org,wangwenhu
,Paul Mackerras
,triv...@kernel.org,Thomas Gleixner
,linuxppc-dev@lists.ozlabs.org,loneh...@hotmail.com
Subject: Re:
On Tue, 18 Feb 2020 06:58:06 +0100
Christophe Leroy wrote:
>
> What do you mean by 'there' ? At the entry of kprobe_handler() ?
>
> That's what my patch does, it checks whether MMU is disabled or not. If
> it is, it converts the address to a virtual address.
>
>
"Kajol Jain" wrote on 14/02/2020 01:36:06 PM:
> From: "Kajol Jain"
> To: linuxppc-dev@lists.ozlabs.org, m...@ellerman.id.au
> Cc: ma...@linux.vnet.ibm.com, a...@linux.vnet.ibm.com, Nageswara R
> Sastry/India/IBM@IBMIN, kj...@linux.ibm.com
> Date: 14/02/2020 01:36 PM
> Subject: [PATCH 2/2]
Manually convert some files from thermal, crypto and misc-devices
to ReST format.
This patch is against linux-next 20200217 tag.
v2:
- a small change at patch 2 to avoid uneeded whitespace changes;
- added 13 new patches at the end
Mauro Carvalho Chehab (24):
docs: thermal: convert
71 matches
Mail list logo
