Re: [PATCH] powerpc/kdump: handle crashkernel memory reservation failure
On Thu, 28 Jun 2018 10:49:56 +0530
Hari Bathini wrote:
> Memory reservation for crashkernel could fail if there are holes around
> kdump kernel offset (128M). Fail gracefully in such cases and print an
> error message.
>
> Signed-off-by: Hari Bathini
Tested-by: David Gibson
> ---
> arch/powerpc/kernel/machine_kexec.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/machine_kexec.c
> b/arch/powerpc/kernel/machine_kexec.c
> index 936c7e2..6181442 100644
> --- a/arch/powerpc/kernel/machine_kexec.c
> +++ b/arch/powerpc/kernel/machine_kexec.c
> @@ -188,7 +188,12 @@ void __init reserve_crashkernel(void)
> (unsigned long)(crashk_res.start >> 20),
> (unsigned long)(memblock_phys_mem_size() >> 20));
>
> - memblock_reserve(crashk_res.start, crash_size);
> + if (!memblock_is_region_memory(crashk_res.start, crash_size) ||
> + memblock_reserve(crashk_res.start, crash_size)) {
> + printk(KERN_ERR "Failed to reserve memory for crashkernel!\n");
> + crashk_res.start = crashk_res.end = 0;
> + return;
> + }
> }
>
> int overlaps_crashkernel(unsigned long start, unsigned long size)
>
--
David Gibson
Principal Software Engineer, Virtualization, Red Hat
pgpHk40ufQtJ4.pgp
Description: OpenPGP digital signature
[PATCH] powerpc/kdump: handle crashkernel memory reservation failure
Memory reservation for crashkernel could fail if there are holes around
kdump kernel offset (128M). Fail gracefully in such cases and print an
error message.
Signed-off-by: Hari Bathini
---
arch/powerpc/kernel/machine_kexec.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index 936c7e2..6181442 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -188,7 +188,12 @@ void __init reserve_crashkernel(void)
(unsigned long)(crashk_res.start >> 20),
(unsigned long)(memblock_phys_mem_size() >> 20));
- memblock_reserve(crashk_res.start, crash_size);
+ if (!memblock_is_region_memory(crashk_res.start, crash_size) ||
+ memblock_reserve(crashk_res.start, crash_size)) {
+ printk(KERN_ERR "Failed to reserve memory for crashkernel!\n");
+ crashk_res.start = crashk_res.end = 0;
+ return;
+ }
}
int overlaps_crashkernel(unsigned long start, unsigned long size)
Regression in 4.18 - 32-bit PowerPC crashes on boot - bisected to commit 1d40a5ea01d5
My PowerBook G4 Aluminum crashes on boot with 4.18-rcX kernels with a kernel BUG
at include/linux/page-flags.h:700! The problem was bisected to commit
1d40a5ea01d5 ("mm: mark pages in use for page tables"). It is not possible to
capture the bug with anything other than a camera. The first few lines of the
traceback are as follows:
free_pgd_range+0x19c/0x30c (unreliable)
free_pgtables_0xa0/0xb0
exit_pmap+0xf4/0x16c
mmput+0x64/0xf0
do_exit+0x33c/0x89c
oops_end+0x13c/0x144
_exception_pkey+0x58/0x128
ret_from_except_full+0x0/0x4
--- interrupt: 700 at free_pgd_range+0x19c/0x30c
LR = free_pgd_range+0x19c/0x30c
free_pgtables+0xa/0xb
exit_mnap+0xf4/0x16c
mmput+0x64/0xf0
flush_old_exec+0x490/0x550
I have a PDF of the complete dump, but I hesitate to send this to the entire
group.
Thanks,
Larry
Re: powerpc/mm/32: Fix pgtable_page_dtor call
On Mon, 2018-06-25 at 08:15:09 UTC, "Aneesh Kumar K.V" wrote:
> Commit 667416f38554 ("powerpc/mm: Fix kernel crash on page table free")
> added a call for pgtable_page_dtor in the rcu page table free routine. We
> missed
> the fact that for 32 bit platforms we did call the 'dtor' early. Drop the
> extra
> call for pgtable_page_dtor. We remove the call from __pte_free_tlb so that we
> do the page table free and 'dtor' call together. This should help when we
> switch these platforms to pte fragments.
>
> Fixes: 667416f38554 ("powerpc/mm: Fix kernel crash on page table free")
> Reported-by: Christophe Leroy
> Signed-off-by: Aneesh Kumar K.V
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/941c06d58503b9f2718b20bc45ee7f
cheers
Re: powerpc: Wire up io_pgetevents
On Wed, 2018-06-20 at 19:35:16 UTC, Breno Leitao wrote: > Wire up io_pgetevents system call on powerpc. > > io_pgetevents is a new syscall to read asynchronous I/O events from the > completion queue. > > Tested with libaio branch aio-poll[1] and the io_pgetevents test (#22) passed > on both ppc64 LE and BE modes. > > [1] https://pagure.io/libaio/branch/aio-poll > > CC: Christoph Hellwig > Signed-off-by: Breno Leitao > Acked-by: Christoph Hellwig Applied to powerpc fixes, thanks. https://git.kernel.org/powerpc/c/b2f82565f2caa1a5c1a26e68593eae cheers
Re: [1/3,v2] powerpc: mac: fix rtc read/write functions
On Tue, 2018-06-19 at 14:02:27 UTC, Arnd Bergmann wrote:
> As Mathieu pointed out, my conversion to time64_t was incorrect and resulted
> in negative times to be read from the RTC. The problem is that during the
> conversion from a byte array to a time64_t, the 'unsigned char' variable
> holding the top byte gets turned into a negative signed 32-bit integer
> before being assigned to the 64-bit variable for any times after 1972.
>
> This changes the logic to cast to an unsigned 32-bit number first for
> the Macintosh time and then convert that to the Unix time, which then gives
> us a time in the documented 1904..2040 year range. I decided not to use
> the longer 1970..2106 range that other drivers use, for consistency with
> the literal interpretation of the register, but that could be easily
> changed if we decide we want to support any Mac after 2040.
>
> Just to be on the safe side, I'm also adding a WARN_ON that will trigger
> if either the year 2040 has come and is observed by this driver, or we
> run into an RTC that got set back to a pre-1970 date for some reason
> (the two are indistinguishable).
>
> For the RTC write functions, Andreas found another problem: both
> pmu_request() and cuda_request() are varargs functions, so changing
> the type of the arguments passed into them from 32 bit to 64 bit
> breaks the API for the set_rtc_time functions. This changes it
> back to 32 bits.
>
> The same code exists in arch/m68k/ and is patched in an identical way now
> in a separate patch.
>
> Fixes: 5bfd643583b2 ("powerpc: use time64_t in read_persistent_clock")
> Reported-by: Mathieu Malaterre
> Reported-by: Andreas Schwab
> Signed-off-by: Arnd Bergmann
> Tested-by: Mathieu Malaterre
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/22db552b50fa11d8c1d171de908a1f
cheers
Re: [PATCH v9 4/6] init: allow initcall tables to be emitted using relative references
On Tue 2018-06-26 20:27:59, Ard Biesheuvel wrote: > Allow the initcall tables to be emitted using relative references that > are only half the size on 64-bit architectures and don't require fixups > at runtime on relocatable kernels. > > Cc: Petr Mladek > Cc: Sergey Senozhatsky > Cc: Steven Rostedt > Cc: James Morris > Cc: "Serge E. Hallyn" > Signed-off-by: Ard Biesheuvel > --- > include/linux/init.h | 44 +++- > init/main.c| 32 +++--- > kernel/printk/printk.c | 16 +++ > security/security.c| 17 > 4 files changed, 68 insertions(+), 41 deletions(-) For the printk stuff: Acked-by: Petr Mladek Best Regards, Petr
Re: [PATCH v9 3/6] module: use relative references for __ksymtab entries
On 27 June 2018 at 17:13, Will Deacon wrote:
> Hi Ard,
>
> On Tue, Jun 26, 2018 at 08:27:58PM +0200, Ard Biesheuvel wrote:
>> An ordinary arm64 defconfig build has ~64 KB worth of __ksymtab
>> entries, each consisting of two 64-bit fields containing absolute
>> references, to the symbol itself and to a char array containing
>> its name, respectively.
>
> [...]
>
>> diff --git a/include/linux/export.h b/include/linux/export.h
>> index ea7df303d68d..ae072bc5aacf 100644
>> --- a/include/linux/export.h
>> +++ b/include/linux/export.h
>> @@ -18,12 +18,6 @@
>> #define VMLINUX_SYMBOL_STR(x) __VMLINUX_SYMBOL_STR(x)
>>
>> #ifndef __ASSEMBLY__
>> -struct kernel_symbol
>> -{
>> - unsigned long value;
>> - const char *name;
>> -};
>> -
>> #ifdef MODULE
>> extern struct module __this_module;
>> #define THIS_MODULE (&__this_module)
>> @@ -54,17 +48,47 @@ extern struct module __this_module;
>> #define __CRC_SYMBOL(sym, sec)
>> #endif
>>
>> +#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
>> +#include
>> +/*
>> + * Emit the ksymtab entry as a pair of relative references: this reduces
>> + * the size by half on 64-bit architectures, and eliminates the need for
>> + * absolute relocations that require runtime processing on relocatable
>> + * kernels.
>> + */
>> +#define __KSYMTAB_ENTRY(sym, sec)\
>> + __ADDRESSABLE(sym) \
>> + asm(" .section \"___ksymtab" sec "+" #sym "\", \"a\" \n" \
>> + " .balign 8 \n" \
>
> Can we use KSYM_ALIGN here instead of 8, or do we need the 8-byte alignment
> even on 32-bit architectures?
>
We don't *need* 8 byte alignment on any architecture, but since the
structure itself is 8 bytes in size and we have a sizable array of
them, it makes sense to align them to 8 bytes.
Re: [PATCH v9 0/6] add support for relative references in special sections
Hi Ard, On Tue, Jun 26, 2018 at 08:27:55PM +0200, Ard Biesheuvel wrote: > This adds support for emitting special sections such as initcall arrays, > PCI fixups and tracepoints as relative references rather than absolute > references. This reduces the size by 50% on 64-bit architectures, but > more importantly, it removes the need for carrying relocation metadata > for these sections in relocatable kernels (e.g., for KASLR) that needs > to be fixed up at boot time. On arm64, this reduces the vmlinux footprint > of such a reference by 8x (8 byte absolute reference + 24 byte RELA entry > vs 4 byte relative reference) > > Patch #3 was sent out before as a single patch. This series supersedes > the previous submission. This version makes relative ksymtab entries > dependent on the new Kconfig symbol HAVE_ARCH_PREL32_RELOCATIONS rather > than trying to infer from kbuild test robot replies for which architectures > it should be blacklisted. > > Patch #1 introduces the new Kconfig symbol HAVE_ARCH_PREL32_RELOCATIONS, > and sets it for the main architectures that are expected to benefit the > most from this feature, i.e., 64-bit architectures or ones that use > runtime relocations. > > Patch #2 add support for #define'ing __DISABLE_EXPORTS to get rid of > ksymtab/kcrctab sections in decompressor and EFI stub objects when > rebuilding existing C files to run in a different context. I had a small question on patch 3, but it's really for my understanding. So, for patches 1-3: Reviewed-by: Will Deacon Thanks, Will
Re: [PATCH v9 3/6] module: use relative references for __ksymtab entries
Hi Ard,
On Tue, Jun 26, 2018 at 08:27:58PM +0200, Ard Biesheuvel wrote:
> An ordinary arm64 defconfig build has ~64 KB worth of __ksymtab
> entries, each consisting of two 64-bit fields containing absolute
> references, to the symbol itself and to a char array containing
> its name, respectively.
[...]
> diff --git a/include/linux/export.h b/include/linux/export.h
> index ea7df303d68d..ae072bc5aacf 100644
> --- a/include/linux/export.h
> +++ b/include/linux/export.h
> @@ -18,12 +18,6 @@
> #define VMLINUX_SYMBOL_STR(x) __VMLINUX_SYMBOL_STR(x)
>
> #ifndef __ASSEMBLY__
> -struct kernel_symbol
> -{
> - unsigned long value;
> - const char *name;
> -};
> -
> #ifdef MODULE
> extern struct module __this_module;
> #define THIS_MODULE (&__this_module)
> @@ -54,17 +48,47 @@ extern struct module __this_module;
> #define __CRC_SYMBOL(sym, sec)
> #endif
>
> +#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
> +#include
> +/*
> + * Emit the ksymtab entry as a pair of relative references: this reduces
> + * the size by half on 64-bit architectures, and eliminates the need for
> + * absolute relocations that require runtime processing on relocatable
> + * kernels.
> + */
> +#define __KSYMTAB_ENTRY(sym, sec)\
> + __ADDRESSABLE(sym) \
> + asm(" .section \"___ksymtab" sec "+" #sym "\", \"a\" \n" \
> + " .balign 8 \n" \
Can we use KSYM_ALIGN here instead of 8, or do we need the 8-byte alignment
even on 32-bit architectures?
Will
Re: [PATCH v9 4/6] init: allow initcall tables to be emitted using relative references
On (06/26/18 20:27), Ard Biesheuvel wrote:
> /*
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 247808333ba4..688a27b0888c 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2772,7 +2772,8 @@ EXPORT_SYMBOL(unregister_console);
> void __init console_init(void)
> {
> int ret;
> - initcall_t *call;
> + initcall_t call;
> + initcall_entry_t *ce;
>
> /* Setup the default TTY line discipline. */
> n_tty_init();
> @@ -2781,13 +2782,14 @@ void __init console_init(void)
>* set up the console device so that later boot sequences can
>* inform about problems etc..
>*/
> - call = __con_initcall_start;
> + ce = __con_initcall_start;
> trace_initcall_level("console");
> - while (call < __con_initcall_end) {
> - trace_initcall_start((*call));
> - ret = (*call)();
> - trace_initcall_finish((*call), ret);
> - call++;
> + while (ce < __con_initcall_end) {
> + call = initcall_from_entry(ce);
> + trace_initcall_start(call);
> + ret = call();
> + trace_initcall_finish(call, ret);
> + ce++;
> }
> }
printk bits look OK to me.
The patch set works fine on my x86_64 and does reduce the size of vmlinux.
Acked-by: Sergey Senozhatsky
-ss
Re: [powerpc/powervm]kernel BUG at mm/memory_hotplug.c:1864!
On 2018-06-26 20:24, Nathan Fontenot wrote: On 06/12/2018 05:28 AM, Balbir Singh wrote: On 11/06/18 17:41, vrbagal1 wrote: On 2018-06-08 17:45, Oscar Salvador wrote: On Fri, Jun 08, 2018 at 05:11:24PM +0530, vrbagal1 wrote: On 2018-06-08 16:58, Oscar Salvador wrote: On Fri, Jun 08, 2018 at 04:44:24PM +0530, vrbagal1 wrote: Greetings!!! I am seeing kernel bug followed by oops message and system reboots, while running dlpar memory hotplug test. Machine Details: Power6 PowerVM Platform GCC version: (gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC)) Test case: dlpar memory hotplug test (https://github.com/avocado-framework-tests/avocado-misc-tests/blob/master/memory/memhotplug.py) Kernel Version: Linux version 4.17.0-autotest I am seeing this bug on rc7 as well. Observing similar traces on linux next kernel: 4.17.0-next-20180608-autotest Block size [0x400] unaligned hotplug range: start 0x22000, size 0x100 size < block_size in this case, why? how? Could you confirm that the block size is 64MB and your trying to remove 16MB I was not able to re-create this failure exactly ( I don't have a Power6 system) but was able to get a similar re-create on a Power 9 with a few modifications. I think the issue you're seeing is due to a change in the validation of memory done in remove_memory to ensure the amount of memory being removed spans entire memory block. The pseries memory remove code, see pseries_remove_memblock, tries to remove each section of a memory block instead of the entire memory block. Could you try the patch below that updates the pseries code to remove the entire memory block instead of doing it one section at a time. -Nathan Hi Nathan, With below patch applied on 4.18.0-rc2 I am seeing below oops message. [ cut here ] kernel BUG at mm/memory_hotplug.c:150! Oops: Exception in kernel mode, sig: 5 [#1] BE SMP NR_CPUS=1024 NUMA pSeries Modules linked in: rpadlpar_io rpaphp nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT cfg80211 nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 rfkill xt_conntrack nf_conntrack libcrc32c ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_security iptable_raw iptable_filter ip_tables ses osst enclosure scsi_transport_sas ehea st uio_pdrv_genirq uio nfsd auth_rpcgss nfs_acl lockd grace sunrpc ipv6 crc_ccitt ext4 mbcache jbd2 sd_mod sr_mod cdrom dm_mirror dm_region_hash dm_log dm_mod dax CPU: 5 PID: 2925 Comm: drmgr Tainted: GW 4.18.0-rc2-00045-g671afc8 #2 NIP: c02cf278 LR: c02c0c38 CTR: 0400 REGS: c002ac4ab150 TRAP: 0700 Tainted: GW (4.18.0-rc2-00045-g671afc8) MSR: 80029032 CR: 28002884 XER: CFAR: c02c0c00 IRQMASK: 0 GPR00: c02c0c38 c002ac4ab3d0 c1159b00 c002b1091810 GPR04: 2b10 GPR08: c002b3fd0600 0001 0220 GPR12: 88002884 ceeaa000 0002b400 00024d00 GPR16: c002b3f8ca00 00024c00 c000d3fc89c0 00024d00 GPR20: 0003 0004 c002b3f7ca8c GPR24: GPR28: c002b3fd0600 c002b1f7c6c0 c002b3f86224 c002b1091810 NIP [c02cf278] .put_page_bootmem+0x28/0xf0 LR [c02c0c38] .sparse_remove_one_section+0x228/0x2c0 Call Trace: [c002ac4ab3d0] [c002ac4ab450] 0xc002ac4ab450 (unreliable) [c002ac4ab450] [c02c0c38] .sparse_remove_one_section+0x228/0x2c0 [c002ac4ab4f0] [c02cf6f8] .__remove_pages+0x3b8/0x550 [c002ac4ab600] [c08d32a4] .arch_remove_memory+0xb4/0x128 [c002ac4ab680] [c02d1cd0] .remove_memory+0xb0/0x100 [c002ac4ab710] [c00bc7b4] .pseries_remove_memblock+0x94/0xe0 [c002ac4ab790] [c00bd3f8] .pseries_memory_notifier+0x248/0x260 [c002ac4ab820] [c0116ee8] .notifier_call_chain+0x78/0xf0 [c002ac4ab8c0] [c0117358] .__blocking_notifier_call_chain+0x58/0x90 [c002ac4ab960] [c0743e30] .of_property_notify+0x90/0xd0 [c002ac4aba10] [c073ed04] .of_update_property+0x104/0x150 [c002ac4abac0] [c00b045c] .ofdt_write+0x3bc/0x6f0 [c002ac4abb90] [c03735b8] .proc_reg_write+0x78/0xc0 [c002ac4abc10] [c02deaac] .__vfs_write+0x3c/0x200 [c002ac4abcf0] [c02deeb0] .vfs_write+0xc0/0x230 [c002ac4abd90] [c02df214] .ksys_write+0x54/0x100 [c002ac4abe30] [c000b9dc] system_call+0x5c/0x70 Instruction dump: 6000 6000 7c0802a6 fbe1fff8 7c7f1b78 f8010010 f821ff81 e9230020 3929fff4 21290002 7d294910 7d2900d0 <0b09>
Re: [PATCH 1/3] [v2] powerpc: mac: fix rtc read/write functions
Arnd Bergmann writes: > On Wed, Jun 27, 2018 at 6:32 AM, Michael Ellerman wrote: >> >> So I think I can take this patch in isolation via the powerpc tree as a >> fix for 4.18. >> >> I'll leave the other two alone. > > Yes, that is what I had intended with this series but should have made > clearer. The two m68k patches are 4.19 material. OK thanks. cheers
Re: [PATCH 1/3] [v2] powerpc: mac: fix rtc read/write functions
On Wed, Jun 27, 2018 at 6:32 AM, Michael Ellerman wrote: > > So I think I can take this patch in isolation via the powerpc tree as a > fix for 4.18. > > I'll leave the other two alone. > Yes, that is what I had intended with this series but should have made clearer. The two m68k patches are 4.19 material. Arnd
Re: [PATCH v3 00/12] macintosh: Resolve various PMU driver problems
Gabriel, Am 27.06.2018 um 21:00 schrieb Gabriel Paubert: On Wed, Jun 27, 2018 at 05:39:15PM +1200, Michael Schmitz wrote: Ben, Am 27.06.2018 um 15:27 schrieb Benjamin Herrenschmidt: On Wed, 2018-06-27 at 13:08 +1000, Michael Ellerman wrote: I will rewrite patch 10/12 after Arnd's fixes and this series have all made their way through both powerpc and m68k trees, and submit it separately. drivers/macintosh is supposedly maintained by Ben, but I'm not sure this series is high on his todo list. We need at least to pull out a couple of powerbooks we have sitting in drawers and try it out. No need to root around in drawers - I'm sitting in front of one (G3 Titanium) writing this. Let me know if that would help (I've forgotten most of what I knew about powerpc kernels). A very rare model, all G3 I've seen were plastic, all Titanium were G4 :-) Right you are - the G3 was the earlier one I used (which was stolen from my office). G4 it is, then. Cheers, Michael Cheers, Gabriel (still using my Pismo from time to time, but much less since sleep was broken)
Re: [PATCH v3 00/12] macintosh: Resolve various PMU driver problems
On Wed, Jun 27, 2018 at 05:39:15PM +1200, Michael Schmitz wrote: > Ben, > > Am 27.06.2018 um 15:27 schrieb Benjamin Herrenschmidt: > > On Wed, 2018-06-27 at 13:08 +1000, Michael Ellerman wrote: > > > > I will rewrite patch 10/12 after Arnd's fixes and this series have all > > > > made their way through both powerpc and m68k trees, and submit it > > > > separately. > > > > > > drivers/macintosh is supposedly maintained by Ben, but I'm not sure this > > > series is high on his todo list. > > > > We need at least to pull out a couple of powerbooks we have sitting in > > drawers and try it out. > > No need to root around in drawers - I'm sitting in front of one (G3 > Titanium) writing this. Let me know if that would help (I've forgotten most > of what I knew about powerpc kernels). A very rare model, all G3 I've seen were plastic, all Titanium were G4 :-) Cheers, Gabriel (still using my Pismo from time to time, but much less since sleep was broken)
Re: [PATCH 2/3] drivers/base: reorder consumer and its children behind suppliers
On Wed, Jun 27, 2018 at 10:34:54AM +0800, Pingfan Liu wrote: > > 1b2a1e63 Pingfan Liu 2018-06-25 243} > > 1b2a1e63 Pingfan Liu 2018-06-25 244} > > 1b2a1e63 Pingfan Liu 2018-06-25 @245BUG_ON(!ret); > > > > If the list is empty then "ret" can be unitialized. We test a different > > list "dev->links.suppliers" to see if that's empty. I wrote a bunch of > > code to make Smatch try to understand about empty lists, but I don't > > think it works... > > > Yes, if list_empty, then the code can not touch ret. But ret is > useless in this scene. Does it matter? > I'm not sure I understand what you're asking? Of course, it matters? regards, dan carpenter
