"Dmitry V. Levin" writes:
> On Mon, Jan 20, 2025 at 02:51:38PM +0100, Christophe Leroy wrote:
>> Le 14/01/2025 à 18:04, Dmitry V. Levin a écrit :
>> > On Mon, Jan 13, 2025 at 06:34:44PM +0100, Christophe Leroy wrote:
>> >> Le 13/01/2025 à 18:10, Dmitry V. Levin a écrit :
>> >>> Bring syscall_set_r
Alexey Gladkov writes:
>
...
> I'm not a powerpc expert but shouldn't be used regs->gpr[3] via a
> regs_return_value() in system_call_exception() ?
Yes I agree.
> notrace long system_call_exception(struct pt_regs *regs, unsigned long r0)
> {
> ...
> r0 = do_syscall_trace_enter(regs
"Dmitry V. Levin" writes:
> On Thu, Jan 23, 2025 at 08:28:15PM +0200, Dmitry V. Levin wrote:
...
>> After looking at system_call_exception() I doubt this inconsistency can be
>> easily avoided, so I don't see how this patch could be enhanced further,
>> and what else could I do with the patch besi
Drop the unused DBG macro
Signed-off-by: Denis Kirjanov
---
arch/powerpc/platforms/powermac/feature.c | 8
arch/powerpc/platforms/powermac/smp.c | 8
arch/powerpc/platforms/powermac/time.c| 8
3 files changed, 24 deletions(-)
diff --git a/arch/powerpc/platform
Hello Christophe
On 24/01/25 19:44, Christophe Leroy wrote:
Le 24/01/2025 à 11:32, Sourabh Jain a écrit :
The fadump kernel boots with limited memory solely to collect the kernel
core dump. Having gigantic hugepages in the fadump kernel is of no use.
Many times, the fadump kernel encounters
The fadump kernel boots with limited memory solely to collect the kernel
core dump. Having gigantic hugepages in the fadump kernel is of no use.
Many times, the fadump kernel encounters OOM (Out of Memory) issues if
gigantic hugepages are allocated.
To address this, disable gigantic hugepages if f
On Sat, Jan 25, 2025 at 11:17:45PM +1100, Michael Ellerman wrote:
> "Dmitry V. Levin" writes:
[...]
> > The only case where I see some intersection is do_seccomp() where the
> > tracer would be able to see -ENOSYS in gpr[3]. However, the seccomp stop
> > is not the place where the tracer *reads*
On Sat, Jan 25, 2025 at 11:17:58PM +1100, Michael Ellerman wrote:
> "Dmitry V. Levin" writes:
> > On Thu, Jan 23, 2025 at 08:28:15PM +0200, Dmitry V. Levin wrote:
> ...
> >> After looking at system_call_exception() I doubt this inconsistency can be
> >> easily avoided, so I don't see how this patc