Re: [PATCH] hugetlb: allow to free gigantic pages regardless of the configuration
On Thu, Jan 17, 2019 at 06:39:53PM +, Alexandre Ghiti wrote: > From: Alexandre Ghiti > > On systems without CMA or (MEMORY_ISOLATION && COMPACTION) activated but > that support gigantic pages, boottime reserved gigantic pages can not be > freed at all. This patchs simply enables the possibility to hand back > those pages to memory allocator. > > This commit then renames gigantic_page_supported and > ARCH_HAS_GIGANTIC_PAGE to make them more accurate. Indeed, those values > being false does not mean that the system cannot use gigantic pages: it > just means that runtime allocation of gigantic pages is not supported, > one can still allocate boottime gigantic pages if the architecture supports > it. > > Signed-off-by: Alexandre Ghiti > --- > > - Compiled on all architectures > - Tested on riscv architecture > > arch/arm64/Kconfig | 2 +- > arch/arm64/include/asm/hugetlb.h | 7 +++-- The arm64 bits look straightforward enough to me... Acked-by: Will Deacon Will
Re: [PATCH v13 00/10] powerpc: Switch to CONFIG_THREAD_INFO_IN_TASK
Michael Ellerman a écrit : Christophe Leroy writes: The purpose of this serie is to activate CONFIG_THREAD_INFO_IN_TASK which moves the thread_info into task_struct. Moving thread_info into task_struct has the following advantages: - It protects thread_info from corruption in the case of stack overflows. - Its address is harder to determine if stack addresses are leaked, making a number of attacks more difficult. Changes since v12: - Patch 1: Taken comment from Mike (re-introduced the 'panic' in case memblock allocation fails in setup_64.c - Patch 1: Added alloc_stack() function in setup_32.c to also panic in case of allocation failure. Hi Christophe, I can't get this series to boot on qemu mac99. I'm getting eg: Problem new with version 13 or it is the first time you test ? [0.981514] NFS: Registering the id_resolver key type [0.981752] Key type id_resolver registered [0.981868] Key type id_legacy registered [0.995711] Unrecoverable exception 0 at 0 (msr=0) [0.996091] Oops: Unrecoverable exception, sig: 6 [#1] [0.996314] BE PAGE_SIZE=4K MMU=Hash PowerMac [0.996617] Modules linked in: [0.996869] CPU: 0 PID: 416 Comm: modprobe Not tainted 5.0.0-rc2-gcc-7.3.0-00043-g53f2de798792 #342 Comm:modprobe ==> Something wrong with modules ? I never tested with CONFIG_MODULES. Christophe [0.997138] NIP: LR: CTR: [0.997309] REGS: ef237f50 TRAP: Not tainted (5.0.0-rc2-gcc-7.3.0-00043-g53f2de798792) [0.997508] MSR: <> CR: XER: [0.997712] [0.997712] GPR00: ef238000 [0.997712] GPR08: c006477c ef13d8c0 [0.997712] GPR16: [0.997712] GPR24: [0.998671] NIP [] (null) [0.998774] LR [] (null) [0.998895] Call Trace: [0.999030] Instruction dump: [0.999320] [0.999546] 6000 [1.23] ---[ end trace 925ea3419844fe68 ]--- I haven't had time to dig any further. cheers
Re: [PATCH v2] powerpc: chrp: Use device_type helpers to access the node type
On Sat, Jan 19, 2019 at 10:18 AM Guenter Roeck wrote:
>
> The node type can no longer be accessed directly, resulting in the
> following build error. Use accessor function instead.
>
> arch/powerpc/platforms/chrp/setup.c: In function ‘chrp_init_IRQ’:
> arch/powerpc/platforms/chrp/setup.c:541:33: error:
> ‘struct device_node’ has no member named ‘type’
>
> Fixes: 8ce5f8415753 ("of: Remove struct device_node.type pointer")
> Cc: Rob Herring
> Signed-off-by: Guenter Roeck
> ---
> v2: of_node_is_type() checks if the node pointer is NULL, so there is
> no need to check it before calling the function.
>
> arch/powerpc/platforms/chrp/setup.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Already have the same patch acked by Michael and am sending to Linus shortly.
Rob
[PATCH v2] powerpc: chrp: Use device_type helpers to access the node type
The node type can no longer be accessed directly, resulting in the
following build error. Use accessor function instead.
arch/powerpc/platforms/chrp/setup.c: In function ‘chrp_init_IRQ’:
arch/powerpc/platforms/chrp/setup.c:541:33: error:
‘struct device_node’ has no member named ‘type’
Fixes: 8ce5f8415753 ("of: Remove struct device_node.type pointer")
Cc: Rob Herring
Signed-off-by: Guenter Roeck
---
v2: of_node_is_type() checks if the node pointer is NULL, so there is
no need to check it before calling the function.
arch/powerpc/platforms/chrp/setup.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/chrp/setup.c
b/arch/powerpc/platforms/chrp/setup.c
index e66644e0fb40..9438fa0fc355 100644
--- a/arch/powerpc/platforms/chrp/setup.c
+++ b/arch/powerpc/platforms/chrp/setup.c
@@ -538,8 +538,7 @@ static void __init chrp_init_IRQ(void)
/* see if there is a keyboard in the device tree
with a parent of type "adb" */
for_each_node_by_name(kbd, "keyboard")
- if (kbd->parent && kbd->parent->type
- && strcmp(kbd->parent->type, "adb") == 0)
+ if (of_node_is_type(kbd->parent, "adb"))
break;
of_node_put(kbd);
if (kbd)
--
2.7.4
[PATCH] powerpc: chrp: Use device_type helpers to access the node type
The node type can no longer be accessed directly, resulting in the
following build error. Use accessor function instead.
arch/powerpc/platforms/chrp/setup.c: In function ‘chrp_init_IRQ’:
arch/powerpc/platforms/chrp/setup.c:541:33: error:
‘struct device_node’ has no member named ‘type’
Fixes: 8ce5f8415753 ("of: Remove struct device_node.type pointer")
Cc: Rob Herring
Signed-off-by: Guenter Roeck
---
arch/powerpc/platforms/chrp/setup.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/chrp/setup.c
b/arch/powerpc/platforms/chrp/setup.c
index e66644e0fb40..c79f626502bf 100644
--- a/arch/powerpc/platforms/chrp/setup.c
+++ b/arch/powerpc/platforms/chrp/setup.c
@@ -538,8 +538,7 @@ static void __init chrp_init_IRQ(void)
/* see if there is a keyboard in the device tree
with a parent of type "adb" */
for_each_node_by_name(kbd, "keyboard")
- if (kbd->parent && kbd->parent->type
- && strcmp(kbd->parent->type, "adb") == 0)
+ if (kbd->parent && of_node_is_type(kbd->parent, "adb"))
break;
of_node_put(kbd);
if (kbd)
--
2.7.4
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Fri, Jan 18, 2019 at 11:53:25AM -0800, Andy Lutomirski wrote: > On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote: > > > > On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote: > > > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote: > > > > - Once we get to 512, we clash with the x32 numbers (unless > > > > we remove x32 support first), and probably have to skip > > > > a few more. I also considered using the 512..547 space > > > > for 32-bit-only calls (which never clash with x32), but > > > > that also seems to add a bit of complexity. > > > > > > I have a patch that I'll send soon to make x32 use its own table. As > > > far as I'm concerned, 547 is *it*. 548 is just a normal number and is > > > not special. But let's please not reuse 512..547 for other purposes > > > on x86 variants -- that way lies even more confusion, IMO. > > > > Fair enough, the space for those numbers is cheap enough here. > > I take it you mean we also should not reuse that number space if > > we were to decide to remove x32 soon, but you are not worried > > about clashing with arch/alpha when everything else uses consistent > > numbers? > > > > I think we have two issues if we reuse those numbers for new syscalls. > First, I'd really like to see new syscalls be numbered consistently > everywhere, or at least on all x86 variants, and we can't on x32 > because they mean something else. Perhaps more importantly, due to > what is arguably a rather severe bug, issuing a native x86_64 syscall > (x32 bit clear) with nr in the range 512..547 does *not* return > -ENOSYS on a kernel with x32 enabled. Instead it does something that > is somewhat arbitrary. With my patch applied, it will return -ENOSYS, > but old kernels will still exist, and this will break syscall probing. > > Can we perhaps just start the consistent numbers above 547 or maybe > block out 512..547 in the new regime? I don't think you gain much with that kind of scheme - it won't take very long before an architecture misses having a syscall added, and then someone else adds their own. Been there with ARM - I was keeping the syscall table in the same order as x86 for new syscalls, but now that others have been adding syscalls to the table since I converted ARM to the tabular form, that's now gone out the window. So, I think it's completely pointless to do what you're suggesting. We'll just end up with a big hole in the middle of the syscall table and then revert back to random numbering of syscalls thereafter again. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
Re: use generic DMA mapping code in powerpc V4
On Sat, Jan 19, 2019 at 02:02:22PM +0100, Christoph Hellwig wrote: > Interesting. This suggest it is related to the use of ZONE_DMA by > the FSL SOCs that your board uses. Let me investigate this a bit more. As a hack to check that theory I've pushed a new commit to the powerpc-dma.6-debug branch to use old powerpc GFP_DMA selection with the new dma direct code: http://git.infradead.org/users/hch/misc.git/commitdiff/5c532d07c2f3c3972104de505d06b8d85f403f06 And another one that drops the addressability checks that powerpc never had: http://git.infradead.org/users/hch/misc.git/commitdiff/18e7629b38465ca98f8e7eed639123a13ac3b669 Can you first test with both patches, and then just with the first in case that worked?
Re: use generic DMA mapping code in powerpc V4
On Sat, Jan 19, 2019 at 12:52:52PM +0100, Christian Zigotzky wrote: > Hi Christoph, > > I have found a small workaround. If I add 'mem=3500M' to the boot arguments > then it detects the SATA hard disk and boots without any problems. > > X5000> setenv bootargs root=/dev/sda2 console=ttyS0,115200 mem=3500M Interesting. This suggest it is related to the use of ZONE_DMA by the FSL SOCs that your board uses. Let me investigate this a bit more.
Re: [PATCH] dmaengine: fsldma: Add 64-bit I/O accessors for powerpc64
On 24-12-18, 05:29, Peng Ma wrote:
> Hi Scott,
>
> Oh, I did not see the in_XX64/out_XX64 supported only __powerpc64__ just now.
> Thanks for your reminder.
Can you send the formal patch for this...
FWIW, fsl patches were not merged last cycle because of reported
regression...
>
> #ifdef __powerpc64__
>
> #ifdef __BIG_ENDIAN__
> DEF_MMIO_OUT_D(out_be64, 64, std);
> DEF_MMIO_IN_D(in_be64, 64, ld);
>
> /* There is no asm instructions for 64 bits reverse loads and stores */
> static inline u64 in_le64(const volatile u64 __iomem *addr)
> {
> return swab64(in_be64(addr));
> }
>
> static inline void out_le64(volatile u64 __iomem *addr, u64 val)
> {
> out_be64(addr, swab64(val));
> }
> #else
> DEF_MMIO_OUT_D(out_le64, 64, std);
> DEF_MMIO_IN_D(in_le64, 64, ld);
>
> /* There is no asm instructions for 64 bits reverse loads and stores */
> static inline u64 in_be64(const volatile u64 __iomem *addr)
> {
> return swab64(in_le64(addr));
> }
>
> static inline void out_be64(volatile u64 __iomem *addr, u64 val)
> {
> out_le64(addr, swab64(val));
> }
>
> #endif
> #endif /* __powerpc64__ */
>
> Best Regards,
> Peng
> >-Original Message-
> >From: Scott Wood
> >Sent: 2018年12月24日 12:46
> >To: Peng Ma ; Leo Li ; Zhang Wei
> >
> >Cc: linuxppc-dev@lists.ozlabs.org; dmaeng...@vger.kernel.org; Wen He
> >
> >Subject: Re: [PATCH] dmaengine: fsldma: Add 64-bit I/O accessors for
> >powerpc64
> >
> >On Mon, 2018-12-24 at 03:42 +, Peng Ma wrote:
> >> Hi Scott,
> >>
> >> You are right, we should support powerpc64, so could I changed it as
> >> fallows:
> >>
> >> diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h index
> >> 88db939..057babf 100644
> >> --- a/drivers/dma/fsldma.h
> >> +++ b/drivers/dma/fsldma.h
> >> @@ -202,35 +202,10 @@ struct fsldma_chan {
> >> #define fsl_iowrite32(v, p)out_le32(p, v)
> >> #define fsl_iowrite32be(v, p) out_be32(p, v)
> >>
> >> -#ifndef __powerpc64__
> >> -static u64 fsl_ioread64(const u64 __iomem *addr) -{
> >> - u32 fsl_addr = lower_32_bits(addr);
> >> - u64 fsl_addr_hi = (u64)in_le32((u32 *)(fsl_addr + 1)) << 32;
> >> -
> >> - return fsl_addr_hi | in_le32((u32 *)fsl_addr);
> >> -}
> >> -
> >> -static void fsl_iowrite64(u64 val, u64 __iomem *addr) -{
> >> - out_le32((u32 __iomem *)addr + 1, val >> 32);
> >> - out_le32((u32 __iomem *)addr, (u32)val);
> >> -}
> >> -
> >> -static u64 fsl_ioread64be(const u64 __iomem *addr) -{
> >> - u32 fsl_addr = lower_32_bits(addr);
> >> - u64 fsl_addr_hi = (u64)in_be32((u32 *)fsl_addr) << 32;
> >> -
> >> - return fsl_addr_hi | in_be32((u32 *)(fsl_addr + 1));
> >> -}
> >> -
> >> -static void fsl_iowrite64be(u64 val, u64 __iomem *addr) -{
> >> - out_be32((u32 __iomem *)addr, val >> 32);
> >> - out_be32((u32 __iomem *)addr + 1, (u32)val);
> >> -}
> >> -#endif
> >> +#define fsl_ioread64(p)in_le64(p)
> >> +#define fsl_ioread64be(p) in_be64(p)
> >> +#define fsl_iowrite64(v, p)out_le64(p, v)
> >> +#define fsl_iowrite64be(v, p) out_be64(p, v)
> >> #endif
> >
> >Then you'll break 32-bit, assuming those fake-it-with-two-32-bit-accesses
> >were actually needed.
> >
> >-Scott
> >
>
--
~Vinod
Re: use generic DMA mapping code in powerpc V4
Hi Christoph, I have found a small workaround. If I add 'mem=3500M' to the boot arguments then it detects the SATA hard disk and boots without any problems. X5000> setenv bootargs root=/dev/sda2 console=ttyS0,115200 mem=3500M Cheers, Christian On 19 January 2019 at 12:40PM, Christian Zigotzky wrote: Hi Christoph, I bought a USB null modem RS-232 serial cable today so I was able to get some SATA error messages. Error messages: [ 13.468538] fsl-sata ffe22.sata: Sata FSL Platform/CSB Driver init [ 13.475106] fsl-sata ffe22.sata: failed to start port 0 (errno=-12) [ 13.481736] fsl-sata ffe221000.sata: Sata FSL Platform/CSB Driver init [ 13.488267] fsl-sata ffe221000.sata: failed to start port 0 (errno=-12) --- errno=-12 = Out of memory Please find attached the complete serial log. Cheers, Christian On 18 January 2019 at 4:06PM, Christian Zigotzky wrote: Hello Christoph, I was able to compile 257002094bc5935dd63207a380d9698ab81f0775 from your Git powerpc-dma.6-debug today. Unfortunately I don't see any error messages (kernel ring buffer) and I don't have a RS232 serial null modem cable to get them. Cheers, Christian
Re: use generic DMA mapping code in powerpc V4
Hi Christoph, I bought a USB null modem RS-232 serial cable today so I was able to get some SATA error messages. Error messages: [ 13.468538] fsl-sata ffe22.sata: Sata FSL Platform/CSB Driver init [ 13.475106] fsl-sata ffe22.sata: failed to start port 0 (errno=-12) [ 13.481736] fsl-sata ffe221000.sata: Sata FSL Platform/CSB Driver init [ 13.488267] fsl-sata ffe221000.sata: failed to start port 0 (errno=-12) --- errno=-12 = Out of memory Please find attached the complete serial log. Cheers, Christian On 18 January 2019 at 4:06PM, Christian Zigotzky wrote: Hello Christoph, I was able to compile 257002094bc5935dd63207a380d9698ab81f0775 from your Git powerpc-dma.6-debug today. Unfortunately I don't see any error messages (kernel ring buffer) and I don't have a RS232 serial null modem cable to get them. Cheers, Christian =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2019.01.19 12:21:05 =~=~=~=~=~=~=~=~=~=~=~= U-Boot 2014.04 (Oct 17 2016 - 08:22:22) CPU0: P5020, Version: 2.0, (0x82200020) Core: e5500, Version: 1.2, (0x80240012) Clock Configuration: CPU0:1995 MHz, CPU1:1995 MHz, CCB:798 MHz, DDR:665 MHz (1330 MT/s data rate) (Asynchronous), LBC:49.875 MHz FMAN1: 498.750 MHz QMAN: 399 MHz PME: 399 MHz L1:D-cache 32 KiB enabled I-cache 32 KiB enabled Reset Configuration Word (RCW): : 0c54 1e1e 0010: 44808c00 ff002000 6800 4500 0020: 0003000f 0030: a000 Board: CYRUS 36-bit Addressing I2C: ready SPI: ready DRAM: Initializingusing SPD Detected UDIMM KHX1600C10D3/4G Detected UDIMM KHX1600C10D3/4G Not enough bank(chip-select) for CS0+CS1 on controller 0, interleaving disabled! Not enough bank(chip-select) for CS0+CS1 on controller 1, interleaving disabled! 6 GiB left unmapped 8 GiB (DDR3, 64-bit, CL=9, ECC off) DDR Controller Interleaving Mode: cache line Local Bus Controller Registers BR0 0xE0001001 OR0 0xFFF00010 BR1 0xE1001001 OR1 0xFFF00010 BR2 0x OR2 0x BR3 0x OR3 0x BR4 0x OR4 0x BR5 0x OR5 0x BR6 0x OR6 0x BR7 0x OR7 0x LBCR 0x4000 LCRR 0x80010004 L2:512 KiB enabled Corenet Platform Cache: 2 MiB enabled SERDES: bank 2 disabled MMC: FSL_SDHC: 0 EEPROM: NXID v0 PCIe1: Root Complex, x4 gen2, regs @ 0xfe20 01:00.0 - 1002:9440 - Display controller PCIe1: Bus 00 - 01 PCIe2: Root Complex, x4 gen2, regs @ 0xfe201000 03:00.0 - 111d:8092 - Bridge device 04:01.0- 111d:8092 - Bridge device 05:00.0 - 12d8:e111 - Bridge device 06:04.0 - 10ec:8139 - Network controller 06:05.0 - 109e:036e - Multimedia device 06:05.1 - 109e:0878 - Multimedia device 04:02.0- 111d:8092 - Bridge device 04:03.0- 111d:8092 - Bridge device 04:08.0- 111d:8092 - Bridge device 04:10.0- 111d:8092 - Bridge device PCIe2: Bus 02 - 0a PCIe3: disabled PCIe4: disabled Looking for VGA PINS: 0xfc000808 videoboot: Booting PCI video card bus 1, function 0, device 0 Begin BIOS POST End BIOS POST Setting VESA Mode Found required VESA mode About to set mode 279 About to get mode Got mode 49431 (0xc117) OK XSize = 1024 YSize = 768 Base =0xe000 mmio_base = 0x8000 bgx = 0xad55ad55 fgx = 0x0 In:serial Out: serial Err: serial ID: NXID v0 SN: 116330018 UID: 442943100191005198d3a080a080 Errata: ÿ "8 Build date: 2015/09/22 10:38:00 CRC: d4925668 SCSI: scanning bus for devices... Found 0 device(s). Net: Initializing Fman MMC read: dev # 0, block # 1130, count 128 ... Fman1: Uploading microcode version 106.1.0 Tuning PHY @ 3 Tuning PHY @ 7 FM1@DTSEC4 [PRIME], FM1@DTSEC5 MMC read: dev # 0, block # 1280, count 512 ... 512 blocks read: OK MMC read: dev # 0, block # 65536, count 131072 ... 131072 blocks read: OK USB0: USB EHCI 1.00 scanning bus 0 for devices... 5 USB Device(s) found USB1: USB EHCI 1.00 scanning bus 1 for devices... ERROR: Invalid USB EP length (9) ERROR: Invalid USB EP length (9) ERROR: Invalid USB EP length (9) 4 USB Device(s) found Timeout poll on interrupt endpoint Failed to get keyboard state from device 0c45:5303 SATA0 (3 Gbps) SATA1 (No RDY) scanning bus for devices... Found 0 device(s). X5000> setenv bootargs root=/dev/sda2 console=ttyS0,115200 X5000> load sata 0:1 100 uImage-5.0 reading uImage-5.0 10687255 bytes read in 75 ms (135.9 MiB/s) X5000> iminfo ## Checking Image at 0100 ... Legacy image found Image Name: Linux-5.0.0-rc2-2_A-EON_A1-X5000 Created: 2019-01-18 14:47:06 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:10687191 Bytes = 10.2 MiB Load Address: Entry Point: Verifying Checksum ... OK X5000> load sata 0:1 200 cyrus.dtb reading cyrus.dtb 29244 bytes read in 27 ms (1 MiB/s) X5000> bo
Re: [PATCH] powerpc: chrp: Use of_node_is_type to access device_type
Rob Herring writes:
> Commit 8ce5f8415753 ("of: Remove struct device_node.type pointer")
> removed struct device_node.type pointer, but the conversion to use
> of_node_is_type() accessor was missed in chrp_init_IRQ().
>
> Fixes: 8ce5f8415753 ("of: Remove struct device_node.type pointer")
> Reported-by: kbuild test robot
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Rob Herring
> ---
> Michael, I see you just sent a PR of fixes. I can send this to Linus if
> you prefer.
Yeah if you're happy to, thanks.
Acked-by: Michael Ellerman
cheers
Re: [PATCH 4/4] powerpc/64s: Support shrinking the SLB for debugging
Michal Suchánek writes: > On Thu, 17 Jan 2019 23:13:28 +1100 > Michael Ellerman wrote: > >> On machines with 1TB segments and a 32-entry SLB it's quite hard to >> cause sufficient SLB pressure to trigger bugs caused due to badly >> timed SLB faults. >> >> We have seen this in the past and a few years ago added the >> disable_1tb_segments command line option to force the use of 256MB >> segments. However even this allows some bugs to slip through testing >> if the SLB entry in question was recently accessed. >> >> So add a new command line parameter for debugging which shrinks the >> SLB to the minimum size we can support. Currently that size is 3, two >> bolted SLBs and 1 for dynamic use. This creates the maximal SLB > > Doesn't this violate the power of 2 requirement stated in 2/4? Yes. Good point. This was originally a hack patch in my tree, back when SLB_NUM_BOLTED was 3 and before Nick even added the slb_used_bitmap, so back then it was a power of 2 but it also didn't matter :) I think I'll rework the slb_full_bitmap patch anyway and remove the power of 2 requirement, so then this patch will be OK. Thanks for the review! cheers
Re: [PATCH v13 00/10] powerpc: Switch to CONFIG_THREAD_INFO_IN_TASK
Christophe Leroy writes: > The purpose of this serie is to activate CONFIG_THREAD_INFO_IN_TASK which > moves the thread_info into task_struct. > > Moving thread_info into task_struct has the following advantages: > - It protects thread_info from corruption in the case of stack > overflows. > - Its address is harder to determine if stack addresses are > leaked, making a number of attacks more difficult. > > Changes since v12: > - Patch 1: Taken comment from Mike (re-introduced the 'panic' in case > memblock allocation fails in setup_64.c > - Patch 1: Added alloc_stack() function in setup_32.c to also panic in case > of allocation failure. Hi Christophe, I can't get this series to boot on qemu mac99. I'm getting eg: [0.981514] NFS: Registering the id_resolver key type [0.981752] Key type id_resolver registered [0.981868] Key type id_legacy registered [0.995711] Unrecoverable exception 0 at 0 (msr=0) [0.996091] Oops: Unrecoverable exception, sig: 6 [#1] [0.996314] BE PAGE_SIZE=4K MMU=Hash PowerMac [0.996617] Modules linked in: [0.996869] CPU: 0 PID: 416 Comm: modprobe Not tainted 5.0.0-rc2-gcc-7.3.0-00043-g53f2de798792 #342 [0.997138] NIP: LR: CTR: [0.997309] REGS: ef237f50 TRAP: Not tainted (5.0.0-rc2-gcc-7.3.0-00043-g53f2de798792) [0.997508] MSR: <> CR: XER: [0.997712] [0.997712] GPR00: ef238000 [0.997712] GPR08: c006477c ef13d8c0 [0.997712] GPR16: [0.997712] GPR24: [0.998671] NIP [] (null) [0.998774] LR [] (null) [0.998895] Call Trace: [0.999030] Instruction dump: [0.999320] [0.999546] 6000 [1.23] ---[ end trace 925ea3419844fe68 ]--- I haven't had time to dig any further. cheers
