With the isolated mm context support, there is a CPU local variable that
can hold the patch address. Use it instead of adding a level of
indirection through the text_poke_area vm_struct.
Signed-off-by: Benjamin Gray
---
arch/powerpc/lib/code-patching.c | 3 ++-
1 file changed, 2 insertions(+),
From: "Christopher M. Riedl"
x86 supports the notion of a temporary mm which restricts access to
temporary PTEs to a single CPU. A temporary mm is useful for situations
where a CPU needs to perform sensitive operations (such as patching a
STRICT_KERNEL_RWX kernel) requiring temporary mappings
Adds a local TLB flush operation that works given an mm_struct, VA to
flush, and page size representation.
This removes the need to create a vm_area_struct, which the temporary
patching mm work does not need.
Signed-off-by: Benjamin Gray
---
arch/powerpc/include/asm/book3s/32/tlbflush.h |
Verifies that if the instruction patching did not return an error then
the value stored at the given address to patch is now equal to the
instruction we patched it to.
Signed-off-by: Benjamin Gray
---
arch/powerpc/lib/code-patching.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: "Christopher M. Riedl"
The latest kernel docs list BUG_ON() as 'deprecated' and that they
should be replaced with WARN_ON() (or pr_warn()) when possible. The
BUG_ON() in poking_init() warrants a WARN_ON() rather than a pr_warn()
since the error condition is deemed "unreachable".
Also take
From: Jordan Niethe
For the coming temporary mm used for instruction patching, the
breakpoint registers need to be cleared to prevent them from
accidentally being triggered. As soon as the patching is done, the
breakpoints will be restored. The breakpoint state is stored in the per
cpu variable
This is a revision of Chris and Jordan's series to introduces a per cpu
temporary
mm to be used for patching with strict rwx on radix mmus.
It is just rebased on powerpc/next. I am aware there are several code patching
patches on the list and can rebase when necessary. For now I figure this'll
>> When we do return to user mode the task is going to be busy servicing
>> a SIGBUS ... so shouldn't try to touch the poison page before the
>> memory_failure() called by the worker thread cleans things up.
>
> What about an RT process on a busy system?
> The worker threads are pretty low
From: Tony Luck
> Sent: 21 October 2022 05:08
> When we do return to user mode the task is going to be busy servicing
> a SIGBUS ... so shouldn't try to touch the poison page before the
> memory_failure() called by the worker thread cleans things up.
What about an RT process on a busy
On Fri, Oct 21, 2022 at 09:52:01AM +0800, Shuai Xue wrote:
>
>
> 在 2022/10/21 AM4:05, Tony Luck 写道:
> > On Thu, Oct 20, 2022 at 09:57:04AM +0800, Shuai Xue wrote:
> >>
> >>
> >> 在 2022/10/20 AM1:08, Tony Luck 写道:
> > I'm experimenting with using sched_work() to handle the call to
> >
>> +INIT_WORK(>work, do_sched_memory_failure);
>> +p->pfn = pfn;
>> +schedule_work(>work);
>
> There is already memory_failure_queue() that can do this. Can we use it
> directly?
Miaohe Lin,
Yes, can use that. A thousand thanks for pointing it out. I just tried it, and
it works
在 2022/10/21 AM4:05, Tony Luck 写道:
> On Thu, Oct 20, 2022 at 09:57:04AM +0800, Shuai Xue wrote:
>>
>>
>> 在 2022/10/20 AM1:08, Tony Luck 写道:
>>> If the kernel is copying a page as the result of a copy-on-write
>>> fault and runs into an uncorrectable error, Linux will crash because
>>> it does
On 2022/10/21 4:05, Tony Luck wrote:
> On Thu, Oct 20, 2022 at 09:57:04AM +0800, Shuai Xue wrote:
>>
>>
>> 在 2022/10/20 AM1:08, Tony Luck 写道:
>>> If the kernel is copying a page as the result of a copy-on-write
>>> fault and runs into an uncorrectable error, Linux will crash because
>>> it does
v6.1-rc1 next-20221020]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Bjorn
v6.1-rc1 next-20221020]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Bjorn-Helgaas
On Thu, Oct 20, 2022 at 09:57:04AM +0800, Shuai Xue wrote:
>
>
> 在 2022/10/20 AM1:08, Tony Luck 写道:
> > If the kernel is copying a page as the result of a copy-on-write
> > fault and runs into an uncorrectable error, Linux will crash because
> > it does not have recovery code for this case where
preempt_enable_no_resched() is just the same as preempt_enable() when we
are in a irqs disabled context. kprobe_handler() and the post/fault
handlers are all called with irqs disabled. As such, convert those to
just use preempt_enable().
Reported-by: Nicholas Piggin
Signed-off-by: Naveen N. Rao
Many of these headers are not necessary since those are included
indirectly, or the code using those headers has been removed.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/kernel/kprobes-ftrace.c | 4
arch/powerpc/kernel/kprobes.c| 2 --
2 files changed, 6 deletions(-)
diff --git
Ensure a more consistent pt_regs across kprobes, optprobes and
KPROBES_ON_FTRACE:
- Drop setting trap to 0x700 under optprobes. This is not accurate and
is unnecessary. Instead, zero it out for both optprobes and
KPROBES_ON_FTRACE.
- Save irq soft mask in the ftrace handler, similar to what we
Similar to x86 commit 2e62024c265aa6 ("kprobes/x86: Use preempt_enable()
in optimized_callback()"), change powerpc optprobes to use
preempt_enable() rather than preempt_enable_no_resched() since powerpc
also removed irq disabling for optprobes in commit f72180cc93a2c6
("powerpc/kprobes: Do not
arch_prepare_kprobe() is called from register_kprobe() via
prepare_kprobe(), or through register_aggr_kprobe(), both with the
kprobe_mutex held. Per the comment for get_kprobe():
/*
* This routine is called either:
*- under the 'kprobe_mutex' - during kprobe_[un]register().
*
This series attempts to address some of the concerns raised in
https://github.com/linuxppc/issues/issues/440
The last two patches are minor cleanups in related kprobes code.
- Naveen
Naveen N. Rao (5):
powerpc/kprobes: Remove preempt disable around call to get_kprobe() in
On Thursday 20 October 2022 08:45:47 Bjorn Helgaas wrote:
> [+cc Pali, heads-up for trivial addition of to
> pci-mvebu.c]
...
> pci-mvebu.c also relies on getting via
> , but it actually depends on of_irq.h, so I'll just
> add an irqdomain.h include there.
>
> Bjorn
>
Ok, that is fine!
On 10/19/22 10:44 PM, Bagas Sanjaya wrote:
> On 10/19/22 06:11, Sean Anderson wrote:
>> This adds support for the Lynx 10G SerDes found on the QorIQ T-series
>> and Layerscape series. Due to limited time and hardware, only support
>> for the LS1046ARDB is added in this initial series. There is
On Thu, Oct 20, 2022 at 10:13:10PM +0800, kernel test robot wrote:
> Hi Bjorn,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on helgaas-pci/next]
> [also build test ERROR on xilinx-xlnx/master rockchip/for-next linus/master
> v6.1-rc1 next
; [also build test ERROR on xilinx-xlnx/master rockchip/for-next linus/master
> > v6.1-rc1 next-20221020]
> > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > And when submitting patch, we suggest to use '--base' as documented in
> > https://git-scm
On Thu, Oct 20, 2022 at 12:36:56PM +0530, Athira Rajeev wrote:
> commit 838d9bb62d13 ("perf: Use sample_flags for raw_data")
> added check for PERF_SAMPLE_RAW in sample_flags in
> perf_prepare_sample(). But while copying the sample in memory,
> the check for sample_flags is not added in
On Thu, Oct 20, 2022 at 08:45:47AM -0500, Bjorn Helgaas wrote:
> [+cc Pali, heads-up for trivial addition of to
> pci-mvebu.c]
>
> On Thu, Oct 20, 2022 at 08:20:25AM +0100, Conor Dooley wrote:
> > On Thu, Oct 20, 2022 at 03:08:50PM +0800, kernel test robot wrote:
> > > Hi Bjorn,
> > >
> > > I
[+cc Pali, heads-up for trivial addition of to
pci-mvebu.c]
On Thu, Oct 20, 2022 at 08:20:25AM +0100, Conor Dooley wrote:
> On Thu, Oct 20, 2022 at 03:08:50PM +0800, kernel test robot wrote:
> > Hi Bjorn,
> >
> > I love your patch! Yet something to improve:
> >
> > >>
On Thu, Oct 20, 2022 at 04:09:37PM +0800, kernel test robot wrote:
> Hi Bjorn,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on helgaas-pci/next]
> [also build test ERROR on xilinx-xlnx/master rockchip/for-next linus/master
> v6.1-rc1 next
在 2022/10/20 AM1:08, Tony Luck 写道:
> If the kernel is copying a page as the result of a copy-on-write
> fault and runs into an uncorrectable error, Linux will crash because
> it does not have recovery code for this case where poison is consumed
> by the kernel.
>
> It is easy to set up a test
On Thu, 06 Oct 2022 22:29:59 -0700, Haren Myneni wrote:
> The hypervisor assigns VAS (Virtual Accelerator Switchboard)
> windows depends on cores configured in LPAR. The kernel uses
> OF reconfig notifier to reconfig VAS windows for DLPAR CPU event.
> In the case of shared CPU mode partition, the
On Sun, 09 Oct 2022 20:41:25 -0700, Haren Myneni wrote:
> irq_default_primary_handler() can be used only with IRQF_ONESHOT
> flag, but the flag disables IRQ before executing the thread handler
> and enables it after the interrupt is handled. But this IRQ disable
> sets the VAS IRQ OFF state in the
"Nicholas Piggin" writes:
> On Wed Oct 19, 2022 at 8:21 PM AEST, Dan Horák wrote:
>> Hi,
>>
>> in my first boot with the 6.1 rc1 kernel I have received a couple of
>> warnings from change_protection on Talos II P9 system, see the details
>> below. Nothing like that was noticed in 6.0 or earlier.
On Thu Oct 20, 2022 at 2:55 PM AEST, Sachin Sant wrote:
> While running powerpc kselftests (mm/stress_code_patching.sh)
> on a PowerVM LPAR following warning is seen. The test passes.
> I can reliably recreate it on a Power9 server, not so easily on
> Power10.
>
> # ./stress_code_patching.sh
>
On Wed Oct 19, 2022 at 8:21 PM AEST, Dan Horák wrote:
> Hi,
>
> in my first boot with the 6.1 rc1 kernel I have received a couple of
> warnings from change_protection on Talos II P9 system, see the details
> below. Nothing like that was noticed in 6.0 or earlier.
Thanks for the report. This is a
commit 838d9bb62d13 ("perf: Use sample_flags for raw_data")
added check for PERF_SAMPLE_RAW in sample_flags in
perf_prepare_sample(). But while copying the sample in memory,
the check for sample_flags is not added in perf_output_sample().
Fix adds the same in perf_output_sample as well.
Fixes:
commit 838d9bb62d13 ("perf: Use sample_flags for raw_data")
added check for PERF_SAMPLE_RAW in sample_flags in
perf_prepare_sample(). But while copying the sample in memory,
the check for sample_flags is not added in perf_output_sample().
Fix adds the same in perf_output_sample as well.
Fixes:
On 10/18/22 1:35 PM, Michael Ellerman wrote:
Kajol Jain writes:
Based on getPerfCountInfo v1.018 documentation, some of the
hv_gpci events got deprecated for platforms firmware that
supports counter_info_version 0x8 or above.
Patch fixes the hv_gpci event list by adding a new attribute
39 matches
Mail list logo
