Re: [PATCH 0/3] powerpc: convert to use ARCH_ATOMIC
On Wed, 11 Nov 2020 21:07:20 +1000, Nicholas Piggin wrote: > This conversion seems to require generic atomic64 changes, looks > like nothing else uses ARCH_ATOMIC and GENERIC_ATOMIC64 yet. > > Thanks, > Nick > > Nicholas Piggin (3): > asm-generic/atomic64: Add support for ARCH_ATOMIC > powerpc/64s/iommu: don't use atomic_ function on atomic64_t type > powerpc: rewrite atomics to use ARCH_ATOMIC > > [...] Patch 2 applied to powerpc/next. [2/3] powerpc/64s/iommu: Don't use atomic_ function on atomic64_t type https://git.kernel.org/powerpc/c/c33cd1ed60013ec2ae50f91fed260def5f1d9851 cheers
Re: [PATCH v7 updated 21/22 ] powerpc/book3s64/kup: Check max key supported before enabling kup
On Fri, 27 Nov 2020 10:14:02 +0530, Aneesh Kumar K.V wrote: > Don't enable KUEP/KUAP if we support less than or equal to 3 keys. > > [...] Applied to powerpc/next. [21/22] powerpc/book3s64/kup: Check max key supported before enabling kup https://git.kernel.org/powerpc/c/61130e203dca3ba1f0c510eb12f7a4294e31a834 cheers
Re: [PATCH] powerpc/book3s64/kuap: Improve error reporting with KUAP
On Tue, 8 Dec 2020 08:45:39 +0530, Aneesh Kumar K.V wrote:
> This partially reverts commit eb232b162446 ("powerpc/book3s64/kuap: Improve
> error reporting with KUAP") and update the fault handler to print
>
> [ 55.022514] Kernel attempted to access user page (7e6725b7) - exploit
> attempt? (uid: 0)
> [ 55.022528] BUG: Unable to handle kernel data access on read at
> 0x7e6725b7
> [ 55.022533] Faulting instruction address: 0xc0e8b9bc
> [ 55.022540] Oops: Kernel access of bad area, sig: 11 [#1]
>
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/book3s64/kuap: Improve error reporting with KUAP
https://git.kernel.org/powerpc/c/475c8749d9542392d7e0855097d29ed14877ad0a
cheers
Re: [PATCH 2/3] kbuild: LD_VERSION redenomination
On Sun, Dec 13, 2020 at 01:54:30AM +0900, Masahiro Yamada wrote:
> Commit ccbef1674a15 ("Kbuild, lto: add ld-version and ld-ifversion
> macros") introduced scripts/ld-version.sh for GCC LTO.
>
> At that time, this script handled 5 version fields because GCC LTO
> needed the downstream binutils. (https://lkml.org/lkml/2014/4/8/272)
>
> The code snippet from the submitted patch was as follows:
>
> # We need HJ Lu's Linux binutils because mainline binutils does not
> # support mixing assembler and LTO code in the same ld -r object.
> # XXX check if the gcc plugin ld is the expected one too
> # XXX some Fedora binutils should also support it. How to check for that?
> ifeq ($(call ld-ifversion,-ge,22710001,y),y)
> ...
>
> However, GCC LTO was not merged into the mainline after all.
> (https://lkml.org/lkml/2014/4/8/272)
>
> So, the 4th and 5th fields were never used, and finally removed by
> commit 0d61ed17dd30 ("ld-version: Drop the 4th and 5th version
> components").
>
> Since then, the last 4-digits returned by this script is always zeros.
>
> Remove the meaningless last 4-digits. This makes the version format
> consistent with GCC_VERSION, CLANG_VERSION, LLD_VERSION.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/mips/loongson64/Platform | 2 +-
> arch/mips/vdso/Kconfig| 2 +-
Acked-by: Thomas Bogendoerfer
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [PATCH] powerpc/book3s64/kuap: Improve error reporting with KUAP
Michael Ellerman writes:
> On Tue, 8 Dec 2020 08:45:39 +0530, Aneesh Kumar K.V wrote:
>> This partially reverts commit eb232b162446 ("powerpc/book3s64/kuap: Improve
>> error reporting with KUAP") and update the fault handler to print
>>
>> [ 55.022514] Kernel attempted to access user page (7e6725b7) - exploit
>> attempt? (uid: 0)
>> [ 55.022528] BUG: Unable to handle kernel data access on read at
>> 0x7e6725b7
>> [ 55.022533] Faulting instruction address: 0xc0e8b9bc
>> [ 55.022540] Oops: Kernel access of bad area, sig: 11 [#1]
>>
>>
>> [...]
>
> Applied to powerpc/next.
>
> [1/1] powerpc/book3s64/kuap: Improve error reporting with KUAP
>
> https://git.kernel.org/powerpc/c/eb232b1624462752dc916d9015b31ecdac0a01f1
This is wrong, the script was confused by two patches with the exact
same subject. See the other mail.
cheers
Re: [PATCH v1 01/20] powerpc/feature: Fix CPU_FTRS_ALWAYS by removing CPU_FTRS_GENERIC_32
On Thu, 22 Oct 2020 06:29:26 + (UTC), Christophe Leroy wrote: > On 8xx, we get the following features: > > [0.00] cpu_features = 0x0100 > [0.00] possible= 0x0120 > [0.00] always = 0x > > This is not correct. As CONFIG_PPC_8xx is mutually exclusive with all > other configurations, the three lines should be equal. > > [...] Patches 1-19 applied to powerpc/next. [01/20] powerpc/feature: Fix CPU_FTRS_ALWAYS by removing CPU_FTRS_GENERIC_32 https://git.kernel.org/powerpc/c/78665179e569c7e1fe102fb6c21d0f5b6951f084 [02/20] powerpc/mm: Add mask of always present MMU features https://git.kernel.org/powerpc/c/f9158d58a4e1d91f21741e4e8ebe67f770b84e12 [03/20] powerpc/mm: Remove flush_tlb_page_nohash() prototype. https://git.kernel.org/powerpc/c/a54d310856b9c1fe15ad67a2f8ee9edc02965a3a [04/20] powerpc/32s: Make bat_addrs[] static https://git.kernel.org/powerpc/c/03d5b19c7243d6e605d360972dd7b701e2b1ba72 [05/20] powerpc/32s: Use mmu_has_feature(MMU_FTR_HPTE_TABLE) instead of checking Hash var https://git.kernel.org/powerpc/c/4cc445b4ff456f3a3997c321d7a353360feea04f [06/20] powerpc/32s: Make Hash var static https://git.kernel.org/powerpc/c/4b74a35fc7e9b8efd9067b8a365bab0fefe889ff [07/20] powerpc/32s: Declare Hash related vars as __initdata https://git.kernel.org/powerpc/c/6e980b5c56a266de479fcd022a03e094574e9a03 [08/20] powerpc/32s: Move _tlbie() and _tlbia() prototypes to tlbflush.h https://git.kernel.org/powerpc/c/cfe32ad0b3dc74df34ab6fea38ccb1e53f904a10 [09/20] powerpc/32s: Inline _tlbie() on non SMP https://git.kernel.org/powerpc/c/b91280f3f36d64cc6f8022893af00935c99de197 [10/20] powerpc/32s: Move _tlbie() and _tlbia() in a new file https://git.kernel.org/powerpc/c/f265512582a047e09390b1b41384f365d7dc806f [11/20] powerpc/32s: Split and inline flush_tlb_mm() and flush_tlb_page() https://git.kernel.org/powerpc/c/fd1b4b7f51d0d75b73eeda41ef459ea7791aaab2 [12/20] powerpc/32s: Inline flush_tlb_range() and flush_tlb_kernel_range() https://git.kernel.org/powerpc/c/1e83396f29d75aae8a1d365f597996fec87ca4d0 [13/20] powerpc/32s: Split and inline flush_range() https://git.kernel.org/powerpc/c/91ec450f8d8c1e599a943c526ab1d2a4acf73c22 [14/20] powerpc/32s: Inline tlb_flush() https://git.kernel.org/powerpc/c/ef08d95546ccea540f6a592b89822bb085bf09c6 [15/20] powerpc/32s: Inline flush_hash_entry() https://git.kernel.org/powerpc/c/80007a17fc59bc2766f7d5cb2f79b4c65651504b [16/20] powerpc/32s: Move early_mmu_init() into mmu.c https://git.kernel.org/powerpc/c/068fdba10ea54b6ebc12c2b2d85020b2137316d1 [17/20] powerpc/32s: Remove CONFIG_PPC_BOOK3S_6xx https://git.kernel.org/powerpc/c/a6a50d8495d098b6459166c3707ab251d3dc9e06 [18/20] powerpc/32s: Regroup 603 based CPUs in cputable https://git.kernel.org/powerpc/c/ad510e37e4b48f7da462650946aeaa078b977277 [19/20] powerpc/32s: Make support for 603 and 604+ selectable https://git.kernel.org/powerpc/c/44e9754d63c7b419874e4c18c0b5e7a770e058c6 cheers
Re: [PATCH v4 1/6] powerpc/book3s64/kuap: Improve error reporting with KUAP
On Wed, 9 Dec 2020 05:29:20 + (UTC), Christophe Leroy wrote:
> This partially reverts commit eb232b162446 ("powerpc/book3s64/kuap: Improve
> error reporting with KUAP") and update the fault handler to print
>
> [ 55.022514] Kernel attempted to access user page (7e6725b7) - exploit
> attempt? (uid: 0)
> [ 55.022528] BUG: Unable to handle kernel data access on read at
> 0x7e6725b7
> [ 55.022533] Faulting instruction address: 0xc0e8b9bc
> [ 55.022540] Oops: Kernel access of bad area, sig: 11 [#1]
>
>
> [...]
Patches 2-6 applied to powerpc/next.
[2/6] powerpc/mm: sanity_check_fault() should work for all, not only BOOK3S
https://git.kernel.org/powerpc/c/7ceb40027e19567a0a066e3b380cc034cdd9a124
[3/6] powerpc/fault: Unnest definition of page_fault_is_write() and
page_fault_is_bad()
https://git.kernel.org/powerpc/c/5250d026d241febfaf226d26cabe528fc478e225
[4/6] powerpc/mm: Move the WARN() out of bad_kuap_fault()
https://git.kernel.org/powerpc/c/3dc12dfe74300febc568c3b530c0f9bee01f2821
[5/6] powerpc/fault: Avoid heavy search_exception_tables() verification
https://git.kernel.org/powerpc/c/cbd7e6ca0210db05c315a27bb5db5a482f2772ce
[6/6] powerpc/fault: Perform exception fixup in do_page_fault()
https://git.kernel.org/powerpc/c/5f1888a077069988218805534f56b983b6d5710c
cheers
Re: [PATCH] powerpc/vas: Fix IRQ name allocation
On Sat, 2020-12-12 at 15:27 +0100, Cédric Le Goater wrote:
> The VAS device allocates a generic interrupt to handle page faults
> but
> the IRQ name doesn't show under /proc. This is because it's on
> stack. Allocate the name.
>
> Signed-off-by: Cédric Le Goater
Thanks for fixing.
Acked-by: Haren Myneni
> ---
>
> I didn't understand this part in init_vas_instance() :
>
> if (vinst->virq) {
> rc = vas_irq_fault_window_setup(vinst);
> /*
>* Fault window is used only for user space send
> windows.
>* So if vinst->virq is NULL, tx_win_open returns
> -ENODEV
>* for user space.
>*/
> if (rc)
> vinst->virq = 0;
> }
>
> If the IRQ cannot be requested, the device probing should fail but
> it's not today. The use of 'vinst->virq' is suspicious.
VAS raises an interrupt only when NX sees fault on request buffers and
faults can happen only for user space requests. So Fault window setup
is needed for user space requests. For kernel requests, continue even
if IRQ / fault_window_setup is failed.
When window open request is issued from user space, kernel returns
-ENODEV if vinst->virq = 0 (means fault window setup is failed).
>
> arch/powerpc/platforms/powernv/vas.h | 1 +
> arch/powerpc/platforms/powernv/vas.c | 11 ---
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/vas.h
> b/arch/powerpc/platforms/powernv/vas.h
> index 70f793e8f6cc..c7db3190baca 100644
> --- a/arch/powerpc/platforms/powernv/vas.h
> +++ b/arch/powerpc/platforms/powernv/vas.h
> @@ -340,6 +340,7 @@ struct vas_instance {
> struct vas_window *rxwin[VAS_COP_TYPE_MAX];
> struct vas_window *windows[VAS_WINDOWS_PER_CHIP];
>
> + char *name;
> char *dbgname;
> struct dentry *dbgdir;
> };
> diff --git a/arch/powerpc/platforms/powernv/vas.c
> b/arch/powerpc/platforms/powernv/vas.c
> index 598e4cd563fb..b65256a63e87 100644
> --- a/arch/powerpc/platforms/powernv/vas.c
> +++ b/arch/powerpc/platforms/powernv/vas.c
> @@ -28,12 +28,10 @@ static DEFINE_PER_CPU(int, cpu_vas_id);
>
> static int vas_irq_fault_window_setup(struct vas_instance *vinst)
> {
> - char devname[64];
> int rc = 0;
>
> - snprintf(devname, sizeof(devname), "vas-%d", vinst->vas_id);
> rc = request_threaded_irq(vinst->virq, vas_fault_handler,
> - vas_fault_thread_fn, 0, devname,
> vinst);
> + vas_fault_thread_fn, 0, vinst->name,
> vinst);
>
> if (rc) {
> pr_err("VAS[%d]: Request IRQ(%d) failed with %d\n",
> @@ -80,6 +78,12 @@ static int init_vas_instance(struct
> platform_device *pdev)
> if (!vinst)
> return -ENOMEM;
>
> + vinst->name = kasprintf(GFP_KERNEL, "vas-%d", vasid);
> + if (!vinst->name) {
> + kfree(vinst);
> + return -ENOMEM;
> + }
> +
> INIT_LIST_HEAD(>node);
> ida_init(>ida);
> mutex_init(>mutex);
> @@ -162,6 +166,7 @@ static int init_vas_instance(struct
> platform_device *pdev)
> return 0;
>
> free_vinst:
> + kfree(vinst->name);
> kfree(vinst);
> return -ENODEV;
>
Re: [PATCH] powerpc/vas: Fix IRQ name allocation
On 12/15/20 11:56 AM, Haren Myneni wrote:
> On Sat, 2020-12-12 at 15:27 +0100, Cédric Le Goater wrote:
>> The VAS device allocates a generic interrupt to handle page faults
>> but
>> the IRQ name doesn't show under /proc. This is because it's on
>> stack. Allocate the name.
>>
>> Signed-off-by: Cédric Le Goater
>
> Thanks for fixing.
I was wondering where those ^B interrupt numbers were coming from.
/proc/interrupts looks better now:
36: ... 0 XIVE-IRQ 50331732 Edge vas-6
40: ... 0 XIVE-IRQ 33554504 Edge vas-4
72: ... 0 XIVE-IRQ 16777304 Edge vas-2
124: ... 0 XIVE-IRQ 124 Edge vas-0
>
> Acked-by: Haren Myneni
>
>> ---
>>
>> I didn't understand this part in init_vas_instance() :
>>
>> if (vinst->virq) {
>> rc = vas_irq_fault_window_setup(vinst);
>> /*
>> * Fault window is used only for user space send
>> windows.
>> * So if vinst->virq is NULL, tx_win_open returns
>> -ENODEV
>> * for user space.
>> */
>> if (rc)
>> vinst->virq = 0;
>> }
>>
>> If the IRQ cannot be requested, the device probing should fail but
>> it's not today. The use of 'vinst->virq' is suspicious.
>
> VAS raises an interrupt only when NX sees fault on request buffers and
> faults can happen only for user space requests. So Fault window setup
> is needed for user space requests. For kernel requests, continue even
> if IRQ / fault_window_setup is failed.
>
> When window open request is issued from user space, kernel returns
> -ENODEV if vinst->virq = 0 (means fault window setup is failed).
It looks ok to deactivate a feature (page faulting for user space
requests) if vas_setup_fault_window() fails but if the IRQ layer
routine request_threaded_irq() fails, something is really wrong
in the system and we should stop probing IMO.
We should probably move the IRQ request after allocating/mapping
the XIVE IPI IRQ.
this test is always true :
if (vinst->virq) {
rc = vas_irq_fault_window_setup(vinst);
since above, we did :
vinst->virq = irq_create_mapping(NULL, hwirq);
if (!vinst->virq) {
pr_err("Inst%d: Unable to map global irq %d\n",
vinst->vas_id, hwirq);
return -EINVAL;
}
Cheers,
C.
>
>
>>
>> arch/powerpc/platforms/powernv/vas.h | 1 +
>> arch/powerpc/platforms/powernv/vas.c | 11 ---
>> 2 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/vas.h
>> b/arch/powerpc/platforms/powernv/vas.h
>> index 70f793e8f6cc..c7db3190baca 100644
>> --- a/arch/powerpc/platforms/powernv/vas.h
>> +++ b/arch/powerpc/platforms/powernv/vas.h
>> @@ -340,6 +340,7 @@ struct vas_instance {
>> struct vas_window *rxwin[VAS_COP_TYPE_MAX];
>> struct vas_window *windows[VAS_WINDOWS_PER_CHIP];
>>
>> +char *name;
>> char *dbgname;
>> struct dentry *dbgdir;
>> };
>> diff --git a/arch/powerpc/platforms/powernv/vas.c
>> b/arch/powerpc/platforms/powernv/vas.c
>> index 598e4cd563fb..b65256a63e87 100644
>> --- a/arch/powerpc/platforms/powernv/vas.c
>> +++ b/arch/powerpc/platforms/powernv/vas.c
>> @@ -28,12 +28,10 @@ static DEFINE_PER_CPU(int, cpu_vas_id);
>>
>> static int vas_irq_fault_window_setup(struct vas_instance *vinst)
>> {
>> -char devname[64];
>> int rc = 0;
>>
>> -snprintf(devname, sizeof(devname), "vas-%d", vinst->vas_id);
>> rc = request_threaded_irq(vinst->virq, vas_fault_handler,
>> -vas_fault_thread_fn, 0, devname,
>> vinst);
>> +vas_fault_thread_fn, 0, vinst->name,
>> vinst);
>>
>> if (rc) {
>> pr_err("VAS[%d]: Request IRQ(%d) failed with %d\n",
>> @@ -80,6 +78,12 @@ static int init_vas_instance(struct
>> platform_device *pdev)
>> if (!vinst)
>> return -ENOMEM;
>>
>> +vinst->name = kasprintf(GFP_KERNEL, "vas-%d", vasid);
>> +if (!vinst->name) {
>> +kfree(vinst);
>> +return -ENOMEM;
>> +}
>> +
>> INIT_LIST_HEAD(>node);
>> ida_init(>ida);
>> mutex_init(>mutex);
>> @@ -162,6 +166,7 @@ static int init_vas_instance(struct
>> platform_device *pdev)
>> return 0;
>>
>> free_vinst:
>> +kfree(vinst->name);
>> kfree(vinst);
>> return -ENODEV;
>>
>
Re: [PATCH] arch: fix 'unexpected IRQ trap at vector' warnings
On 09.12.20 00:01, Thomas Gleixner wrote:
> There are a few situations why it is invoked or not:
>
> 1) The original x86 usage is not longer using it because it complains
> rightfully about a vector being raised which has no interrupt
> descriptor associated to it. So the original reason for naming it
> vector is gone long ago. It emits:
>
> pr_emerg_ratelimited("%s: %d.%u No irq handler for vector\n",
> __func__, smp_processor_id(), vector);
>
> Directly from the x86 C entry point without ever invoking that
> function. Pretty popular error message due to some AMD BIOS
> wreckage. :)
Of course, the term "vector" should be replaced by something like
"irqnr" or "virq", but I didn't have name changes within scope - just
wanted to fix the printing of that number, as i've stupled over it while
working on something different and wondered why the number differed from
what I had expected, until I seen that it prints hex instead of decimal.
But if you prefer a more complete cleanup, I'll be happy to do it.
> 3) It's invoked from __handle_domain_irq() when the 'hwirq' which is
> handed in by the caller does not resolve to a mapped Linux
> interrupt which is pretty much the same as the x86 situation above
> in #1, but it prints useless data.
>
> It prints 'irq' which is invalid but it does not print the really
> interesting 'hwirq' which was handed in by the caller and did
> not resolve.
I wouldn't say the irq-nr isn't interesting. In my particular case it
was quite what I've been looking for. But you're right, hwirq should
also be printed.
> In this case the Linux irq number is uninteresting as it is known
> to be invalid and simply is not mapped and therefore does not
> exist.
In my case it came in from generic_handle_irq(), and in this case this
irq number (IMHO) has been valid, but nobody handled it, so it went to
ack_bad_irq.
Of course, if this function is meant as a fallback to ack some not
otherwise handled IRQ on the hw, the linux irq number indeed isn't quite
helpful (unless we expect that code to do a lookup to the hw irq).
... rethinking this further ... shouldn't we also pass in even more data
(eg. irq_desc, irqchip, ...), so this function can check which hw to
actually talk to ?
> 4) It's invoked from the dummy irq chip which is installed for a
> couple of truly virtual interrupts where the invocation of
> dummy_irq_chip::irq_ack() is indicating wreckage.
>
> In that case the Linux irq number is the thing which is printed.
>
> So no. It's not just inconsistent it's in some places outright
> wrong. What we really want is:
>
> ack_bad_irq(int hwirq, int virq)
is 'int' correct here ?
BTW: I also wonder why the virq is unsigned int, while hwirq (eg. in
struct irq_data) is unsigned long. shouldn't the virtual number space
be at least as big (or even bigger) than the hw one ?
{
> if (hwirq >= 0)
>print_useful_info(hwirq);
> if (virq > 0)
>print_useful_info(virq);
> arch_try_to_ack(hwirq, virq);
> }
>
> for this to make sense. Just fixing the existing printk() to be less
> wrong is not really an improvement.
Okay, makes sense.
OTOH: since both callers (dummychip.c, handle.c) already dump out before
ack_bad_irq(), do we need to print out anything at all ?
I've also seen that many archs increase a counter (some use long, others
atomic_t) - should we also consolidate this in an arch-independent way
in handle.c (or does kstat_incr_irqs_this_cpu already do this) ?
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
Re: [RFC PATCH] treewide: remove bzip2 compression support
Hello, On Tue, Dec 15, 2020 at 02:03:15PM -0500, Alex Xu (Hello71) wrote: > bzip2 is either slower or larger than every other supported algorithm, > according to benchmarks at [0]. It is far slower to decompress than any > other algorithm, and still larger than lzma, xz, and zstd. > > [0] https://lore.kernel.org/lkml/1588791882.08g1378g67.none@localhost/ Sounds cool. I wonder how many people will complain that their distribution migrated to bzip2 but got stuck there and now new kernels won't work on there with some odd tool or another :p > @@ -212,11 +209,6 @@ choice > Compression speed is only relevant when building a kernel. > Decompression speed is relevant at each boot. > > - If you have any problems with bzip2 or lzma compressed > - kernels, mail me (Alain Knaff) . (An older > - version of this functionality (bzip2 only), for 2.4, was > - supplied by Christian Ludwig) > - Shouldn't the LZMA part be preserved here? Thanks Michal
[RFC PATCH] treewide: remove bzip2 compression support
bzip2 is either slower or larger than every other supported algorithm,
according to benchmarks at [0]. It is far slower to decompress than any
other algorithm, and still larger than lzma, xz, and zstd.
[0] https://lore.kernel.org/lkml/1588791882.08g1378g67.none@localhost/
Signed-off-by: Alex Xu (Hello71)
---
Documentation/x86/boot.rst | 8 +-
arch/arm/configs/aspeed_g4_defconfig | 1 -
arch/arm/configs/aspeed_g5_defconfig | 1 -
arch/arm/configs/ezx_defconfig | 1 -
arch/arm/configs/imote2_defconfig | 1 -
arch/arm/configs/lpc18xx_defconfig | 1 -
arch/arm/configs/vf610m4_defconfig | 1 -
arch/arm64/boot/Makefile | 5 +-
arch/mips/Kconfig | 1 -
arch/mips/Makefile | 3 -
arch/mips/boot/Makefile| 14 -
arch/mips/boot/compressed/Makefile | 1 -
arch/mips/boot/compressed/decompress.c | 4 -
arch/mips/configs/ath25_defconfig | 1 -
arch/mips/configs/pistachio_defconfig | 1 -
arch/openrisc/configs/simple_smp_defconfig | 1 -
arch/parisc/Kconfig| 1 -
arch/parisc/boot/compressed/Makefile | 5 +-
arch/parisc/boot/compressed/misc.c | 4 -
arch/powerpc/configs/skiroot_defconfig | 1 -
arch/riscv/boot/Makefile | 3 -
arch/riscv/configs/nommu_k210_defconfig| 1 -
arch/riscv/configs/nommu_virt_defconfig| 1 -
arch/s390/Kconfig | 1 -
arch/s390/boot/compressed/Makefile | 5 +-
arch/s390/boot/compressed/decompressor.c | 8 -
arch/sh/Kconfig| 1 -
arch/sh/Makefile | 3 +-
arch/sh/boot/Makefile | 11 +-
arch/sh/boot/compressed/Makefile | 5 +-
arch/sh/boot/compressed/misc.c | 8 -
arch/sh/configs/sdk7786_defconfig | 1 -
arch/x86/Kconfig | 1 -
arch/x86/boot/compressed/Makefile | 9 +-
arch/x86/boot/compressed/misc.c| 4 -
arch/x86/include/asm/boot.h| 4 +-
arch/xtensa/configs/cadence_csp_defconfig | 1 -
arch/xtensa/configs/nommu_kc705_defconfig | 1 -
include/linux/decompress/bunzip2.h | 11 -
init/Kconfig | 22 +-
init/do_mounts_rd.c| 1 -
kernel/configs/tiny.config | 1 -
lib/Kconfig| 3 -
lib/Makefile | 1 -
lib/decompress.c | 5 -
lib/decompress_bunzip2.c | 756 -
scripts/Makefile.lib | 8 +-
scripts/Makefile.package | 1 -
scripts/package/buildtar | 2 +-
usr/Kconfig| 26 +-
usr/Makefile | 3 +-
51 files changed, 22 insertions(+), 942 deletions(-)
delete mode 100644 include/linux/decompress/bunzip2.h
delete mode 100644 lib/decompress_bunzip2.c
diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
index abb9fc164657..741eebc10140 100644
--- a/Documentation/x86/boot.rst
+++ b/Documentation/x86/boot.rst
@@ -781,10 +781,10 @@ Protocol: 2.08+
The payload may be compressed. The format of both the compressed and
uncompressed data should be determined using the standard magic
numbers. The currently supported compression formats are gzip
- (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA
- (magic number 5D 00), XZ (magic number FD 37), LZ4 (magic number
- 02 21) and ZSTD (magic number 28 B5). The uncompressed payload is
- currently always ELF (magic number 7F 45 4C 46).
+ (magic numbers 1F 8B or 1F 9E), LZMA (magic number 5D 00), XZ (magic
+ number FD 37), LZ4 (magic number 02 21) and ZSTD (magic number 28 B5).
+ Formerly supported was bzip2 (magic number 42 5A). The uncompressed
+ payload is currently always ELF (magic number 7F 45 4C 46).
==
Field name:payload_length
diff --git a/arch/arm/configs/aspeed_g4_defconfig
b/arch/arm/configs/aspeed_g4_defconfig
index 58d293b63581..f2f5dcd0e59c 100644
--- a/arch/arm/configs/aspeed_g4_defconfig
+++ b/arch/arm/configs/aspeed_g4_defconfig
@@ -8,7 +8,6 @@ CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_CGROUPS=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
# CONFIG_UID16 is not set
diff --git a/arch/arm/configs/aspeed_g5_defconfig
b/arch/arm/configs/aspeed_g5_defconfig
index 047975eccefb..5d045b2902d6 100644
--- a/arch/arm/configs/aspeed_g5_defconfig
+++ b/arch/arm/configs/aspeed_g5_defconfig
@@ -8,7 +8,6 @@ CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_CGROUPS=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZO is not set
#
Re: [PATCH] arch: fix 'unexpected IRQ trap at vector' warnings
On Tue, Dec 15 2020 at 21:12, Enrico Weigelt wrote:
> On 09.12.20 00:01, Thomas Gleixner wrote:
>> 3) It's invoked from __handle_domain_irq() when the 'hwirq' which is
>> handed in by the caller does not resolve to a mapped Linux
>> interrupt which is pretty much the same as the x86 situation above
>> in #1, but it prints useless data.
>>
>> It prints 'irq' which is invalid but it does not print the really
>> interesting 'hwirq' which was handed in by the caller and did
>> not resolve.
>
> I wouldn't say the irq-nr isn't interesting. In my particular case it
> was quite what I've been looking for. But you're right, hwirq should
> also be printed.
The number is _not_ interesting in this case. It's useless because the
function does:
irq = hwirq;
if (lookup)
irq = find_mapping(hwirq);
if (!irq || irq >= nr_irqs)
-> BAD
So irq is completely useless because find_mapping() returns 0 if there
is no mapping and if irq >= nr_irqs then there was no lookup and the
hwirq number is bogus.
In both cases the only interesting information is that hwirq does not
resolve to a valid Linux interrupt number and which hwirq number caused
that.
>> In this case the Linux irq number is uninteresting as it is known
>> to be invalid and simply is not mapped and therefore does not
>> exist.
>
> In my case it came in from generic_handle_irq(), and in this case this
> irq number (IMHO) has been valid, but nobody handled it, so it went to
> ack_bad_irq.
generic_handle_irq() _is_ a different function which is only invoked
when there is a valid Linux interrupt number and then the ack_bad_irq()
is invoked from a different place. See below.
> Of course, if this function is meant as a fallback to ack some not
> otherwise handled IRQ on the hw, the linux irq number indeed isn't quite
> helpful (unless we expect that code to do a lookup to the hw irq).
If there is no valid linux irq number then there is no lookup. And you
can't look it up from the hardware either.
If you look really then you find out that there is exactly _ONE_
architecture which does anything else than incrementing a counter and/or
printing stuff: X86, which has a big fat comment explaining why. The
only way to ack an interrupt on X86 is to issue EOI on the local APIC,
i.e. it does _not_ need any further information.
> ... rethinking this further ... shouldn't we also pass in even more data
> (eg. irq_desc, irqchip, ...), so this function can check which hw to
> actually talk to ?
There are 3 ways to get there:
1) via dummy chip which obviously has no hardware associated
2) via handle_bad_irq() which prints the info already
3) __handle_domain_irq() which cannot print anything and obviously
cannot figure out the hw to talk to because there is no irq
descriptor associated.
>> 4) It's invoked from the dummy irq chip which is installed for a
>> couple of truly virtual interrupts where the invocation of
>> dummy_irq_chip::irq_ack() is indicating wreckage.
>>
>> In that case the Linux irq number is the thing which is printed.
>>
>> So no. It's not just inconsistent it's in some places outright
>> wrong. What we really want is:
>>
>> ack_bad_irq(int hwirq, int virq)
>
> is 'int' correct here ?
This was just for illustration.
> BTW: I also wonder why the virq is unsigned int, while hwirq (eg. in
> struct irq_data) is unsigned long. shouldn't the virtual number space
> be at least as big (or even bigger) than the hw one ?
Only if there are no irqdomain mappings and the virq space is 1:1 mapped
to the hwirq space. Systems with > 4G interrupts are pretty unlikely.
Also hwirq can be completely artificial and encode information about
interrupts which are composed, i.e. PCI/MSI. See pci_msi_domain_calc_hwirq().
> {
>> if (hwirq >= 0)
>>print_useful_info(hwirq);
>> if (virq > 0)
>>print_useful_info(virq);
>> arch_try_to_ack(hwirq, virq);
>> }
>>
>> for this to make sense. Just fixing the existing printk() to be less
>> wrong is not really an improvement.
>
> Okay, makes sense.
>
> OTOH: since both callers (dummychip.c, handle.c) already dump out before
> ack_bad_irq(), do we need to print out anything at all ?
Not all callers print something, but yes this could do with some general
cleanup.
> I've also seen that many archs increase a counter (some use long, others
> atomic_t) - should we also consolidate this in an arch-independent way
> in handle.c (or does kstat_incr_irqs_this_cpu already do this) ?
kstat_incr_irqs_this_cpu(desc) operates on the irq descriptor which
requires that an irq descriptor exists in the first place.
The error counter is independent of that, but yes there is room for
consolidation.
Thanks,
tglx
Re: [PATCH] powerpc/boot: Fix build of dts/fsl
On Tue, Dec 15, 2020 at 12:29 PM Michael Ellerman wrote:
>
> The lkp robot reported that some configs fail to build, for example
> mpc85xx_smp_defconfig, with:
>
> cc1: fatal error: opening output file
> arch/powerpc/boot/dts/fsl/.mpc8540ads.dtb.dts.tmp: No such file or directory
>
> This bisects to:
> cc8a51ca6f05 ("kbuild: always create directories of targets")
>
> Although that commit claims to be about in-tree builds, it somehow
> breaks out-of-tree builds. But presumably it's just exposing a latent
> bug in our Makefiles.
>
> We can fix it by adding to targets for dts/fsl in the same way that we
> do for dts.
>
> Fixes: cc8a51ca6f05 ("kbuild: always create directories of targets")
> Reported-by: kernel test robot
> Signed-off-by: Michael Ellerman
> ---
> arch/powerpc/boot/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index 68a7534454cd..c3e084cceaed 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -372,6 +372,8 @@ initrd-y := $(filter-out $(image-y), $(initrd-y))
> targets+= $(image-y) $(initrd-y)
> targets += $(foreach x, dtbImage uImage cuImage simpleImage treeImage, \
> $(patsubst $(x).%, dts/%.dtb, $(filter $(x).%, $(image-y
> +targets += $(foreach x, dtbImage uImage cuImage simpleImage treeImage, \
> + $(patsubst $(x).%, dts/fsl/%.dtb, $(filter $(x).%,
> $(image-y
>
> $(addprefix $(obj)/, $(initrd-y)): $(obj)/ramdisk.image.gz
>
> --
> 2.25.1
>
Some freescale dts files are right under arch/powerpc/boot/dts/,
but some are in the fsl/ subdirectory.
I do not understand the policy.
If "fsl/" is a very special case,
I just thought we could add a new syntax, fslimage-y,
but I do not mind either way.
fslimage-$(CONFIG_MPC8540_ADS) += cuImage.mpc8540ads
targets += $(foreach x, dtbImage uImage cuImage simpleImage treeImage, \
$(patsubst $(x).%, dts/fsl/%.dtb, $(filter $(x).%,
$(fslimage-y
This Makefile is wrong over-all anyway.
--
Best Regards
Masahiro Yamada
Re: [PATCH 1/2] powerpc/64s: remplement power4_idle code in C
On Thu, 11 Jul 2019 12:24:03 +1000, Nicholas Piggin wrote: > This implements the tricky tracing and soft irq handling bits in C, > leaving the low level bit to asm. > > A functional difference is that this redirects the interrupt exit to > a return stub to execute blr, rather than the lr address itself. This > is probably barely measurable on real hardware, but it keeps the link > stack balanced. > > [...] Patch 2 applied to powerpc/next. [2/2] powerpc/64s: Remove idle workaround code from restore_cpu_cpufeatures https://git.kernel.org/powerpc/c/02b02ee1b05ef225525835b2d45faf31b3420bdd cheers
Re: [PATCH] powerpc/64s: Remove MSR[ISF] bit
On Fri, 6 Nov 2020 14:53:40 +1000, Nicholas Piggin wrote: > No supported processor implements this mode. Setting the bit in > MSR values can be a bit confusing (and would prevent the bit from > ever being reused). Remove it. Applied to powerpc/next. [1/1] powerpc/64s: Remove MSR[ISF] bit https://git.kernel.org/powerpc/c/e89a8ca94bf583f2577fe722483f0304b3390aa2 cheers
Re: [PATCH v2] powerpc/64: irq replay remove decrementer overflow check
On Sat, 7 Nov 2020 11:43:36 +1000, Nicholas Piggin wrote: > This is way to catch some cases of decrementer overflow, when the > decrementer has underflowed an odd number of times, while MSR[EE] was > disabled. > > With a typical small decrementer, a timer that fires when MSR[EE] is > disabled will be "lost" if MSR[EE] remains disabled for between 4.3 and > 8.6 seconds after the timer expires. In any case, the decrementer > interrupt would be taken at 8.6 seconds and the timer would be found at > that point. > > [...] Applied to powerpc/next. [1/1] powerpc/64: irq replay remove decrementer overflow check https://git.kernel.org/powerpc/c/59d512e4374b2d8a6ad341475dc94c4a4bdec7d3 cheers
Re: [PATCH v3] powerpc/watchpoint: Workaround P10 DD1 issue with VSX-32 byte instructions
On Fri, 6 Nov 2020 10:26:50 +0530, Ravi Bangoria wrote: > POWER10 DD1 has an issue where it generates watchpoint exceptions when > it shouldn't. The conditions where this occur are: > > - octword op > - ending address of DAWR range is less than starting address of op > - those addresses need to be in the same or in two consecutive 512B >blocks > - 'op address + 64B' generates an address that has a carry into bit >52 (crosses 2K boundary) > > [...] Applied to powerpc/next. [1/1] powerpc/watchpoint: Workaround P10 DD1 issue with VSX-32 byte instructions https://git.kernel.org/powerpc/c/3d2ffcdd2a982e8bbe65fa0f94fb21bf304c281e cheers
Re: [PATCH v5 0/5] powerpc/sstep: VSX 32-byte vector paired load/store instructions
On Sun, 11 Oct 2020 10:39:03 +0530, Ravi Bangoria wrote: > VSX vector paired instructions operates with octword (32-byte) > operand for loads and stores between storage and a pair of two > sequential Vector-Scalar Registers (VSRs). There are 4 word > instructions and 2 prefixed instructions that provides this > 32-byte storage access operations - lxvp, lxvpx, stxvp, stxvpx, > plxvp, pstxvp. > > [...] Applied to powerpc/next. [1/5] powerpc/sstep: Emulate prefixed instructions only when CPU_FTR_ARCH_31 is set https://git.kernel.org/powerpc/c/ef6879f8c8053cc3b493f400a06d452d7fb13650 [2/5] powerpc/sstep: Cover new VSX instructions under CONFIG_VSX https://git.kernel.org/powerpc/c/1817de2f141c718f1a0ae59927ec003e9b144349 [3/5] powerpc/sstep: Support VSX vector paired storage access instructions https://git.kernel.org/powerpc/c/af99da74333b06d97ea6a9a2cd8906244da4bb26 [4/5] powerpc/ppc-opcode: Add encoding macros for VSX vector paired instructions https://git.kernel.org/powerpc/c/6ce73ba7691555fd182bc68529dc03cbd4378f72 [5/5] powerpc/sstep: Add testcases for VSX vector paired load/store instructions https://git.kernel.org/powerpc/c/35785b293da0070a8df19b0193f0e7de6c9eaecb cheers
Re: [PATCH] powerpc/rtas: fix typo of ibm, open-errinjct in rtas filter
On Tue, 8 Dec 2020 13:54:34 -0600, Tyrel Datwyler wrote:
> Commit bd59380c5ba4 ("powerpc/rtas: Restrict RTAS requests from userspace")
> introduced the following error when invoking the errinjct userspace
> tool.
>
> [root@ltcalpine2-lp5 librtas]# errinjct open
> [327884.071171] sys_rtas: RTAS call blocked - exploit attempt?
> [327884.071186] sys_rtas: token=0x26, nargs=0 (called by errinjct)
> errinjct: Could not open RTAS error injection facility
> errinjct: librtas: open: Unexpected I/O error
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/rtas: Fix typo of ibm,open-errinjct in RTAS filter
https://git.kernel.org/powerpc/c/f10881a46f8914428110d110140a455c66bdf27b
cheers
[powerpc:merge] BUILD SUCCESS a1d4aa500bfb93c4ea6eb9a3c5c9cb6720ed8f46
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: a1d4aa500bfb93c4ea6eb9a3c5c9cb6720ed8f46 Automatic merge of 'next' into merge (2020-12-15 23:50) elapsed time: 727m configs tested: 134 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arc nsimosci_hs_smp_defconfig riscvallyesconfig mips bmips_stb_defconfig armrealview_defconfig mips decstation_defconfig arm64alldefconfig powerpc holly_defconfig powerpc mpc837x_mds_defconfig armshmobile_defconfig shecovec24-romimage_defconfig arm pxa255-idp_defconfig h8300 h8s-sim_defconfig powerpc powernv_defconfig arm assabet_defconfig ia64 gensparse_defconfig openrisc simple_smp_defconfig powerpc mpc836x_mds_defconfig armvt8500_v6_v7_defconfig riscvnommu_k210_defconfig mipsar7_defconfig powerpc ppc64_defconfig arm ep93xx_defconfig powerpcwarp_defconfig nios2 10m50_defconfig mips bmips_be_defconfig xtensaxip_kc705_defconfig sh se7724_defconfig armlart_defconfig um i386_defconfig ia64 bigsur_defconfig powerpc mpc85xx_cds_defconfig armclps711x_defconfig powerpc ep8248e_defconfig arm netwinder_defconfig arm h5000_defconfig powerpc kmeter1_defconfig arm integrator_defconfig powerpc pq2fads_defconfig powerpc tqm5200_defconfig shsh7763rdp_defconfig arm collie_defconfig arm jornada720_defconfig arm davinci_all_defconfig powerpc linkstation_defconfig m68kmac_defconfig powerpc64alldefconfig arm sunxi_defconfig armzeus_defconfig mips tb0287_defconfig powerpc sequoia_defconfig mips decstation_64_defconfig arm omap2plus_defconfig powerpc mpc834x_itx_defconfig xtensa iss_defconfig sh sh2007_defconfig shdreamcast_defconfig arm corgi_defconfig parisc alldefconfig mips pic32mzda_defconfig mips xway_defconfig arm mv78xx0_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a003-20201215 x86_64
Re: [PATCH] powerpc/boot: Fix build of dts/fsl
Masahiro Yamada writes:
> On Tue, Dec 15, 2020 at 12:29 PM Michael Ellerman wrote:
>>
>> The lkp robot reported that some configs fail to build, for example
>> mpc85xx_smp_defconfig, with:
>>
>> cc1: fatal error: opening output file
>> arch/powerpc/boot/dts/fsl/.mpc8540ads.dtb.dts.tmp: No such file or directory
>>
>> This bisects to:
>> cc8a51ca6f05 ("kbuild: always create directories of targets")
>>
>> Although that commit claims to be about in-tree builds, it somehow
>> breaks out-of-tree builds. But presumably it's just exposing a latent
>> bug in our Makefiles.
>>
>> We can fix it by adding to targets for dts/fsl in the same way that we
>> do for dts.
>>
>> Fixes: cc8a51ca6f05 ("kbuild: always create directories of targets")
>> Reported-by: kernel test robot
>> Signed-off-by: Michael Ellerman
>> ---
>> arch/powerpc/boot/Makefile | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
>> index 68a7534454cd..c3e084cceaed 100644
>> --- a/arch/powerpc/boot/Makefile
>> +++ b/arch/powerpc/boot/Makefile
>> @@ -372,6 +372,8 @@ initrd-y := $(filter-out $(image-y), $(initrd-y))
>> targets+= $(image-y) $(initrd-y)
>> targets += $(foreach x, dtbImage uImage cuImage simpleImage treeImage, \
>> $(patsubst $(x).%, dts/%.dtb, $(filter $(x).%, $(image-y
>> +targets += $(foreach x, dtbImage uImage cuImage simpleImage treeImage, \
>> + $(patsubst $(x).%, dts/fsl/%.dtb, $(filter $(x).%,
>> $(image-y
>>
>> $(addprefix $(obj)/, $(initrd-y)): $(obj)/ramdisk.image.gz
>>
>
>
> Some freescale dts files are right under arch/powerpc/boot/dts/,
> but some are in the fsl/ subdirectory.
> I do not understand the policy.
There isn't a policy. Best I can tell Kumar felt like it would be
cleaner to have a separate directory for (some of) the Freescale DTS
files, when he initially submitted them ~9 years ago.
> If "fsl/" is a very special case,
> I just thought we could add a new syntax, fslimage-y,
> but I do not mind either way.
OK. If you don't mind I'll merge my patch as a quick fix for now.
Then we can probably move all the fsl/ files up one level and avoid the
problem entirely in future.
> fslimage-$(CONFIG_MPC8540_ADS) += cuImage.mpc8540ads
>
> targets += $(foreach x, dtbImage uImage cuImage simpleImage treeImage, \
>$(patsubst $(x).%, dts/fsl/%.dtb, $(filter $(x).%,
> $(fslimage-y
>
>
> This Makefile is wrong over-all anyway.
Excellent.
cheers
Re: [RFC PATCH] treewide: remove bzip2 compression support
Excerpts from Alex Xu (Hello71)'s message of December 15, 2020 2:03 pm: > bzip2 is either slower or larger than every other supported algorithm, > according to benchmarks at [0]. It is far slower to decompress than any > other algorithm, and still larger than lzma, xz, and zstd. > > [0] https://lore.kernel.org/lkml/1588791882.08g1378g67.none@localhost/ > > Signed-off-by: Alex Xu (Hello71) Upon further research, I found that bzip2 removal was already implemented as part of zstd addition, but were apparently abandoned in an effort to get zstd in. I will check those patches and try sending those instead. Thanks to all reviewers for comments on this patch.
[powerpc:next] BUILD SUCCESS c15d1f9d03a0f4f68bf52dffdd541c8054e6de35
j2_defconfig pariscgeneric-32bit_defconfig mips tb0226_defconfig arm corgi_defconfig parisc alldefconfig mips pic32mzda_defconfig mips xway_defconfig arm mv78xx0_defconfig powerpc mpc832x_mds_defconfig arm u8500_defconfig powerpc tqm8560_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig sh allmodconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig i386 tinyconfig i386defconfig sparc defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig x86_64 randconfig-a003-20201215 x86_64 randconfig-a006-20201215 x86_64 randconfig-a002-20201215 x86_64 randconfig-a005-20201215 x86_64 randconfig-a004-20201215 x86_64 randconfig-a001-20201215 i386 randconfig-a001-20201215 i386 randconfig-a004-20201215 i386 randconfig-a003-20201215 i386 randconfig-a002-20201215 i386 randconfig-a006-20201215 i386 randconfig-a005-20201215 i386 randconfig-a014-20201215 i386 randconfig-a013-20201215 i386 randconfig-a012-20201215 i386 randconfig-a011-20201215 i386 randconfig-a015-20201215 i386 randconfig-a016-20201215 riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel x86_64rhel-7.6-kselftests x86_64 kexec clang tested configs: x86_64 randconfig-a016-20201215 x86_64 randconfig-a012-20201215 x86_64 randconfig-a013-20201215 x86_64 randconfig-a015-20201215 x86_64 randconfig-a014-20201215 x86_64 randconfig-a011-20201215 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v2 07/13] powerpc: Increase NR_IRQS range to support more KVM guests
Cédric Le Goater writes: > On 12/11/20 12:51 AM, Michael Ellerman wrote: >> Cédric Le Goater writes: >>> PowerNV systems can handle up to 4K guests and 1M interrupt numbers >>> per chip. Increase the range of allowed interrupts to support a larger >>> number of guests. >>> >>> Reviewed-by: Greg Kurz >>> Signed-off-by: Cédric Le Goater >>> --- >>> arch/powerpc/Kconfig | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig >>> index 5181872f9452..c250fbd430d1 100644 >>> --- a/arch/powerpc/Kconfig >>> +++ b/arch/powerpc/Kconfig >>> @@ -66,7 +66,7 @@ config NEED_PER_CPU_PAGE_FIRST_CHUNK >>> >>> config NR_IRQS >>> int "Number of virtual interrupt numbers" >>> - range 32 32768 >>> + range 32 1048576 >>> default "512" >>> help >>> This defines the number of virtual interrupt numbers the kernel >> >> We should really do what other arches do, and size this appropriately >> based on the config, rather than asking users to guess what size they >> need. >> >> But I guess I'll take this for now, and we can do something fancier >> later. > > I was thinking on adding a property to OPAL to size the HW interrupt > number space. Is that it ? That's a separate issue. NR_IRQS is about the maximum number of Linux interrupts, and it's a compile time limit. In the old days there was an array of irq_desc[NR_IRQS] in .data, so you didn't want NR_IRQS to be too big. These days we don't do that, because of the sparse IRQ support, but I don't know if it's completely free to make NR_IRQS arbitrarily large at build time. > That would be good because it's increasing from 20bits on P9 to 24bits > on P10. That's probably still helpful, it might mean we can shrink some structures at runtime. > I am checking other arches. Thanks. cheers
Re: [PATCH] powerpc/boot: Fix build of dts/fsl
On Wed, Dec 16, 2020 at 11:41 AM Michael Ellerman wrote:
>
> Masahiro Yamada writes:
> > On Tue, Dec 15, 2020 at 12:29 PM Michael Ellerman
> > wrote:
> >>
> >> The lkp robot reported that some configs fail to build, for example
> >> mpc85xx_smp_defconfig, with:
> >>
> >> cc1: fatal error: opening output file
> >> arch/powerpc/boot/dts/fsl/.mpc8540ads.dtb.dts.tmp: No such file or
> >> directory
> >>
> >> This bisects to:
> >> cc8a51ca6f05 ("kbuild: always create directories of targets")
> >>
> >> Although that commit claims to be about in-tree builds, it somehow
> >> breaks out-of-tree builds. But presumably it's just exposing a latent
> >> bug in our Makefiles.
> >>
> >> We can fix it by adding to targets for dts/fsl in the same way that we
> >> do for dts.
> >>
> >> Fixes: cc8a51ca6f05 ("kbuild: always create directories of targets")
> >> Reported-by: kernel test robot
> >> Signed-off-by: Michael Ellerman
> >> ---
> >> arch/powerpc/boot/Makefile | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> >> index 68a7534454cd..c3e084cceaed 100644
> >> --- a/arch/powerpc/boot/Makefile
> >> +++ b/arch/powerpc/boot/Makefile
> >> @@ -372,6 +372,8 @@ initrd-y := $(filter-out $(image-y), $(initrd-y))
> >> targets+= $(image-y) $(initrd-y)
> >> targets += $(foreach x, dtbImage uImage cuImage simpleImage treeImage, \
> >> $(patsubst $(x).%, dts/%.dtb, $(filter $(x).%,
> >> $(image-y
> >> +targets += $(foreach x, dtbImage uImage cuImage simpleImage treeImage, \
> >> + $(patsubst $(x).%, dts/fsl/%.dtb, $(filter $(x).%,
> >> $(image-y
> >>
> >> $(addprefix $(obj)/, $(initrd-y)): $(obj)/ramdisk.image.gz
> >>
> >
> >
> > Some freescale dts files are right under arch/powerpc/boot/dts/,
> > but some are in the fsl/ subdirectory.
> > I do not understand the policy.
>
> There isn't a policy. Best I can tell Kumar felt like it would be
> cleaner to have a separate directory for (some of) the Freescale DTS
> files, when he initially submitted them ~9 years ago.
>
>
> > If "fsl/" is a very special case,
> > I just thought we could add a new syntax, fslimage-y,
> > but I do not mind either way.
>
> OK. If you don't mind I'll merge my patch as a quick fix for now.
>
> Then we can probably move all the fsl/ files up one level and avoid the
> problem entirely in future.
Yes. I think it is OK.
As for PPC, most of the DT files are freescale.
Even if you separated DT files in vendor directories,
the majority would go into fsl/.
> > fslimage-$(CONFIG_MPC8540_ADS) += cuImage.mpc8540ads
> >
> > targets += $(foreach x, dtbImage uImage cuImage simpleImage treeImage, \
> >$(patsubst $(x).%, dts/fsl/%.dtb, $(filter $(x).%,
> > $(fslimage-y
> >
> >
> > This Makefile is wrong over-all anyway.
>
> Excellent.
You can pass V=2 to see why targets under arch/powerpc/boot/
are needlessly rebuilt.
This Makefile is already too cluttered, and I do not have
much time to look into it.
--
Best Regards
Masahiro Yamada
Re: [PATCH v3 2/5] powerpc/smp: Rename cpu_l1_cache_map as thread_group_l1_cache_map
* Gautham R. Shenoy [2020-12-10 16:08:56]: > From: "Gautham R. Shenoy" > > On platforms which have the "ibm,thread-groups" property, the per-cpu > variable cpu_l1_cache_map keeps a track of which group of threads > within the same core share the L1 cache, Instruction and Data flow. > > This patch renames the variable to "thread_group_l1_cache_map" to make > it consistent with a subsequent patch which will introduce > thread_group_l2_cache_map. > > This patch introduces no functional change. > Looks good to me. Reviewed-by: Srikar Dronamraju > Signed-off-by: Gautham R. Shenoy -- Thanks and Regards Srikar Dronamraju
Re: [PATCH v3 3/5] powerpc/smp: Rename init_thread_group_l1_cache_map() to make it generic
* Gautham R. Shenoy [2020-12-10 16:08:57]: > From: "Gautham R. Shenoy" > > init_thread_group_l1_cache_map() initializes the per-cpu cpumask > thread_group_l1_cache_map with the core-siblings which share L1 cache > with the CPU. Make this function generic to the cache-property (L1 or > L2) and update a suitable mask. This is a preparatory patch for the > next patch where we will introduce discovery of thread-groups that > share L2-cache. > > No functional change. > Looks good to me. Reviewed-by: Srikar Dronamraju > Signed-off-by: Gautham R. Shenoy -- Thanks and Regards Srikar Dronamraju
Re: [PATCH v3 1/5] powerpc/smp: Parse ibm,thread-groups with multiple properties
* Gautham R. Shenoy [2020-12-10 16:08:55]: > From: "Gautham R. Shenoy" > > The "ibm,thread-groups" device-tree property is an array that is used > to indicate if groups of threads within a core share certain > properties. It provides details of which property is being shared by > which groups of threads. This array can encode information about > multiple properties being shared by different thread-groups within the > core. > Looks good to me. Reviewed-by: Srikar Dronamraju -- Thanks and Regards Srikar Dronamraju
[PATCH V3] powerpc/perf: Fix Threshold Event Counter Multiplier width for P10
From: Madhavan Srinivasan
Threshold Event Counter Multiplier (TECM) is part of Monitor Mode
Control Register A (MMCRA). This field along with Threshold Event
Counter Exponent (TECE) is used to get threshould counter value.
In Power10, this is a 8bit field, so patch fixes the
current code to modify the MMCRA[TECM] extraction macro to
handle this change. ISA v3.1 says this is a 7 bit field but
POWER10 it's actually 8 bits which will hopefully be fixed
in ISA v3.1 update.
Fixes: 170a315f41c64 ('powerpc/perf: Support to export MMCRA[TEC*] field to
userspace')
Signed-off-by: Madhavan Srinivasan
Signed-off-by: Athira Rajeev
---
Changelog v2 -> v3:
- Since in POWER10 it's actually 8 bits which will hopefully be
fixed in ISA3.1 update, bring back the cpu feature check which
is the appropriate one.
Changelog v1 -> v2:
- Fixed the commit message
- Fixed the condition check to use PVR check for power10
instead of ISA v3.1 cpu feature check.
arch/powerpc/perf/isa207-common.c | 3 +++
arch/powerpc/perf/isa207-common.h | 4
2 files changed, 7 insertions(+)
diff --git a/arch/powerpc/perf/isa207-common.c
b/arch/powerpc/perf/isa207-common.c
index 24f0a90..6ab5b27 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -247,6 +247,9 @@ void isa207_get_mem_weight(u64 *weight)
u64 sier = mfspr(SPRN_SIER);
u64 val = (sier & ISA207_SIER_TYPE_MASK) >> ISA207_SIER_TYPE_SHIFT;
+ if (cpu_has_feature(CPU_FTR_ARCH_31))
+ mantissa = P10_MMCRA_THR_CTR_MANT(mmcra);
+
if (val == 0 || val == 7)
*weight = 0;
else
diff --git a/arch/powerpc/perf/isa207-common.h
b/arch/powerpc/perf/isa207-common.h
index 4208764..454b32c 100644
--- a/arch/powerpc/perf/isa207-common.h
+++ b/arch/powerpc/perf/isa207-common.h
@@ -231,6 +231,10 @@
#define MMCRA_THR_CTR_EXP(v) (((v) >> MMCRA_THR_CTR_EXP_SHIFT) &\
MMCRA_THR_CTR_EXP_MASK)
+#define P10_MMCRA_THR_CTR_MANT_MASK0xFFul
+#define P10_MMCRA_THR_CTR_MANT(v) (((v) >> MMCRA_THR_CTR_MANT_SHIFT) &\
+ P10_MMCRA_THR_CTR_MANT_MASK)
+
/* MMCRA Threshold Compare bit constant for power9 */
#define p9_MMCRA_THR_CMP_SHIFT 45
--
1.8.3.1
Re: [PATCH v3 5/5] powerpc/cacheinfo: Print correct cache-sibling map/list for L2 cache
* Gautham R. Shenoy [2020-12-10 16:08:59]: > From: "Gautham R. Shenoy" > > On POWER platforms where only some groups of threads within a core > share the L2-cache (indicated by the ibm,thread-groups device-tree > property), we currently print the incorrect shared_cpu_map/list for > L2-cache in the sysfs. > > This patch reports the correct shared_cpu_map/list on such platforms. > > Example: > On a platform with "ibm,thread-groups" set to > 0001 0002 0004 > 0002 0004 0006 0001 > 0003 0005 0007 0002 > 0002 0004 0002 > 0004 0006 0001 0003 > 0005 0007 > Looks good to me. Reviewed-by: Srikar Dronamraju -- Thanks and Regards Srikar Dronamraju
Re: [PATCH v3 4/5] powerpc/smp: Add support detecting thread-groups sharing L2 cache
* Gautham R. Shenoy [2020-12-10 16:08:58]: > From: "Gautham R. Shenoy" > > On POWER systems, groups of threads within a core sharing the L2-cache > can be indicated by the "ibm,thread-groups" property array with the > identifier "2". > > This patch adds support for detecting this, and when present, populate > the populating the cpu_l2_cache_mask of every CPU to the core-siblings > which share L2 with the CPU as specified in the by the > "ibm,thread-groups" property array. > > On a platform with the following "ibm,thread-group" configuration >0001 0002 0004 >0002 0004 0006 0001 >0003 0005 0007 0002 >0002 0004 0002 >0004 0006 0001 0003 >0005 0007 > Looks good to me. Reviewed-by: Srikar Dronamraju -- Thanks and Regards Srikar Dronamraju
Re: [PATCH v2] powerpc/book3s/kup: Mark the kuap/keup function non __init
On Mon, 14 Dec 2020 13:31:21 +0530, Aneesh Kumar K.V wrote: > The kernel call these functions on cpu online and hence they should > not be marked __init. Applied to powerpc/next. [1/1] powerpc/64s: Mark the kuap/kuep functions non __init https://git.kernel.org/powerpc/c/44b4c4450f8d31296ba633d74be753a85fd627bd cheers
Re: [PATCH V2] powerpc/perf: Exclude kernel samples while counting events in user space.
On Wed, 25 Nov 2020 02:26:55 -0500, Athira Rajeev wrote: > Perf event attritube supports exclude_kernel flag > to avoid sampling/profiling in supervisor state (kernel). > Based on this event attr flag, Monitor Mode Control Register > bit is set to freeze on supervisor state. But sometime (due > to hardware limitation), Sampled Instruction Address > Register (SIAR) locks on to kernel address even when > freeze on supervisor is set. Patch here adds a check to > drop those samples. Applied to powerpc/next. [1/1] powerpc/perf: Exclude kernel samples while counting events in user space. https://git.kernel.org/powerpc/c/aa8e21c053d72b6639ea5a7f1d3a1d0209534c94 cheers
Re: [PATCH] powerpc/32s: Handle PROTFAULT in hash_page() also for CONFIG_PPC_KUAP
On Mon, 16 Nov 2020 16:09:31 + (UTC), Christophe Leroy wrote:
> On hash 32 bits, handling minor protection faults like unsetting
> dirty flag is heavy if done from the normal page_fault processing,
> because it implies hash table software lookup for flushing the entry
> and then a DSI is taken anyway to add the entry back.
>
> When KUAP was implemented, as explained in commit a68c31fc01ef
> ("powerpc/32s: Implement Kernel Userspace Access Protection"),
> protection faults has been diverted from hash_page() because
> hash_page() was not able to identify a KUAP fault.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/32s: Handle PROTFAULT in hash_page() also for CONFIG_PPC_KUAP
https://git.kernel.org/powerpc/c/1b03e71ff6f2bd10b45a0128ce76e0e42014a44c
cheers
Re: [PATCH v2] powerpc/powermac: Fix low_sleep_handler with CONFIG_VMAP_STACK
On Tue, 8 Dec 2020 05:24:19 + (UTC), Christophe Leroy wrote: > low_sleep_handler() can't restore the context from standard > stack because the stack can hardly be accessed with MMU OFF. > > Store everything in a global storage area instead of storing > a pointer to the stack in that global storage area. > > To avoid a complete churn of the function, still use r1 as > the pointer to the storage area during restore. Applied to powerpc/next. [1/1] powerpc/powermac: Fix low_sleep_handler with CONFIG_VMAP_STACK https://git.kernel.org/powerpc/c/db972a3787d12b1ce9ba7a31ec376d8a79e04c47 cheers
Re: [PATCH v2 00/13] powerpc/xive: misc cleanups
On Thu, 10 Dec 2020 18:14:37 +0100, Cédric Le Goater wrote: > The most important change is the removal of support of OPAL flags > required for P9 DD1. It provides a good cleanup of some complex > routines. > > Thanks, > > C. > > [...] Patches 1-3 and 5-13 applied to powerpc/next. [01/13] KVM: PPC: Book3S HV: XIVE: Show detailed configuration in debug output https://git.kernel.org/powerpc/c/98983675008ab3ae9b37fc7a4bfa083998079215 [02/13] powerpc/xive: Rename XIVE_IRQ_NO_EOI to show its a flag https://git.kernel.org/powerpc/c/4f1c3f7b08187e6b97701c7fb2dc6f3749566c62 [03/13] powerpc/xive: Introduce XIVE_IPI_HW_IRQ https://git.kernel.org/powerpc/c/e2cf43d59525477cfd030378c3c808187952c531 [05/13] powerpc/xive: Add a name to the IRQ domain https://git.kernel.org/powerpc/c/9dfe4b14df93532da3dbf11952a17389ae3cdc67 [06/13] powerpc/xive: Add a debug_show handler to the XIVE irq_domain https://git.kernel.org/powerpc/c/a5021abc48a0f44083a15a37b3e61378519cb00d [07/13] powerpc: Increase NR_IRQS range to support more KVM guests https://git.kernel.org/powerpc/c/7b3b3de3b04ecb7393cdfaa30a3468dd47b750cf [08/13] powerpc/xive: Remove P9 DD1 flag XIVE_IRQ_FLAG_SHIFT_BUG https://git.kernel.org/powerpc/c/4cc0e36df2c0a41fd38645ddde08d2bfba699b7a [09/13] powerpc/xive: Remove P9 DD1 flag XIVE_IRQ_FLAG_MASK_FW https://git.kernel.org/powerpc/c/b5277d18c65e31ce51f6733ebdca3985a962fab5 [10/13] powerpc/xive: Remove P9 DD1 flag XIVE_IRQ_FLAG_EOI_FW https://git.kernel.org/powerpc/c/cf58b746665d0177b86d42d18e60985fa1fdb909 [11/13] powerpc/xive: Simplify xive_do_source_eoi() https://git.kernel.org/powerpc/c/614546d56296380b59e94484813eeef62a7d2b6b [12/13] powerpc/xive: Improve error reporting of OPAL calls https://git.kernel.org/powerpc/c/07efbca11c1a985efa4d15bd76a637c6bffc253b [13/13] KVM: PPC: Book3S HV: XIVE: Add a comment regarding VP numbering https://git.kernel.org/powerpc/c/dddc4ef92d1ce92987da1d6926cdfa99e8acb622 cheers
Re: [PATCH] powerpc: fix spelling mistake in Kconfig "seleted" -> "selected"
On Mon, 7 Dec 2020 15:54:20 +, Colin King wrote: > There is a spelling mistake in the help text of the Kconfig. Fix it. Applied to powerpc/next. [1/1] powerpc: fix spelling mistake in Kconfig "seleted" -> "selected" https://git.kernel.org/powerpc/c/f8a4b277c3cf39ec8efe50114924a7743cc84800 cheers
Re: [PATCH v2 00/28] partition suspend updates
On Mon, 7 Dec 2020 15:51:32 -0600, Nathan Lynch wrote: > This series aims to improve the pseries-specific partition migration > and hibernation implementation, part of which has been living in > kernel/rtas.c. Most of that code is eliminated or moved to > platforms/pseries, and the following major functional changes are > made: > > - Use stop_machine() instead of on_each_cpu() to avoid deadlock in the > join/suspend sequence. > > [...] Applied to powerpc/next. [01/28] powerpc/rtas: prevent suspend-related sys_rtas use on LE https://git.kernel.org/powerpc/c/de0f7349a0dd072e54b5fc04c305907b22d28a5f [02/28] powerpc/rtas: complete ibm,suspend-me status codes https://git.kernel.org/powerpc/c/970e453ea4ecdd7a16a46c229294547148d1c7b6 [03/28] powerpc/rtas: rtas_ibm_suspend_me -> rtas_ibm_suspend_me_unsafe https://git.kernel.org/powerpc/c/7049b288ea8c95f270ec8fe643e3c3187938d5af [04/28] powerpc/rtas: add rtas_ibm_suspend_me() https://git.kernel.org/powerpc/c/701ba68342412ae9be99a7c7f3badebf95271403 [05/28] powerpc/rtas: add rtas_activate_firmware() https://git.kernel.org/powerpc/c/5f485a66f4d0693a535e4ab38ffc3538716d2c2b [06/28] powerpc/hvcall: add token and codes for H_VASI_SIGNAL https://git.kernel.org/powerpc/c/9bae89f528c041f3117f0a6c21878dda5a55af60 [07/28] powerpc/pseries/mobility: don't error on absence of ibm, update-nodes https://git.kernel.org/powerpc/c/b06a6717873560e9dd1c07357781fc2b27545701 [08/28] powerpc/pseries/mobility: add missing break to default case https://git.kernel.org/powerpc/c/aa5e5c9b556a2e5f68a915e4b5dfa5c6bda47c64 [09/28] powerpc/pseries/mobility: error message improvements https://git.kernel.org/powerpc/c/2d5be6f16c4ba5c27d06704976daf55f3236a236 [10/28] powerpc/pseries/mobility: use rtas_activate_firmware() on resume https://git.kernel.org/powerpc/c/c3ae9781d5a64093f161e6cc5dfefb0773106ca9 [11/28] powerpc/pseries/mobility: extract VASI session polling logic https://git.kernel.org/powerpc/c/d9213319b84ee8393475c38361c84151d5c33415 [12/28] powerpc/pseries/mobility: use stop_machine for join/suspend https://git.kernel.org/powerpc/c/9327dc0aeef36a3cbb9d94f79b79cc4f91ff8a41 [13/28] powerpc/pseries/mobility: signal suspend cancellation to platform https://git.kernel.org/powerpc/c/37cddc7d6cf4568a7fb69aeff6f26e4c8a3bc0f7 [14/28] powerpc/pseries/mobility: retry partition suspend after error https://git.kernel.org/powerpc/c/aeca35b9a52b0e0d019a5244fbaab699f753b443 [15/28] powerpc/rtas: dispatch partition migration requests to pseries https://git.kernel.org/powerpc/c/4d756894ba75f1afe7945ccafe9afebff50484b6 [16/28] powerpc/rtas: remove rtas_ibm_suspend_me_unsafe() https://git.kernel.org/powerpc/c/5f6665e400569de479733677e77862542aebb6cc [17/28] powerpc/pseries/hibernation: drop pseries_suspend_begin() from suspend ops https://git.kernel.org/powerpc/c/52719fce3f4c7a8ac9eaa191e8d75a697f9fbcbc [18/28] powerpc/pseries/hibernation: pass stream id via function arguments https://git.kernel.org/powerpc/c/a10a5a17f4ac4f84fcc26162d43b53e2a4e1009a [19/28] powerpc/pseries/hibernation: remove pseries_suspend_cpu() https://git.kernel.org/powerpc/c/ed22bb8d39fa7f3980afc6e16d2a891847367d33 [20/28] powerpc/machdep: remove suspend_disable_cpu() https://git.kernel.org/powerpc/c/796f9247b4fa9bec320d6b47ffde2ecf86cc71c0 [21/28] powerpc/rtas: remove rtas_suspend_cpu() https://git.kernel.org/powerpc/c/395b2c090907975c627902ba8fda0bdb04c7cad3 [22/28] powerpc/pseries/hibernation: switch to rtas_ibm_suspend_me() https://git.kernel.org/powerpc/c/366fb13bf13b029c4d43bf19382f7aea69bfa4b7 [23/28] powerpc/rtas: remove unused rtas_suspend_last_cpu() https://git.kernel.org/powerpc/c/1b2488176ea56e299d2b084772daeb5ecbfc16d1 [24/28] powerpc/pseries/hibernation: remove redundant cacheinfo update https://git.kernel.org/powerpc/c/b866459489fe8ef0e92cde3cbd6bbb1af6c4e99b [25/28] powerpc/pseries/hibernation: perform post-suspend fixups later https://git.kernel.org/powerpc/c/fa53bcdb7413e7c40170106781f6b5bb9d74db84 [26/28] powerpc/pseries/hibernation: remove prepare_late() callback https://git.kernel.org/powerpc/c/d102f8312e1ea5e8bf84fceebf99186f22d16fc6 [27/28] powerpc/rtas: remove unused rtas_suspend_me_data https://git.kernel.org/powerpc/c/87b57ea7e109520d3c6dfb01671a0cb134d3ccff [28/28] powerpc/pseries/mobility: refactor node lookup during DT update https://git.kernel.org/powerpc/c/2efd7f6eb9b7107e469837d8452e750d7d080a5d cheers
Re: [PATCH] powerpc: Inline setup_kup()
Christophe Leroy writes:
> Le 15/12/2020 à 02:42, Michael Ellerman a écrit :
>> Christophe Leroy writes:
>>> Le 14/12/2020 à 13:30, Michael Ellerman a écrit :
setup_kup() is used by both 64-bit and 32-bit code. However on 64-bit
it must not be __init, because it's used for CPU hotplug, whereas on
32-bit it should be __init because it calls setup_kuap/kuep() which
are __init.
We worked around that problem in the past by marking it __ref, see
commit 67d53f30e23e ("powerpc/mm: fix section mismatch for
setup_kup()").
Marking it __ref basically just omits it from section mismatch
checking, which can lead to bugs, and in fact it did, see commit
44b4c4450f8d ("powerpc/64s: Mark the kuap/kuep functions non __init")
We can avoid all these problems by just making it static inline.
Because all it does is call other functions, making it inline actually
shrinks the 32-bit vmlinux by ~76 bytes.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/kup.h | 8 ++--
arch/powerpc/mm/init-common.c | 6 --
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/kup.h
b/arch/powerpc/include/asm/kup.h
index 5a9820c54da9..46b12c6dc728 100644
--- a/arch/powerpc/include/asm/kup.h
+++ b/arch/powerpc/include/asm/kup.h
@@ -49,8 +49,6 @@ extern bool disable_kuap;
#include
-void setup_kup(void);
-
#ifdef CONFIG_PPC_KUEP
void setup_kuep(bool disabled);
#else
@@ -85,6 +83,12 @@ static inline void restore_user_access(unsigned long
flags) { }
#endif /* CONFIG_PPC_BOOK3S_64 */
#endif /* CONFIG_PPC_KUAP */
+static inline void setup_kup(void)
>>>
>>> Should it be __always_inline ?
>>
>> Yes I guess so, will fix. Thanks for reviewing.
>>
>
> While we are talking about __always_inline, do you plan to take the following
> patch this cycle ?
>
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/a1d31f84ddb0926813b17fcd5cc7f3fa7b4deac2.1602759123.git.christophe.le...@csgroup.eu/
I intended to, will grab it now.
cheers
Re: [PATCH 2/2] powerpc/64s: Trim offlined CPUs from mm_cpumasks
Nicholas Piggin writes: > Excerpts from Michael Ellerman's message of December 14, 2020 8:43 pm: >> Nicholas Piggin writes: >>> Excerpts from Geert Uytterhoeven's message of December 10, 2020 7:06 pm: Hi Nicholas, On Fri, Nov 20, 2020 at 4:01 AM Nicholas Piggin wrote: > > When offlining a CPU, powerpc/64s does not flush TLBs, rather it just > leaves the CPU set in mm_cpumasks, so it continues to receive TLBIEs > to manage its TLBs. > > However the exit_flush_lazy_tlbs() function expects that after > returning, all CPUs (except self) have flushed TLBs for that mm, in > which case TLBIEL can be used for this flush. This breaks for offline > CPUs because they don't get the IPI to flush their TLB. This can lead > to stale translations. > > Fix this by clearing the CPU from mm_cpumasks, then flushing all TLBs > before going offline. > > These offlined CPU bits stuck in the cpumask also prevents the cpumask > from being trimmed back to local mode, which means continual broadcast > IPIs or TLBIEs are needed for TLB flushing. This patch prevents that > situation too. > > Signed-off-by: Nicholas Piggin Thanks for your patch! > --- a/arch/powerpc/platforms/powermac/smp.c > +++ b/arch/powerpc/platforms/powermac/smp.c > @@ -911,6 +911,8 @@ static int smp_core99_cpu_disable(void) > > mpic_cpu_set_priority(0xf); > > + cleanup_cpu_mmu_context(); > + I guess this change broke pmac32_defconfig+SMP in v5.10-rc7? arch/powerpc/platforms/powermac/smp.c: error: implicit declaration of function 'cleanup_cpu_mmu_context' [-Werror=implicit-function-declaration]: => 914:2 http://kisskb.ellerman.id.au/kisskb/buildresult/14423174/ >>> >>> Hey, yeah it does thanks for catching it. This patch fixes it for me >>> >>> --- >>> From a9b5ec92ffac975e81c6d7db6ff2b1486b2723f7 Mon Sep 17 00:00:00 2001 >>> From: Nicholas Piggin >>> Date: Mon, 14 Dec 2020 13:52:39 +1000 >>> Subject: [PATCH] powerpc/32s: Fix cleanup_cpu_mmu_context() compile bug >>> >>> 32s has no tlbiel_all() defined, so just disable the cleanup with a >>> comment. >> >> Or what about just: > > That works, I kind of wanted it in there explicit that we don't > clean up on 32s. I don't mind if you prefer this though. OK. I'll merge my version because I can do that without needing to merge master in order to get the broken commit into my tree. cheers
Re: [PATCH] powerpc/8xx: Fix early debug when SMC1 is relocated
On Fri, 4 Dec 2020 10:11:34 + (UTC), Christophe Leroy wrote: > When SMC1 is relocated and early debug is selected, the > board hangs is ppc_md.setup_arch(). This is because ones > the microcode has been loaded and SMC1 relocated, early > debug writes in the weed. > > To allow smooth continuation, the SMC1 parameter RAM set up > by the bootloader have to be copied into the new location. Applied to powerpc/next. [1/1] powerpc/8xx: Fix early debug when SMC1 is relocated https://git.kernel.org/powerpc/c/1e78f723d6a52966bfe3804209dbf404fdc9d3bb cheers
Re: [PATCH] powerpc/process: Remove target specific __set_dabr()
On Fri, 4 Dec 2020 10:12:51 + (UTC), Christophe Leroy wrote: > __set_dabr() are simple functions that can be inline directly > inside set_dabr() and using IS_ENABLED() instead of #ifdef Applied to powerpc/next. [1/1] powerpc/process: Remove target specific __set_dabr() https://git.kernel.org/powerpc/c/ad3ed15cd04b96de7c38204ba7c698cbccd8fe88 cheers
Re: [PATCH] powerpc/mm: Refactor the floor/ceiling check in hugetlb range freeing functions
On Fri, 6 Nov 2020 13:20:54 + (UTC), Christophe Leroy wrote:
> All hugetlb range freeing functions have a verification like the following,
> which only differs by the mask used, depending on the page table level.
>
> start &= MASK;
> if (start < floor)
> return;
> if (ceiling) {
> ceiling &= MASK;
> if (! ceiling)
> return;
> }
> if (end - 1 > ceiling - 1)
> return;
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/mm: Refactor the floor/ceiling check in hugetlb range freeing
functions
https://git.kernel.org/powerpc/c/7bfe54b5f16561bb703de6482f880614ada8dbf2
cheers
Re: [PATCH v1 1/3] powerpc/32s: Remove unused counters incremented by create_hpte()
On Tue, 24 Nov 2020 19:51:55 + (UTC), Christophe Leroy wrote: > primary_pteg_full and htab_hash_searches are not used. > > Remove them. Applied to powerpc/next. [1/3] powerpc/32s: Remove unused counters incremented by create_hpte() https://git.kernel.org/powerpc/c/c5ccb4e78968fbe64f938a5a012fc8ec25cafabf [2/3] powerpc/32s: In add_hash_page(), calculate VSID later https://git.kernel.org/powerpc/c/fec6166b44ded68e68144144a02e498580118f1a [3/3] powerpc/32s: Cleanup around PTE_FLAGS_OFFSET in hash_low.S https://git.kernel.org/powerpc/c/da481c4fe0e485cdab5cf4d2761be8b8fb38d3d1 cheers
Re: [PATCH v1 1/6] powerpc/8xx: DEBUG_PAGEALLOC doesn't require an ITLB miss exception handler
On Tue, 24 Nov 2020 15:24:54 + (UTC), Christophe Leroy wrote:
> Since commit e611939fc8ec ("powerpc/mm: Ensure change_page_attr()
> doesn't invalidate pinned TLBs"), pinned TLBs are not anymore
> invalidated by __kernel_map_pages() when CONFIG_DEBUG_PAGEALLOC is
> selected.
>
> Remove the dependency on CONFIG_DEBUG_PAGEALLOC.
Applied to powerpc/next.
[1/6] powerpc/8xx: DEBUG_PAGEALLOC doesn't require an ITLB miss exception
handler
https://git.kernel.org/powerpc/c/613df979da6c032cbe6fa273fb8ca21af022157e
[2/6] powerpc/8xx: Always pin kernel text TLB
https://git.kernel.org/powerpc/c/bccc58986a2f98e3af349c85c5f49aac7fb19ef2
[3/6] powerpc/8xx: Simplify INVALIDATE_ADJACENT_PAGES_CPU15
https://git.kernel.org/powerpc/c/576e02bbf1062b9118d5bbb96a40ed3b6b359f22
[4/6] powerpc/8xx: Use SPRN_SPRG_SCRATCH2 in ITLB miss exception
https://git.kernel.org/powerpc/c/a314ea5abf6dbaf35f14c9bd1d93105260fb9336
[5/6] powerpc/8xx: Use SPRN_SPRG_SCRATCH2 in DTLB miss exception
https://git.kernel.org/powerpc/c/89eecd938cab80f0da18abbd2ed997a521f83f01
[6/6] powerpc/ppc-opcode: Add PPC_RAW_MFSPR()
https://git.kernel.org/powerpc/c/70b588a068668dd7a92ed19cf0373ba92847957c
cheers
Re: [PATCH v3 0/5] Extend Parsing "ibm, thread-groups" for Shared-L2 information
On Thu, 10 Dec 2020 16:08:54 +0530, Gautham R. Shenoy wrote: > This is the v2 of the patchset to extend parsing of "ibm,thread-groups" > property > to discover the Shared-L2 cache information. > > The previous versions can be found here : > > v2 : > https://lore.kernel.org/linuxppc-dev/1607533700-5546-1-git-send-email-...@linux.vnet.ibm.com/T/#m043ea15d3832658527fca94765202b9cbefd330d > > [...] Applied to powerpc/next. [1/5] powerpc/smp: Parse ibm,thread-groups with multiple properties https://git.kernel.org/powerpc/c/790a1662d3a26fe9fa5f691386d8fde6bb8b0dc2 [2/5] powerpc/smp: Rename cpu_l1_cache_map as thread_group_l1_cache_map https://git.kernel.org/powerpc/c/1fdc1d6632ff3f6813a2f15b65586bde8fe0f0ba [3/5] powerpc/smp: Rename init_thread_group_l1_cache_map() to make it generic https://git.kernel.org/powerpc/c/fbd2b672e91d276b9fa5a729e4a823ba29fa2692 [4/5] powerpc/smp: Add support detecting thread-groups sharing L2 cache https://git.kernel.org/powerpc/c/9538abee18cca70ffd03cef56027388b0c5084cc [5/5] powerpc/cacheinfo: Print correct cache-sibling map/list for L2 cache https://git.kernel.org/powerpc/c/0be47634db0baa9e91c7e635e7e73355d6a5cf43 cheers
