* Re: [PATCH] powerpc/bpf: fix write protecting JIT code
From: Michael Ellerman @ 2021-11-02 10:12 UTC (permalink / raw)
To: jniethe5, christophe.leroy, Hari Bathini, naveen.n.rao, daniel,
ast, mpe
Cc: songliubraving, netdev, john.fastabend, kpsingh, stable, andrii,
paulus, yhs, bpf, linuxppc-dev, kafai
In-Reply-To: <20211025055649.114728-1-hbathini@linux.ibm.com>
On Mon, 25 Oct 2021 11:26:49 +0530, Hari Bathini wrote:
> Running program with bpf-to-bpf function calls results in data access
> exception (0x300) with the below call trace:
>
> [c000000000113f28] bpf_int_jit_compile+0x238/0x750 (unreliable)
> [c00000000037d2f8] bpf_check+0x2008/0x2710
> [c000000000360050] bpf_prog_load+0xb00/0x13a0
> [c000000000361d94] __sys_bpf+0x6f4/0x27c0
> [c000000000363f0c] sys_bpf+0x2c/0x40
> [c000000000032434] system_call_exception+0x164/0x330
> [c00000000000c1e8] system_call_vectored_common+0xe8/0x278
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/bpf: fix write protecting JIT code
https://git.kernel.org/powerpc/c/44a8214de96bafb5210e43bfa2c97c19bf75af3d
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/powernv/prd: Unregister OPAL_MSG_PRD2 notifier during module unload
From: Michael Ellerman @ 2021-11-02 10:12 UTC (permalink / raw)
To: Vasant Hegde, linuxppc-dev; +Cc: dja
In-Reply-To: <20211028165716.41300-1-hegdevasant@linux.vnet.ibm.com>
On Thu, 28 Oct 2021 22:27:16 +0530, Vasant Hegde wrote:
> Commit 587164cd, introduced new opal message type (OPAL_MSG_PRD2) and added
> opal notifier. But I missed to unregister the notifier during module unload
> path. This results in below call trace if you try to unload and load
> opal_prd module.
>
> Also add new notifier_block for OPAL_MSG_PRD2 message.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/powernv/prd: Unregister OPAL_MSG_PRD2 notifier during module unload
https://git.kernel.org/powerpc/c/52862ab33c5d97490f3fa345d6529829e6d6637b
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/64s: Default to 64K pages for 64 bit book3s
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Joel Stanley, linuxppc-dev
In-Reply-To: <20211015001649.45591-1-joel@jms.id.au>
On Fri, 15 Oct 2021 10:46:49 +1030, Joel Stanley wrote:
> For 64-bit book3s the default should be 64K as that's what modern CPUs
> are designed for.
>
> The following defconfigs already set CONFIG_PPC_64K_PAGES:
>
> cell_defconfig
> pasemi_defconfig
> powernv_defconfig
> ppc64_defconfig
> pseries_defconfig
> skiroot_defconfig
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/64s: Default to 64K pages for 64 bit book3s
https://git.kernel.org/powerpc/c/f22969a6604165df658b99221b0aeb6918a9026d
cheers
^ permalink raw reply
* Re: [V3] powerpc/perf: Enable PMU counters post partition migration if PMU is active
From: Athira Rajeev @ 2021-11-02 11:00 UTC (permalink / raw)
To: Michael Ellerman
Cc: Nathan Lynch, maddy, rnsastry, kjain, Nicholas Piggin,
linuxppc-dev
In-Reply-To: <87sfwk7z0m.fsf@mpe.ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 9755 bytes --]
> On 29-Oct-2021, at 6:45 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Nicholas Piggin <npiggin@gmail.com <mailto:npiggin@gmail.com>> writes:
>> Excerpts from Athira Rajeev's message of October 29, 2021 1:05 pm:
>>> During Live Partition Migration (LPM), it is observed that perf
>>> counter values reports zero post migration completion. However
>>> 'perf stat' with workload continues to show counts post migration
>>> since PMU gets disabled/enabled during sched switches. But incase
>>> of system/cpu wide monitoring, zero counts were reported with 'perf
>>> stat' after migration completion.
>>>
>>> Example:
>>> ./perf stat -e r1001e -I 1000
>>> time counts unit events
>>> 1.001010437 22,137,414 r1001e
>>> 2.002495447 15,455,821 r1001e
>>> <<>> As seen in next below logs, the counter values shows zero
>>> after migration is completed.
>>> <<>>
>>> 86.142535370 129,392,333,440 r1001e
>>> 87.144714617 0 r1001e
>>> 88.146526636 0 r1001e
>>> 89.148085029 0 r1001e
>>
>> This is the output without the patch? After the patch it keeps counting
>> I suppose? And does the very large count go away too?
>>
>>>
>>> Here PMU is enabled during start of perf session and counter
>>> values are read at intervals. Counters are only disabled at the
>>> end of session. The powerpc mobility code presently does not handle
>>> disabling and enabling back of PMU counters during partition
>>> migration. Also since the PMU register values are not saved/restored
>>> during migration, PMU registers like Monitor Mode Control Register 0
>>> (MMCR0), Monitor Mode Control Register 1 (MMCR1) will not contain
>>> the value it was programmed with. Hence PMU counters will not be
>>> enabled correctly post migration.
>>>
>>> Fix this in mobility code by handling disabling and enabling of
>>> PMU in all cpu's before and after migration. Patch introduces two
>>> functions 'mobility_pmu_disable' and 'mobility_pmu_enable'.
>>> mobility_pmu_disable() is called before the processor threads goes
>>> to suspend state so as to disable the PMU counters. And disable is
>>> done only if there are any active events running on that cpu.
>>> mobility_pmu_enable() is called after the migrate is done to enable
>>> back the PMU counters.
>>>
>>> Since the performance Monitor counters ( PMCs) are not
>>> saved/restored during LPM, results in PMC value being zero and the
>>> 'event->hw.prev_count' being non-zero value. This causes problem
>>> during updation of event->count since we always accumulate
>>> (event->hw.prev_count - PMC value) in event->count. If
>>> event->hw.prev_count is greater PMC value, event->count becomes
>>> negative. To fix this, 'prev_count' also needs to be re-initialised
>>> for all events while enabling back the events. Hence read the
>>> existing events and clear the PMC index (stored in event->hw.idx)
>>> for all events im mobility_pmu_disable. By this way, event count
>>> settings will get re-initialised correctly in power_pmu_enable.
>>>
>>> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
>>> [ Fixed compilation error reported by kernel test robot ]
>>> Reported-by: kernel test robot <lkp@intel.com>
>>> ---
>>> Changelog:
>>> Change from v2 -> v3:
>>> Addressed review comments from Nicholas Piggin.
>>> - Removed the "migrate" field which was added in initial
>>> patch to address updation of event count settings correctly
>>> in power_pmu_enable. Instead read off existing events in
>>> mobility_pmu_disable before power_pmu_enable.
>>> - Moved the mobility_pmu_disable/enable declaration from
>>> rtas.h to perf event header file.
>>>
>>> Addressed review comments from Nathan.
>>> - Moved the mobility function calls from stop_machine
>>> context out to pseries_migrate_partition. Also now this
>>> is a per cpu invocation.
>>>
>>> Change from v1 -> v2:
>>> - Moved the mobility_pmu_enable and mobility_pmu_disable
>>> declarations under CONFIG_PPC_PERF_CTRS in rtas.h.
>>> Also included 'asm/rtas.h' in core-book3s to fix the
>>> compilation warning reported by kernel test robot.
>>>
>>> arch/powerpc/include/asm/perf_event.h | 8 +++++
>>> arch/powerpc/perf/core-book3s.c | 39 +++++++++++++++++++++++
>>> arch/powerpc/platforms/pseries/mobility.c | 7 ++++
>>> 3 files changed, 54 insertions(+)
>>>
>>> diff --git a/arch/powerpc/include/asm/perf_event.h b/arch/powerpc/include/asm/perf_event.h
>>> index 164e910bf654..88aab6cf840c 100644
>>> --- a/arch/powerpc/include/asm/perf_event.h
>>> +++ b/arch/powerpc/include/asm/perf_event.h
>>> @@ -17,6 +17,14 @@ static inline bool is_sier_available(void) { return false; }
>>> static inline unsigned long get_pmcs_ext_regs(int idx) { return 0; }
>>> #endif
>>>
>>> +#ifdef CONFIG_PPC_PERF_CTRS
>>> +void mobility_pmu_disable(void *unused);
>>> +void mobility_pmu_enable(void *unused);
>>> +#else
>>> +static inline void mobility_pmu_disable(void *unused) { }
>>> +static inline void mobility_pmu_enable(void *unused) { }
>>> +#endif
>>> +
>>> #ifdef CONFIG_FSL_EMB_PERF_EVENT
>>> #include <asm/perf_event_fsl_emb.h>
>>> #endif
>>> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
>>> index 73e62e9b179b..2e8c4c668fa3 100644
>>> --- a/arch/powerpc/perf/core-book3s.c
>>> +++ b/arch/powerpc/perf/core-book3s.c
>>> @@ -1343,6 +1343,33 @@ static void power_pmu_disable(struct pmu *pmu)
>>> local_irq_restore(flags);
>>> }
>>>
>>> +/*
>>> + * Called from pseries_migrate_partition() function
>>> + * before migration, from powerpc/mobility code.
>>> + */
>
> These are only needed if pseries is built, so should be inside a PSERIES
> ifdef.
Sure mpe, will address this change in next version
>
> This function should handle iterating over CPUs, that shouldn't be left
> up to the mobility.c code.
>
> And the names should be something like pmu_start_migration(),
> pmu_finish_migration().
Ok, will change
>
>>> +void mobility_pmu_disable(void *unused)
>>> +{
>>> + struct cpu_hw_events *cpuhw = this_cpu_ptr(&cpu_hw_events);
>>> + struct perf_event *event;
>>> +
>>> + if (cpuhw->n_events != 0) {
>>> + int i;
>>> +
>>> + power_pmu_disable(NULL);
>>> + /*
>>> + * Read off any pre-existing events because the register
>>> + * values may not be migrated.
>>> + */
>>> + for (i = 0; i < cpuhw->n_events; ++i) {
>>> + event = cpuhw->event[i];
>>> + if (event->hw.idx) {
>>> + power_pmu_read(event);
>>> + event->hw.idx = 0;
>>> + }
>>> + }
>>> + }
>>> +}
>>> +
>>> /*
>>> * Re-enable all events if disable == 0.
>>> * If we were previously disabled and events were added, then
>>> @@ -1515,6 +1542,18 @@ static void power_pmu_enable(struct pmu *pmu)
>>> local_irq_restore(flags);
>>> }
>>>
>>> +/*
>>> + * Called from pseries_migrate_partition() function
>>> + * after migration, from powerpc/mobility code.
>>> + */
>>> +void mobility_pmu_enable(void *unused)
>>> +{
>>> + struct cpu_hw_events *cpuhw = this_cpu_ptr(&cpu_hw_events);
>>> +
>>> + cpuhw->n_added = cpuhw->n_events;
>>> + power_pmu_enable(NULL);
>>> +}
>>> +
>>> static int collect_events(struct perf_event *group, int max_count,
>>> struct perf_event *ctrs[], u64 *events,
>>> unsigned int *flags)
>>> diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
>>> index e83e0891272d..3e96485ccba4 100644
>>> --- a/arch/powerpc/platforms/pseries/mobility.c
>>> +++ b/arch/powerpc/platforms/pseries/mobility.c
>>> @@ -22,6 +22,7 @@
>>> #include <linux/delay.h>
>>> #include <linux/slab.h>
>>> #include <linux/stringify.h>
>>> +#include <linux/perf_event.h>
>>>
>>> #include <asm/machdep.h>
>>> #include <asm/rtas.h>
>>> @@ -631,12 +632,18 @@ static int pseries_migrate_partition(u64 handle)
>>> if (ret)
>>> return ret;
>>>
>>> + /* Disable PMU before suspend */
>>> + on_each_cpu(&mobility_pmu_disable, NULL, 0);
>>
>> Why was this moved out of stop machine and to an IPI?
>>
>> My concern would be, what are the other CPUs doing at this time? Is it
>> possible they could take interrupts and schedule? Could that mess up the
>> perf state here?
>
> pseries_migrate_partition() is called directly from migration_store(),
> which is the sysfs store function, which can be called concurrently by
> different CPUs.
>
> It's also potentially called from rtas_syscall_dispatch_ibm_suspend_me(),
> from sys_rtas(), again with no locking.
>
> So we could have two CPUs calling into here at the same time, which
> might not crash, but is unlikely to work well.
>
> I think the lack of locking might have been OK in the past because only
> one CPU will successfully get the other CPUs to call do_join() in
> pseries_suspend(). But I could be wrong.
>
> Anyway, now that we're mutating the PMU state before suspending we need
> to be more careful. So I think we need a lock around the whole sequence.
Thanks for the review comments.
The PMU callback invocations were from inside stop machine ( inside “do_join” ) in initial version.
Moved these out to pseries_migrate_partition as an IPI so as to minimise calls to other sub-system from “do_join” context, as pointed by Nathan.
But if it is not safe to have per-cpu invocation from pseries_migrate_partition, should we handle this under the interrupt disable path in do_join itself ( as in the initial version ) ?
Please share your thoughts/suggestions.
Thanks
Athira
>
> cheers
[-- Attachment #2: Type: text/html, Size: 35735 bytes --]
^ permalink raw reply
* Re: [PATCH v2] powerpc/s64: Clarify that radix lacks DEBUG_PAGEALLOC
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Jordan Niethe, Joel Stanley, Christophe Leroy; +Cc: linuxppc-dev
In-Reply-To: <20211013213438.675095-1-joel@jms.id.au>
On Thu, 14 Oct 2021 08:04:38 +1030, Joel Stanley wrote:
> The page_alloc.c code will call into __kernel_map_pages when
> DEBUG_PAGEALLOC is configured and enabled.
>
> As the implementation assumes hash, this should crash spectacularly if
> not for a bit of luck in __kernel_map_pages. In this function
> linear_map_hash_count is always zero, the for loop exits without doing
> any damage.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/s64: Clarify that radix lacks DEBUG_PAGEALLOC
https://git.kernel.org/powerpc/c/4f703e7faa67a116016c4678fc88b507c12670c9
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/xmon: fix task state output
From: Michael Ellerman @ 2021-11-02 10:12 UTC (permalink / raw)
To: Denis Kirjanov, linuxppc-dev
In-Reply-To: <20211026133108.7113-1-kda@linux-powerpc.org>
On Tue, 26 Oct 2021 16:31:08 +0300, Denis Kirjanov wrote:
> p_state is unsigned since the commit 2f064a59a11f
>
> The patch also uses TASK_RUNNING instead of null.
>
>
Applied to powerpc/next.
[1/1] powerpc/xmon: fix task state output
https://git.kernel.org/powerpc/c/b1f896ce3542eb2eede5949ee2e481526fae1108
cheers
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Update powerpc KVM entry
From: Michael Ellerman @ 2021-11-02 10:12 UTC (permalink / raw)
To: paulus, Michael Ellerman, linuxppc-dev
Cc: kvm-ppc, pbonzini, npiggin, linux-kernel, kvm
In-Reply-To: <20211027061646.540708-1-mpe@ellerman.id.au>
On Wed, 27 Oct 2021 17:16:46 +1100, Michael Ellerman wrote:
> Paul is no longer handling patches for kvmppc.
>
> Instead we'll treat them as regular powerpc patches, taking them via the
> powerpc tree, using the topic/ppc-kvm branch when necessary.
>
> Also drop the web reference, it doesn't have any information
> specifically relevant to powerpc KVM.
>
> [...]
Applied to powerpc/next.
[1/1] MAINTAINERS: Update powerpc KVM entry
https://git.kernel.org/powerpc/c/19b27f37ca97d1e42453b9e48af1cccb296f6965
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/dcr: Use cmplwi instead of 3-argument cmpli
From: Michael Ellerman @ 2021-11-02 10:12 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: ndesaulniers
In-Reply-To: <20211014024424.528848-1-mpe@ellerman.id.au>
On Thu, 14 Oct 2021 13:44:24 +1100, Michael Ellerman wrote:
> In dcr-low.S we use cmpli with three arguments, instead of four
> arguments as defined in the ISA:
>
> cmpli cr0,r3,1024
>
> This appears to be a PPC440-ism, looking at the "PPC440x5 CPU Core
> User’s Manual" it shows cmpli having no L field, but implied to be 0 due
> to the core being 32-bit. It mentions that the ISA defines four
> arguments and recommends using cmplwi.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/dcr: Use cmplwi instead of 3-argument cmpli
https://git.kernel.org/powerpc/c/fef071be57dc43679a32d5b0e6ee176d6f12e9f2
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/pseries/mobility: ignore ibm, platform-facilities updates
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev; +Cc: tyreld, cheloha, ldufour
In-Reply-To: <20211020194703.2613093-1-nathanl@linux.ibm.com>
On Wed, 20 Oct 2021 14:47:03 -0500, Nathan Lynch wrote:
> On VMs with NX encryption, compression, and/or RNG offload, these
> capabilities are described by nodes in the ibm,platform-facilities device
> tree hierarchy:
>
> $ tree -d /sys/firmware/devicetree/base/ibm,platform-facilities/
> /sys/firmware/devicetree/base/ibm,platform-facilities/
> ├── ibm,compression-v1
> ├── ibm,random-v1
> └── ibm,sym-encryption-v1
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/pseries/mobility: ignore ibm, platform-facilities updates
https://git.kernel.org/powerpc/c/319fa1a52e438a6e028329187783a25ad498c4e6
cheers
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Book3S HV: H_ENTER filter out reserved HPTE[B] value
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: kvm-ppc, Nicholas Piggin, linuxppc-dev
In-Reply-To: <20211004145749.1331331-1-npiggin@gmail.com>
On Tue, 5 Oct 2021 00:57:49 +1000, Nicholas Piggin wrote:
> The HPTE B field is a 2-bit field with values 0b10 and 0b11 reserved.
> This field is also taken from the HPTE and used when KVM executes
> TLBIEs to set the B field of those instructions.
>
> Disallow the guest setting B to a reserved value with H_ENTER by
> rejecting it. This is the same approach already taken for rejecting
> reserved (unsupported) LLP values. This prevents the guest from being
> able to induce the host to execute TLBIE with reserved values, which
> is not known to be a problem with current processors but in theory it
> could prevent the TLBIE from working correctly in a future processor.
>
> [...]
Applied to powerpc/next.
[1/1] KVM: PPC: Book3S HV: H_ENTER filter out reserved HPTE[B] value
https://git.kernel.org/powerpc/c/322fda0405fecaaa540b0fa90393830aaadaf420
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/32e: Ignore ESR in instruction storage interrupt handler
From: Michael Ellerman @ 2021-11-02 10:12 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Jacques de Laval
In-Reply-To: <20211028133043.4159501-1-npiggin@gmail.com>
On Thu, 28 Oct 2021 23:30:43 +1000, Nicholas Piggin wrote:
> A e5500 machine running a 32-bit kernel sometimes hangs at boot,
> seemingly going into an infinite loop of instruction storage interrupts.
> The ESR SPR has a value of 0x800000 (store) when this happens, which is
> likely set by a previous store. An instruction TLB miss interrupt would
> then leave ESR unchanged, and if no PTE exists it calls directly to the
> instruction storage interrupt handler without changing ESR.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/32e: Ignore ESR in instruction storage interrupt handler
https://git.kernel.org/powerpc/c/81291383ffde08b23bce75e7d6b2575ce9d3475c
cheers
^ permalink raw reply
* Re: [PATCH v1] powerpc/64s/interrupt: Fix check_return_regs_valid false positive
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20211026122531.3599918-1-npiggin@gmail.com>
On Tue, 26 Oct 2021 22:25:31 +1000, Nicholas Piggin wrote:
> The check_return_regs_valid can cause a false positive if the return
> regs are marked as norestart and they are an HSRR type interrupt,
> because the low bit in the bottom of regs->trap causes interrupt
> type matching to fail.
>
> This can occcur for example on bare metal with a HV privileged doorbell
> interrupt that causes a signal, but do_signal returns early because
> get_signal() fails, and takes the "No signal to deliver" path. In this
> case no signal was delivered so the return location is not changed so
> return SRRs are not invalidated, yet set_trap_norestart is called, which
> messes up the match. Building go-1.16.6 is known to reproduce this.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/64s/interrupt: Fix check_return_regs_valid false positive
https://git.kernel.org/powerpc/c/4a5cb51f3db4be547225a4bce7a43d41b231382b
cheers
^ permalink raw reply
* Re: [PATCH v3] KVM: PPC: Tick accounting should defer vtime accounting 'til after IRQ handling
From: Michael Ellerman @ 2021-11-02 10:12 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Laurent Vivier, stable
In-Reply-To: <20211027142150.3711582-1-npiggin@gmail.com>
On Thu, 28 Oct 2021 00:21:50 +1000, Nicholas Piggin wrote:
> From: Laurent Vivier <lvivier@redhat.com>
>
> Commit 112665286d08 ("KVM: PPC: Book3S HV: Context tracking exit guest
> context before enabling irqs") moved guest_exit() into the interrupt
> protected area to avoid wrong context warning (or worse). The problem is
> that tick-based time accounting has not yet been updated at this point
> (because it depends on the timer interrupt firing), so the guest time
> gets incorrectly accounted to system time.
>
> [...]
Applied to powerpc/next.
[1/1] KVM: PPC: Tick accounting should defer vtime accounting 'til after IRQ handling
https://git.kernel.org/powerpc/c/235cee162459d96153d63651ce7ff51752528c96
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/security: Use a mutex for interrupt exit code patching
From: Michael Ellerman @ 2021-11-02 10:12 UTC (permalink / raw)
To: Russell Currey, linuxppc-dev; +Cc: npiggin
In-Reply-To: <20211027072410.40950-1-ruscur@russell.cc>
On Wed, 27 Oct 2021 17:24:10 +1000, Russell Currey wrote:
> The mitigation-patching.sh script in the powerpc selftests toggles
> all mitigations on and off simultaneously, revealing that rfi_flush
> and stf_barrier cannot safely operate at the same time due to races
> in updating the static key.
>
> On some systems, the static key code throws a warning and the kernel
> remains functional. On others, the kernel will hang or crash.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/security: Use a mutex for interrupt exit code patching
https://git.kernel.org/powerpc/c/3c12b4df8d5e026345a19886ae375b3ebc33c0b6
cheers
^ permalink raw reply
* Re: [PATCH] selftests/powerpc: Use date instead of EPOCHSECONDS in mitigation-patching.sh
From: Michael Ellerman @ 2021-11-02 10:12 UTC (permalink / raw)
To: Russell Currey, linuxppc-dev
In-Reply-To: <20211025102436.19177-1-ruscur@russell.cc>
On Mon, 25 Oct 2021 20:24:36 +1000, Russell Currey wrote:
> The EPOCHSECONDS environment variable was added in bash 5.0 (released
> 2019). Some distributions of the "stable" and "long-term" variety ship
> older versions of bash than this, so swap to using the date command
> instead.
>
> "%s" was added to coreutils `date` in 1993 so we should be good, but who
> knows, it is a GNU extension and not part of the POSIX spec for `date`.
>
> [...]
Applied to powerpc/next.
[1/1] selftests/powerpc: Use date instead of EPOCHSECONDS in mitigation-patching.sh
https://git.kernel.org/powerpc/c/cb662608e546d755e3e1b51b30a269459323bf24
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: mpc8349emitx: Make mcu_gpiochip_remove() return void
From: Michael Ellerman @ 2021-11-02 10:12 UTC (permalink / raw)
To: Scott Wood, Michael Ellerman, Uwe Kleine-König
Cc: Paul Mackerras, linuxppc-dev, kernel
In-Reply-To: <20211021105657.72572-1-u.kleine-koenig@pengutronix.de>
On Thu, 21 Oct 2021 12:56:57 +0200, Uwe Kleine-König wrote:
> Up to now mcu_gpiochip_remove() returns zero unconditionally. Make it
> return void instead which makes it easier to see in the callers that
> there is no error to handle.
>
> Also the return value of i2c remove callbacks is ignored anyway.
>
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: mpc8349emitx: Make mcu_gpiochip_remove() return void
https://git.kernel.org/powerpc/c/5d354dc35ebb0b224d627264c60f60dbda3a1bc3
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/kexec_file: Add of_node_put() before goto
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Wan Jiabing, linux-kernel, Paul Mackerras, Michael Ellerman,
Lakshmi Ramasubramanian, Sourabh Jain, Hari Bathini, linuxppc-dev,
Rob Herring, Thiago Jung Bauermann, Benjamin Herrenschmidt
Cc: kael_w
In-Reply-To: <20211018015418.10182-1-wanjiabing@vivo.com>
On Sun, 17 Oct 2021 21:54:16 -0400, Wan Jiabing wrote:
> Fix following coccicheck warning:
> ./arch/powerpc/kexec/file_load_64.c:698:1-22: WARNING: Function
> for_each_node_by_type should have of_node_put() before goto
>
> Early exits from for_each_node_by_type should decrement the
> node reference counter.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/kexec_file: Add of_node_put() before goto
https://git.kernel.org/powerpc/c/7453f501d443c7febf48809ee1c530b64d625c59
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pseries/iommu: Add of_node_put() before break
From: Michael Ellerman @ 2021-11-02 10:11 UTC (permalink / raw)
To: Wan Jiabing, linux-kernel, Frederic Barrat, Michael Ellerman,
Paul Mackerras, linuxppc-dev, Leonardo Bras, David Gibson,
Alexey Kardashevskiy, Benjamin Herrenschmidt
Cc: kael_w
In-Reply-To: <20211014075624.16344-1-wanjiabing@vivo.com>
On Thu, 14 Oct 2021 03:56:04 -0400, Wan Jiabing wrote:
> Fix following coccicheck warning:
>
> ./arch/powerpc/platforms/pseries/iommu.c:924:1-28: WARNING: Function
> for_each_node_with_property should have of_node_put() before break
>
> Early exits from for_each_node_with_property should decrement the
> node reference counter.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/pseries/iommu: Add of_node_put() before break
https://git.kernel.org/powerpc/c/915b368f6968122fcab31fd6441ed4ba7cc7574c
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/bpf: fix write protecting JIT code
From: Naveen N. Rao @ 2021-11-02 11:59 UTC (permalink / raw)
To: ast, christophe.leroy, Daniel Borkmann, Hari Bathini, jniethe5,
Michael Ellerman
Cc: songliubraving, netdev, john.fastabend, kpsingh, stable, andrii,
paulus, yhs, bpf, linuxppc-dev, kafai
In-Reply-To: <87zgqs8upq.fsf@mpe.ellerman.id.au>
Michael Ellerman wrote:
> Daniel Borkmann <daniel@iogearbox.net> writes:
>> On 10/25/21 8:15 AM, Naveen N. Rao wrote:
>>> Hari Bathini wrote:
>>>> Running program with bpf-to-bpf function calls results in data access
>>>> exception (0x300) with the below call trace:
>>>>
>>>> [c000000000113f28] bpf_int_jit_compile+0x238/0x750 (unreliable)
>>>> [c00000000037d2f8] bpf_check+0x2008/0x2710
>>>> [c000000000360050] bpf_prog_load+0xb00/0x13a0
>>>> [c000000000361d94] __sys_bpf+0x6f4/0x27c0
>>>> [c000000000363f0c] sys_bpf+0x2c/0x40
>>>> [c000000000032434] system_call_exception+0x164/0x330
>>>> [c00000000000c1e8] system_call_vectored_common+0xe8/0x278
>>>>
>>>> as bpf_int_jit_compile() tries writing to write protected JIT code
>>>> location during the extra pass.
>>>>
>>>> Fix it by holding off write protection of JIT code until the extra
>>>> pass, where branch target addresses fixup happens.
>>>>
>>>> Cc: stable@vger.kernel.org
>>>> Fixes: 62e3d4210ac9 ("powerpc/bpf: Write protect JIT code")
>>>> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
>>>> ---
>>>> arch/powerpc/net/bpf_jit_comp.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> Thanks for the fix!
>>>
>>> Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
>>
>> LGTM, I presume this fix will be routed via Michael.
>
> Thanks for reviewing, I've picked it up.
>
>> BPF selftests have plenty of BPF-to-BPF calls in there, too bad this was
>> caught so late. :/
>
> Yeah :/
>
> STRICT_KERNEL_RWX is not on by default in all our defconfigs, so that's
> probably why no one caught it.
Yeah, sorry - we should have caught this sooner.
>
> I used to run the BPF selftests but they stopped building for me a while
> back, I'll see if I can get them going again.
Ravi had started looking into getting the selftests working well before
he left. I will take a look at this.
Thanks,
Naveen
^ permalink raw reply
* Re: [PATCH v2 RESEND] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
From: Paul Moore @ 2021-11-02 13:01 UTC (permalink / raw)
To: patch-notifications
Cc: linux-kernel, linux-audit, Paul Mackerras, Eric Paris,
linuxppc-dev
In-Reply-To: <163584790624.1845480.1785827913484538939.b4-ty@ellerman.id.au>
On Tue, Nov 2, 2021 at 7:38 AM Michael Ellerman
<patch-notifications@ellerman.id.au> wrote:
>
> On Tue, 24 Aug 2021 13:36:13 +0000 (UTC), Christophe Leroy wrote:
> > Commit e65e1fc2d24b ("[PATCH] syscall class hookup for all normal
> > targets") added generic support for AUDIT but that didn't include
> > support for bi-arch like powerpc.
> >
> > Commit 4b58841149dc ("audit: Add generic compat syscall support")
> > added generic support for bi-arch.
> >
> > [...]
>
> Applied to powerpc/next.
>
> [1/1] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
> https://git.kernel.org/powerpc/c/566af8cda399c088763d07464463dc871c943b54
Did the test failure discussed earlier in this thread ever get
resolved? If not, this really shouldn't be in linux-next IMO.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] powerpc/bpf: fix write protecting JIT code
From: Michael Ellerman @ 2021-11-02 13:48 UTC (permalink / raw)
To: Naveen N. Rao, ast, christophe.leroy, Daniel Borkmann,
Hari Bathini, jniethe5
Cc: songliubraving, netdev, john.fastabend, kpsingh, stable, andrii,
paulus, yhs, bpf, linuxppc-dev, kafai
In-Reply-To: <1635854227.x13v13l6az.naveen@linux.ibm.com>
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com> writes:
> Michael Ellerman wrote:
>> Daniel Borkmann <daniel@iogearbox.net> writes:
>>> On 10/25/21 8:15 AM, Naveen N. Rao wrote:
>>>> Hari Bathini wrote:
>>>>> Running program with bpf-to-bpf function calls results in data access
>>>>> exception (0x300) with the below call trace:
>>>>>
>>>>> [c000000000113f28] bpf_int_jit_compile+0x238/0x750 (unreliable)
>>>>> [c00000000037d2f8] bpf_check+0x2008/0x2710
>>>>> [c000000000360050] bpf_prog_load+0xb00/0x13a0
>>>>> [c000000000361d94] __sys_bpf+0x6f4/0x27c0
>>>>> [c000000000363f0c] sys_bpf+0x2c/0x40
>>>>> [c000000000032434] system_call_exception+0x164/0x330
>>>>> [c00000000000c1e8] system_call_vectored_common+0xe8/0x278
>>>>>
>>>>> as bpf_int_jit_compile() tries writing to write protected JIT code
>>>>> location during the extra pass.
>>>>>
>>>>> Fix it by holding off write protection of JIT code until the extra
>>>>> pass, where branch target addresses fixup happens.
>>>>>
>>>>> Cc: stable@vger.kernel.org
>>>>> Fixes: 62e3d4210ac9 ("powerpc/bpf: Write protect JIT code")
>>>>> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
>>>>> ---
>>>>> arch/powerpc/net/bpf_jit_comp.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> Thanks for the fix!
>>>>
>>>> Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
>>>
>>> LGTM, I presume this fix will be routed via Michael.
>>
>> Thanks for reviewing, I've picked it up.
>>
>>> BPF selftests have plenty of BPF-to-BPF calls in there, too bad this was
>>> caught so late. :/
>>
>> Yeah :/
>>
>> STRICT_KERNEL_RWX is not on by default in all our defconfigs, so that's
>> probably why no one caught it.
>
> Yeah, sorry - we should have caught this sooner.
>
>>
>> I used to run the BPF selftests but they stopped building for me a while
>> back, I'll see if I can get them going again.
>
> Ravi had started looking into getting the selftests working well before
> he left. I will take a look at this.
Thanks.
I got them building with something like:
- turning on DEBUG_INFO and DEBUG_INFO_BTF and rebuilding vmlinux
- grabbing clang 13 from:
https://github.com/llvm/llvm-project/releases/download/llvmorg-13.0.0/clang+llvm-13.0.0-powerpc64le-linux-ubuntu-18.04.tar.xz
- PATH=$HOME/clang+llvm-13.0.0-powerpc64le-linux-ubuntu-18.04/bin/:$PATH
- apt install:
- libelf-dev
- dwarves
- python-docutils
- libcap-dev
The DEBUG_INFO requirement is a bit of a pain for me. I generally don't
build with that enabled, because the resulting kernels are stupidly
large. I'm not sure if that's a hard requirement, or if the vmlinux has
to match the running kernel exactly?
There is logic in tools/testing/bpf/Makefile to use VMLINUX_H instead of
extracting the BTF from the vmlinux (line 247), but AFAICS that's
unreachable since 1a3449c19407 ("selftests/bpf: Clarify build error if
no vmlinux"), which makes it a hard error to not have a VMLINUX_BTF.
cheers
^ permalink raw reply
* Re: KVM on POWER8 host lock up since 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C")
From: Michal Suchánek @ 2021-11-02 15:48 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: ro, linuxppc-dev, kvm-ppc, Hari Bathini
In-Reply-To: <1610628922.o1ihbt98xg.astroid@bobo.none>
On Thu, Jan 14, 2021 at 11:08:03PM +1000, Nicholas Piggin wrote:
> Excerpts from Michal Suchánek's message of January 14, 2021 10:40 pm:
> > On Mon, Oct 19, 2020 at 02:50:51PM +1000, Nicholas Piggin wrote:
> >> Excerpts from Nicholas Piggin's message of October 19, 2020 11:00 am:
> >> > Excerpts from Michal Suchánek's message of October 17, 2020 6:14 am:
> >> >> On Mon, Sep 07, 2020 at 11:13:47PM +1000, Nicholas Piggin wrote:
> >> >>> Excerpts from Michael Ellerman's message of August 31, 2020 8:50 pm:
> >> >>> > Michal Suchánek <msuchanek@suse.de> writes:
> >> >>> >> On Mon, Aug 31, 2020 at 11:14:18AM +1000, Nicholas Piggin wrote:
> >> >>> >>> Excerpts from Michal Suchánek's message of August 31, 2020 6:11 am:
> >> >>> >>> > Hello,
> >> >>> >>> >
> >> >>> >>> > on POWER8 KVM hosts lock up since commit 10d91611f426 ("powerpc/64s:
> >> >>> >>> > Reimplement book3s idle code in C").
> >> >>> >>> >
> >> >>> >>> > The symptom is host locking up completely after some hours of KVM
> >> >>> >>> > workload with messages like
> >> >>> >>> >
> >> >>> >>> > 2020-08-30T10:51:31+00:00 obs-power8-01 kernel: KVM: couldn't grab cpu 47
> >> >>> >>> > 2020-08-30T10:51:31+00:00 obs-power8-01 kernel: KVM: couldn't grab cpu 71
> >> >>> >>> > 2020-08-30T10:51:31+00:00 obs-power8-01 kernel: KVM: couldn't grab cpu 47
> >> >>> >>> > 2020-08-30T10:51:31+00:00 obs-power8-01 kernel: KVM: couldn't grab cpu 71
> >> >>> >>> > 2020-08-30T10:51:31+00:00 obs-power8-01 kernel: KVM: couldn't grab cpu 47
> >> >>> >>> >
> >> >>> >>> > printed before the host locks up.
> >> >>> >>> >
> >> >>> >>> > The machines run sandboxed builds which is a mixed workload resulting in
> >> >>> >>> > IO/single core/mutiple core load over time and there are periods of no
> >> >>> >>> > activity and no VMS runnig as well. The VMs are shortlived so VM
> >> >>> >>> > setup/terdown is somewhat excercised as well.
> >> >>> >>> >
> >> >>> >>> > POWER9 with the new guest entry fast path does not seem to be affected.
> >> >>> >>> >
> >> >>> >>> > Reverted the patch and the followup idle fixes on top of 5.2.14 and
> >> >>> >>> > re-applied commit a3f3072db6ca ("powerpc/powernv/idle: Restore IAMR
> >> >>> >>> > after idle") which gives same idle code as 5.1.16 and the kernel seems
> >> >>> >>> > stable.
> >> >>> >>> >
> >> >>> >>> > Config is attached.
> >> >>> >>> >
> >> >>> >>> > I cannot easily revert this commit, especially if I want to use the same
> >> >>> >>> > kernel on POWER8 and POWER9 - many of the POWER9 fixes are applicable
> >> >>> >>> > only to the new idle code.
> >> >>> >>> >
> >> >>> >>> > Any idea what can be the problem?
> >> >>> >>>
> >> >>> >>> So hwthread_state is never getting back to to HWTHREAD_IN_IDLE on
> >> >>> >>> those threads. I wonder what they are doing. POWER8 doesn't have a good
> >> >>> >>> NMI IPI and I don't know if it supports pdbg dumping registers from the
> >> >>> >>> BMC unfortunately.
> >> >>> >>
> >> >>> >> It may be possible to set up fadump with a later kernel version that
> >> >>> >> supports it on powernv and dump the whole kernel.
> >> >>> >
> >> >>> > Your firmware won't support it AFAIK.
> >> >>> >
> >> >>> > You could try kdump, but if we have CPUs stuck in KVM then there's a
> >> >>> > good chance it won't work :/
> >> >>>
> >> >>> I haven't had any luck yet reproducing this still. Testing with sub
> >> >>> cores of various different combinations, etc. I'll keep trying though.
> >> >>
> >> >> Hello,
> >> >>
> >> >> I tried running some KVM guests to simulate the workload and what I get
> >> >> is guests failing to start with a rcu stall. Tried both 5.3 and 5.9
> >> >> kernel and qemu 4.2.1 and 5.1.0
> >> >>
> >> >> To start some guests I run
> >> >>
> >> >> for i in $(seq 0 9) ; do /opt/qemu/bin/qemu-system-ppc64 -m 2048 -accel kvm -smp 8 -kernel /boot/vmlinux -initrd /boot/initrd -nodefaults -nographic -serial mon:telnet::444$i,server,wait & done
> >> >>
> >> >> To simulate some workload I run
> >> >>
> >> >> xz -zc9T0 < /dev/zero > /dev/null &
> >> >> while true; do
> >> >> killall -STOP xz; sleep 1; killall -CONT xz; sleep 1;
> >> >> done &
> >> >>
> >> >> on the host and add a job that executes this to the ramdisk. However, most
> >> >> guests never get to the point where the job is executed.
> >> >>
> >> >> Any idea what might be the problem?
> >> >
> >> > I would say try without pv queued spin locks (but if the same thing is
> >> > happening with 5.3 then it must be something else I guess).
> >> >
> >> > I'll try to test a similar setup on a POWER8 here.
> >>
> >> Couldn't reproduce the guest hang, they seem to run fine even with
> >> queued spinlocks. Might have a different .config.
> >>
> >> I might have got a lockup in the host (although different symptoms than
> >> the original report). I'll look into that a bit further.
> >
> > Hello,
> >
> > any progress on this?
>
> No progress, I still wasn't able to reproduce, and it fell off the
> radar sorry.
>
> I expect hwthred_state must be getting corrupted somewhere or a
> secondary thread getting stuck but I couldn't see where. I try pick
> it up again thanks for the reminder.
Hello,
the fixes pointed out in
https://lore.kernel.org/linuxppc-dev/87pmrtbbdt.fsf@mpe.ellerman.id.au/T/#u
resolve the problem.
Thanks
Michal
^ permalink raw reply
* Re: [PATCH 03/13] nvdimm/btt: do not call del_gendisk() if not needed
From: Luis Chamberlain @ 2021-11-02 17:03 UTC (permalink / raw)
To: Dan Williams
Cc: Linux NVDIMM, vigneshr, linux-nvme, Paul Mackerras, miquel.raynal,
Weiny, Ira, Christoph Hellwig, Dave Jiang, Sagi Grimberg,
Minchan Kim, Vishal L Verma, Nitin Gupta, linux-block,
Keith Busch, Jens Axboe, Geoff Levand, Linux Kernel Mailing List,
Jim Paris, senozhatsky, Richard Weinberger, linux-mtd,
linuxppc-dev
In-Reply-To: <CAPcyv4gU0q=UhDhGoDjK1mwS8WNcWYUXgEb7Rd8Amqr1XFs6ow@mail.gmail.com>
On Sun, Oct 31, 2021 at 10:47:22AM -0700, Dan Williams wrote:
> On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >
> > We know we don't need del_gendisk() if we haven't added
> > the disk, so just skip it. This should fix a bug on older
> > kernels, as del_gendisk() became able to deal with
> > disks not added only recently, after the patch titled
> > "block: add flag for add_disk() completion notation".
>
> Perhaps put this in:
>
> commit $abbrev_commit ("block: add flag for add_disk() completion notation")
>
> ...format, but I can't seem to find that commit?
Indeed, that patch got dropped and it would seem Christoph preferred
a simpler approach with the new disk_live()
commit 40b3a52ffc5bc3b5427d5d35b035cfb19d03fdd6
Author: Christoph Hellwig <hch@lst.de>
Date: Wed Aug 18 16:45:32 2021 +0200
block: add a sanity check for a live disk in del_gendisk
> If you're touching the changelog how about one that clarifies the
> impact and drops "we"?
> "del_gendisk() is not required if the disk has not been added. On
> kernels prior to commit $abbrev_commit ("block: add flag for
> add_disk() completion notation")
> it is mandatory to not call del_gendisk() if the underlying device has
> not been through device_add()."
>
> Fixes: 41cd8b70c37a ("libnvdimm, btt: add support for blk integrity")
>
> With that you can add:
>
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
You got it.
Luis
^ permalink raw reply
* Re: [PATCH] powerpc/bpf: fix write protecting JIT code
From: Andrii Nakryiko @ 2021-11-02 17:34 UTC (permalink / raw)
To: Michael Ellerman
Cc: Song Liu, Daniel Borkmann, jniethe5, john fastabend,
Alexei Starovoitov, Andrii Nakryiko, Paul Mackerras,
linux- stable, Networking, Naveen N. Rao, Yonghong Song, bpf,
KP Singh, linuxppc-dev, Martin Lau, Hari Bathini
In-Reply-To: <87h7cu8y98.fsf@mpe.ellerman.id.au>
On Tue, Nov 2, 2021 at 6:48 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> "Naveen N. Rao" <naveen.n.rao@linux.ibm.com> writes:
> > Michael Ellerman wrote:
> >> Daniel Borkmann <daniel@iogearbox.net> writes:
> >>> On 10/25/21 8:15 AM, Naveen N. Rao wrote:
> >>>> Hari Bathini wrote:
> >>>>> Running program with bpf-to-bpf function calls results in data access
> >>>>> exception (0x300) with the below call trace:
> >>>>>
> >>>>> [c000000000113f28] bpf_int_jit_compile+0x238/0x750 (unreliable)
> >>>>> [c00000000037d2f8] bpf_check+0x2008/0x2710
> >>>>> [c000000000360050] bpf_prog_load+0xb00/0x13a0
> >>>>> [c000000000361d94] __sys_bpf+0x6f4/0x27c0
> >>>>> [c000000000363f0c] sys_bpf+0x2c/0x40
> >>>>> [c000000000032434] system_call_exception+0x164/0x330
> >>>>> [c00000000000c1e8] system_call_vectored_common+0xe8/0x278
> >>>>>
> >>>>> as bpf_int_jit_compile() tries writing to write protected JIT code
> >>>>> location during the extra pass.
> >>>>>
> >>>>> Fix it by holding off write protection of JIT code until the extra
> >>>>> pass, where branch target addresses fixup happens.
> >>>>>
> >>>>> Cc: stable@vger.kernel.org
> >>>>> Fixes: 62e3d4210ac9 ("powerpc/bpf: Write protect JIT code")
> >>>>> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
> >>>>> ---
> >>>>> arch/powerpc/net/bpf_jit_comp.c | 2 +-
> >>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> Thanks for the fix!
> >>>>
> >>>> Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> >>>
> >>> LGTM, I presume this fix will be routed via Michael.
> >>
> >> Thanks for reviewing, I've picked it up.
> >>
> >>> BPF selftests have plenty of BPF-to-BPF calls in there, too bad this was
> >>> caught so late. :/
> >>
> >> Yeah :/
> >>
> >> STRICT_KERNEL_RWX is not on by default in all our defconfigs, so that's
> >> probably why no one caught it.
> >
> > Yeah, sorry - we should have caught this sooner.
> >
> >>
> >> I used to run the BPF selftests but they stopped building for me a while
> >> back, I'll see if I can get them going again.
> >
> > Ravi had started looking into getting the selftests working well before
> > he left. I will take a look at this.
>
> Thanks.
>
> I got them building with something like:
>
> - turning on DEBUG_INFO and DEBUG_INFO_BTF and rebuilding vmlinux
> - grabbing clang 13 from:
> https://github.com/llvm/llvm-project/releases/download/llvmorg-13.0.0/clang+llvm-13.0.0-powerpc64le-linux-ubuntu-18.04.tar.xz
> - PATH=$HOME/clang+llvm-13.0.0-powerpc64le-linux-ubuntu-18.04/bin/:$PATH
> - apt install:
> - libelf-dev
> - dwarves
> - python-docutils
> - libcap-dev
>
>
> The DEBUG_INFO requirement is a bit of a pain for me. I generally don't
We do need DWARF to be present during BTF generation. We don't really
need to preserve DWARF after BTF is generated, though. But no one
added that config option and corresponding optimization. If you can
figure out how to do that, I'm sure a bunch of folks will appreciate
being able to specify CONFIG_DEBUG_INFO_BTF without CONFIG_DEBUG_INFO
dependency.
> build with that enabled, because the resulting kernels are stupidly
> large. I'm not sure if that's a hard requirement, or if the vmlinux has
> to match the running kernel exactly?
>
> There is logic in tools/testing/bpf/Makefile to use VMLINUX_H instead of
> extracting the BTF from the vmlinux (line 247), but AFAICS that's
> unreachable since 1a3449c19407 ("selftests/bpf: Clarify build error if
> no vmlinux"), which makes it a hard error to not have a VMLINUX_BTF.
Yeah, you can pass pre-generated vmlinux.h through VMLINUX_H, which we
do for libbpf CI (see [0]) when running latest selftests against old
kernels (we test 4.9 and 5.5 currently). Latest vmlinux image (which
you can override with VMLINUX_BTF) is required for custom kernel
module which we use during selftests. But if you don't provide the
matching kernel, everything should still build fine, the test module
won't load properly and we'll skip a few tests. You still should get a
good coverage.
So in short, given we are able to build selftests and run it against
4.9 and 5.5, you should be able to as well.
[0] https://github.com/libbpf/libbpf/blob/master/travis-ci/vmtest/build_selftests.sh#L29-L30
>
> cheers
^ permalink raw reply
* Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to unrecoverable loop.
From: Joakim Tjernlund @ 2021-11-02 21:15 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org, Eugene_Bordenkircher@selinc.com,
linux-usb@vger.kernel.org
Cc: gregkh@linuxfoundation.org, balbi@kernel.org, leoyang.li@nxp.com
In-Reply-To: <2c275adc278477e1e512ea6ecc0c1f4dcc46969d.camel@infinera.com>
On Sat, 2021-10-30 at 14:20 +0000, Joakim Tjernlund wrote:
> On Fri, 2021-10-29 at 17:14 +0000, Eugene Bordenkircher wrote:
> > Hello all,
> >
> > We've discovered a situation where the FSL udc driver (drivers/usb/gadget/udc/fsl_udc_core.c) will enter a loop iterating over the request queue, but the queue has been corrupted at some point so it loops infinitely. I believe we have narrowed into the offending code, but we are in need of assistance trying to find an appropriate fix for the problem. The identified code appears to be in all versions of the Linux kernel the driver exists in.
> >
> > The problem appears to be when handling a USB_REQ_GET_STATUS request. The driver gets this request and then calls the ch9getstatus() function. In this function, it starts a request by "borrowing" the per device status_req, filling it in, and then queuing it with a call to list_add_tail() to add the request to the endpoint queue. Right before it exits the function however, it's calling ep0_prime_status(), which is filling out that same status_req structure and then queuing it with another call to list_add_tail() to add the request to the endpoint queue. This adds two instances of the exact same LIST_HEAD to the endpoint queue, which breaks the list since the prev and next pointers end up pointing to the wrong things. This ends up causing a hard loop the next time nuke() gets called, which happens on the next setup IRQ.
> >
> > I'm not sure what the appropriate fix to this problem is, mostly due to my lack of expertise in USB and this driver stack. The code has been this way in the kernel for a very long time, which suggests that it has been working, unless USB_REQ_GET_STATUS requests are never made. This further suggests that there is something else going on that I don't understand. Deleting the call to ep0_prime_status() and the following ep0stall() call appears, on the surface, to get the device working again, but may have side effects that I'm not seeing.
> >
> > I'm hopeful someone in the community can help provide some information on what I may be missing or help come up with a solution to the problem. A big thank you to anyone who would like to help out.
> >
> > Eugene
>
> Run into this to a while ago. Found the bug and a few more fixes.
> This is against 4.19 so you may have to tweak them a bit.
> Feel free to upstream them.
>
> Jocke
Curious, did my patches help? Good to known once we upgrade as well.
Jocke
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox