* Re: [PATCH RFC v4 02/21] PCI: Fix race condition in pci_enable/disable_device()
From: Sergey Miroshnichenko @ 2019-03-27 17:11 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Marta Rybczynska, linux-pci, linux-kernel, linux, Srinath Mannam,
linuxppc-dev
In-Reply-To: <20190326190038.GL24180@google.com>
[-- Attachment #1.1: Type: text/plain, Size: 7632 bytes --]
On 3/26/19 10:00 PM, Bjorn Helgaas wrote:
> [+cc Srinath, Marta, LKML]
>
> On Mon, Mar 11, 2019 at 04:31:03PM +0300, Sergey Miroshnichenko wrote:
>> CPU0 CPU1
>>
>> pci_enable_device_mem() pci_enable_device_mem()
>> pci_enable_bridge() pci_enable_bridge()
>> pci_is_enabled()
>> return false;
>> atomic_inc_return(enable_cnt)
>> Start actual enabling the bridge
>> ... pci_is_enabled()
>> ... return true;
>> ... Start memory requests <-- FAIL
>> ...
>> Set the PCI_COMMAND_MEMORY bit <-- Must wait for this
>>
>> This patch protects the pci_enable/disable_device() and pci_enable_bridge()
>> with mutexes.
>
> This is a subtle issue that we've tried to fix before, but we've never
> had a satisfactory solution, so I hope you've figured out the right
> fix.
>
> I'll include some links to previous discussion. This patch is very
> similar to [2], which we didn't actually apply. We did apply the
> patch from [3] as 40f11adc7cd9 ("PCI: Avoid race while enabling
> upstream bridges"), but it caused the regressions reported in [4,5],
> so we reverted it with 0f50a49e3008 ("Revert "PCI: Avoid race while
> enabling upstream bridges"").
>
Thanks for the links, I wasn't aware of these discussions and patches!
On PowerNV this issue is partially hidden by db2173198b95 ("powerpc/powernv/pci: Work
around races in PCI bridge enabling"), and on x86 BIOS pre-initializes all the bridges, so
it doesn't reproduce until hotplugging in a hotplugged bridge.
This patch is indeed similar to 40f11adc7cd9 ("PCI: Avoid race while enabling upstream
bridges"), but instead of a single static mutex it adds per-device mutexes and prevents
the dev->enable_cnt from incrementing too early. So it's not needed anymore to carefully
select a moment safe enough to enable the device.
Serge
> I think the underlying design problem is that we have a driver for
> device B calling pci_enable_device(), and it is changing the state of
> device A (an upstream bridge). The model generally is that a driver
> should only touch the device it is bound to.
>
> It's tricky to get the locking right when several children of device A
> all need to operate on A.
>
> That's all to say I'll have to think carefully about this particular
> patch, so I'll go on to the others and come back to this one.
>
> Bjorn
>
> [1] https://lore.kernel.org/linux-pci/1494256190-28993-1-git-send-email-srinath.mannam@broadcom.com/T/#u
> [RFC PATCH] pci: Concurrency issue in NVMe Init through PCIe switch
>
> [2] https://lore.kernel.org/linux-pci/1496135297-19680-1-git-send-email-srinath.mannam@broadcom.com/T/#u
> [RFC PATCH v2] pci: Concurrency issue in NVMe Init through PCIe switch
>
> [3] https://lore.kernel.org/linux-pci/1501858648-22228-1-git-send-email-srinath.mannam@broadcom.com/T/#u
> [RFC PATCH v3] pci: Concurrency issue during pci enable bridge
>
> [4] https://lore.kernel.org/linux-pci/150547971091.977464.16294045866179907260.stgit@buzz/T/#u
> [PATCH bisected regression in 4.14] PCI: fix race while enabling upstream bridges concurrently
>
> [5] https://lore.kernel.org/linux-wireless/04c9b578-693c-1dc6-9f0f-904580231b21@kernel.dk/T/#u
> iwlwifi firmware load broken in current -git
>
> [6] https://lore.kernel.org/linux-pci/744877924.5841545.1521630049567.JavaMail.zimbra@kalray.eu/T/#u
> [RFC PATCH] nvme: avoid race-conditions when enabling devices
>
>> Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
>> ---
>> drivers/pci/pci.c | 26 ++++++++++++++++++++++----
>> drivers/pci/probe.c | 1 +
>> include/linux/pci.h | 1 +
>> 3 files changed, 24 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index f006068be209..895201d4c9e6 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -1615,6 +1615,8 @@ static void pci_enable_bridge(struct pci_dev *dev)
>> struct pci_dev *bridge;
>> int retval;
>>
>> + mutex_lock(&dev->enable_mutex);
>> +
>> bridge = pci_upstream_bridge(dev);
>> if (bridge)
>> pci_enable_bridge(bridge);
>> @@ -1622,6 +1624,7 @@ static void pci_enable_bridge(struct pci_dev *dev)
>> if (pci_is_enabled(dev)) {
>> if (!dev->is_busmaster)
>> pci_set_master(dev);
>> + mutex_unlock(&dev->enable_mutex);
>> return;
>> }
>>
>> @@ -1630,11 +1633,14 @@ static void pci_enable_bridge(struct pci_dev *dev)
>> pci_err(dev, "Error enabling bridge (%d), continuing\n",
>> retval);
>> pci_set_master(dev);
>> + mutex_unlock(&dev->enable_mutex);
>> }
>>
>> static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags)
>> {
>> struct pci_dev *bridge;
>> + /* Enable-locking of bridges is performed within the pci_enable_bridge() */
>> + bool need_lock = !dev->subordinate;
>> int err;
>> int i, bars = 0;
>>
>> @@ -1650,8 +1656,13 @@ static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags)
>> dev->current_state = (pmcsr & PCI_PM_CTRL_STATE_MASK);
>> }
>>
>> - if (atomic_inc_return(&dev->enable_cnt) > 1)
>> + if (need_lock)
>> + mutex_lock(&dev->enable_mutex);
>> + if (pci_is_enabled(dev)) {
>> + if (need_lock)
>> + mutex_unlock(&dev->enable_mutex);
>> return 0; /* already enabled */
>> + }
>>
>> bridge = pci_upstream_bridge(dev);
>> if (bridge)
>> @@ -1666,8 +1677,10 @@ static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags)
>> bars |= (1 << i);
>>
>> err = do_pci_enable_device(dev, bars);
>> - if (err < 0)
>> - atomic_dec(&dev->enable_cnt);
>> + if (err >= 0)
>> + atomic_inc(&dev->enable_cnt);
>> + if (need_lock)
>> + mutex_unlock(&dev->enable_mutex);
>> return err;
>> }
>>
>> @@ -1910,15 +1923,20 @@ void pci_disable_device(struct pci_dev *dev)
>> if (dr)
>> dr->enabled = 0;
>>
>> + mutex_lock(&dev->enable_mutex);
>> dev_WARN_ONCE(&dev->dev, atomic_read(&dev->enable_cnt) <= 0,
>> "disabling already-disabled device");
>>
>> - if (atomic_dec_return(&dev->enable_cnt) != 0)
>> + if (atomic_dec_return(&dev->enable_cnt) != 0) {
>> + mutex_unlock(&dev->enable_mutex);
>> return;
>> + }
>>
>> do_pci_disable_device(dev);
>>
>> dev->is_busmaster = 0;
>> +
>> + mutex_unlock(&dev->enable_mutex);
>> }
>> EXPORT_SYMBOL(pci_disable_device);
>>
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 2ec0df04e0dc..977a127ce791 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -2267,6 +2267,7 @@ struct pci_dev *pci_alloc_dev(struct pci_bus *bus)
>> INIT_LIST_HEAD(&dev->bus_list);
>> dev->dev.type = &pci_dev_type;
>> dev->bus = pci_bus_get(bus);
>> + mutex_init(&dev->enable_mutex);
>>
>> return dev;
>> }
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index 77448215ef5b..cb2760a31fe2 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -419,6 +419,7 @@ struct pci_dev {
>> unsigned int no_vf_scan:1; /* Don't scan for VFs after IOV enablement */
>> pci_dev_flags_t dev_flags;
>> atomic_t enable_cnt; /* pci_enable_device has been called */
>> + struct mutex enable_mutex;
>>
>> u32 saved_config_space[16]; /* Config space saved at suspend time */
>> struct hlist_head saved_cap_space;
>> --
>> 2.20.1
>>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [Qemu-ppc] pseries on qemu-system-ppc64le crashes in doorbell_core_ipi()
From: Cédric Le Goater @ 2019-03-27 16:51 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, linuxppc-dev, qemu-ppc
Cc: tglx, Paul Mackerras, Nicholas Piggin, David Gibson
In-Reply-To: <7d97f3c6-4614-ead7-179a-e7e223ea3997@kaod.org>
On 3/27/19 5:37 PM, Cédric Le Goater wrote:
> On 3/27/19 1:36 PM, Sebastian Andrzej Siewior wrote:
>> With qemu-system-ppc64le -machine pseries -smp 4 I get:
>>
>> |# chrt 1 hackbench
>> |Running in process mode with 10 groups using 40 file descriptors each (== 400 tasks)
>> |Each sender will pass 100 messages of 100 bytes
>> | Oops: Exception in kernel mode, sig: 4 [#1]
>> | LE PAGE_SIZE=64K MMU=Hash PREEMPT SMP NR_CPUS=2048 NUMA pSeries
>> | Modules linked in:
>> | CPU: 0 PID: 629 Comm: hackbench Not tainted 5.1.0-rc2 #71
>> | NIP: c000000000046978 LR: c000000000046a38 CTR: c0000000000b0150
>> | REGS: c0000001fffeb8e0 TRAP: 0700 Not tainted (5.1.0-rc2)
>> | MSR: 8000000000089033 <SF,EE,ME,IR,DR,RI,LE> CR: 42000874 XER: 00000000
>> | CFAR: c000000000046a34 IRQMASK: 1
>> | GPR00: c0000000000b0170 c0000001fffebb70 c000000000a6ba00 0000000028000000
>> …
>> | NIP [c000000000046978] doorbell_core_ipi+0x28/0x30
>> | LR [c000000000046a38] doorbell_try_core_ipi+0xb8/0xf0
>> | Call Trace:
>> | [c0000001fffebb70] [c0000001fffebba0] 0xc0000001fffebba0 (unreliable)
>> | [c0000001fffebba0] [c0000000000b0170] smp_pseries_cause_ipi+0x20/0x70
>> | [c0000001fffebbd0] [c00000000004b02c] arch_send_call_function_single_ipi+0x8c/0xa0
>> | [c0000001fffebbf0] [c0000000001de600] irq_work_queue_on+0xe0/0x130
>> | [c0000001fffebc30] [c0000000001340c8] rto_push_irq_work_func+0xc8/0x120
>> …
>> | Instruction dump:
>> | 60000000 60000000 3c4c00a2 384250b0 3d220009 392949c8 81290000 3929ffff
>> | 7d231838 7c0004ac 5463017e 64632800 <7c00191c> 4e800020 3c4c00a2 38425080
>> | ---[ end trace eb842b544538cbdf ]---
>>
>> and I was wondering whether this is a qemu bug or the kernel is using an
>> opcode it should rather not. If I skip doorbell_try_core_ipi() in
>> smp_pseries_cause_ipi() then there is no crash. The comment says "POWER9
>> should not use this handler" so…
>
> I would say Linux is using a msgsndp instruction which is not implemented
> in QEMU TCG. But why have we started using dbells in Linux ?
ah. It seems arch_local_irq_restore() / replay_interrupt() generated
some interrupt.
C.
^ permalink raw reply
* Re: [Qemu-ppc] pseries on qemu-system-ppc64le crashes in doorbell_core_ipi()
From: Cédric Le Goater @ 2019-03-27 16:37 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, linuxppc-dev, qemu-ppc
Cc: tglx, Paul Mackerras, David Gibson
In-Reply-To: <20190327123615.rwhk6h3ayfurvapf@linutronix.de>
On 3/27/19 1:36 PM, Sebastian Andrzej Siewior wrote:
> With qemu-system-ppc64le -machine pseries -smp 4 I get:
>
> |# chrt 1 hackbench
> |Running in process mode with 10 groups using 40 file descriptors each (== 400 tasks)
> |Each sender will pass 100 messages of 100 bytes
> | Oops: Exception in kernel mode, sig: 4 [#1]
> | LE PAGE_SIZE=64K MMU=Hash PREEMPT SMP NR_CPUS=2048 NUMA pSeries
> | Modules linked in:
> | CPU: 0 PID: 629 Comm: hackbench Not tainted 5.1.0-rc2 #71
> | NIP: c000000000046978 LR: c000000000046a38 CTR: c0000000000b0150
> | REGS: c0000001fffeb8e0 TRAP: 0700 Not tainted (5.1.0-rc2)
> | MSR: 8000000000089033 <SF,EE,ME,IR,DR,RI,LE> CR: 42000874 XER: 00000000
> | CFAR: c000000000046a34 IRQMASK: 1
> | GPR00: c0000000000b0170 c0000001fffebb70 c000000000a6ba00 0000000028000000
> …
> | NIP [c000000000046978] doorbell_core_ipi+0x28/0x30
> | LR [c000000000046a38] doorbell_try_core_ipi+0xb8/0xf0
> | Call Trace:
> | [c0000001fffebb70] [c0000001fffebba0] 0xc0000001fffebba0 (unreliable)
> | [c0000001fffebba0] [c0000000000b0170] smp_pseries_cause_ipi+0x20/0x70
> | [c0000001fffebbd0] [c00000000004b02c] arch_send_call_function_single_ipi+0x8c/0xa0
> | [c0000001fffebbf0] [c0000000001de600] irq_work_queue_on+0xe0/0x130
> | [c0000001fffebc30] [c0000000001340c8] rto_push_irq_work_func+0xc8/0x120
> …
> | Instruction dump:
> | 60000000 60000000 3c4c00a2 384250b0 3d220009 392949c8 81290000 3929ffff
> | 7d231838 7c0004ac 5463017e 64632800 <7c00191c> 4e800020 3c4c00a2 38425080
> | ---[ end trace eb842b544538cbdf ]---
>
> and I was wondering whether this is a qemu bug or the kernel is using an
> opcode it should rather not. If I skip doorbell_try_core_ipi() in
> smp_pseries_cause_ipi() then there is no crash. The comment says "POWER9
> should not use this handler" so…
I would say Linux is using a msgsndp instruction which is not implemented
in QEMU TCG. But why have we started using dbells in Linux ?
C.
^ permalink raw reply
* Re: [PATCH v5 0/8] powerpc/powernv/pci: Make hotplug self-sufficient, independent of FW and DT
From: Bjorn Helgaas @ 2019-03-27 14:10 UTC (permalink / raw)
To: Sergey Miroshnichenko
Cc: Stewart Smith, Alexey Kardashevskiy, linux-pci, linux,
Oliver O'Halloran, linuxppc-dev
In-Reply-To: <20190311115233.6514-1-s.miroshnichenko@yadro.com>
Hi Sergey,
Since this doesn't touch drivers/pci, I assume powerpc folks will
handle this series. Let me know if otherwise.
On Mon, Mar 11, 2019 at 02:52:25PM +0300, Sergey Miroshnichenko wrote:
> This patchset allows switching from the pnv_php module to the standard
> pciehp driver for PCIe hotplug functionality, if the platform supports it:
> PowerNV working on on top of the skiboot with the "core/pci: Sync VFs and
> the changes of bdfns between the firmware and the OS" [1] patch serie
> applied.
s/bdfns/BDFs/ Maybe? I see this is a reference to another patch
series, but if it hasn't been merged yet, "BDFs" would be consistent
with "VFs" and give a hint that "bdfns" is not itself a word.
s/serie/series/
> The feature is activated by the "pci=realloc" command line argument.
From a user point of view, it doesn't seem intuitive that
"pci=realloc" also means "switch from pnv_php to pciehp".
The only direct effect of "pci=realloc" is to set pci_realloc_enable.
I haven't read the patches, but is there really something in
arch/powerpc/ that does something different based on
pci_realloc_enable?
> The goal is ability to hotplug bridges full of devices in the future. The
> "Movable BARs" [2] is a platform-independent part of our work in this. The
> final part will be movable bus numbers to support inserting a bridge in the
> middle of an existing PCIe tree.
>
> Tested on POWER8 PowerNV+PHB3 ppc64le (our Vesnin server) with:
> - the pciehp driver active;
> - the pnv_php driver disabled;
> - The "pci=realloc" argument is passed;
> - surprise hotplug of an NVME disk works;
> - controlled hotplug of a network card with SR-IOV works;
> - activating of SR-IOV on a network card works;
> - [with extra patches] manually initiated (via sysfs) rescan has found
> and turned on a hotplugged bridge;
> - Without "pci=realloc" works just as before.
>
> Changes since v4:
> - Fixed failing build when EEH is disabled in a kernel config;
> - Unfreeze the bus on EEH_IO_ERROR_VALUE(size), not only 0xffffffff;
> - Replaced the 0xff magic constant with phb->ioda.reserved_pe_idx;
> - Renamed create_pdn() -> pci_create_pdn_from_dev();
> - Renamed add_one_dev_pci_data(..., vf_index, ...) -> pci_alloc_pdn();
> - Renamed add_dev_pci_data() -> pci_create_vf_pdns();
> - Renamed remove_dev_pci_data() -> pci_destroy_vf_pdns();
> - Removed the patch fixing uninitialized IOMMU group - now it is fixed in
> commit 8f5b27347e88 ("powerpc/powernv/sriov: Register IOMMU groups for
> VFs")
>
> Changes since v3 [3]:
> - Subject changed;
> - Don't disable EEH during rescan anymore - instead just unfreeze the
> target buses deliberately;
> - Add synchronization with the firmware when changing the PCIe topology;
> - Fixed for VFs;
> - Code cleanup.
>
> Changes since v2:
> - Don't reassign bus numbers on PowerNV by default (to retain the default
> behavior), but only when pci=realloc is passed;
> - Less code affected;
> - pci_add_device_node_info is refactored with add_one_dev_pci_data;
> - Minor code cleanup.
>
> Changes since v1:
> - Fixed build for ppc64le and ppc64be when CONFIG_PCI_IOV is disabled;
> - Fixed build for ppc64e when CONFIG_EEH is disabled;
> - Fixed code style warnings.
>
> [1] https://lists.ozlabs.org/pipermail/skiboot/2019-March/013571.html
> [2] https://www.spinics.net/lists/linux-pci/msg79995.html
> [3] https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-September/178053.html
>
> Sergey Miroshnichenko (8):
> powerpc/pci: Access PCI config space directly w/o pci_dn
> powerpc/powernv/pci: Suppress an EEH error when reading an empty slot
> powerpc/pci: Create pci_dn on demand
> powerpc/pci: Reduce code duplication in pci_add_device_node_info
> powerpc/pci/IOV: Add support for runtime enabling the VFs
> powerpc/pci: Don't rely on DT is the PCI_REASSIGN_ALL_BUS is set
> powerpc/powernv/pci: Hook up the writes to PCI_SECONDARY_BUS register
> powerpc/powernv/pci: Enable reassigning the bus numbers
>
> arch/powerpc/include/asm/pci-bridge.h | 4 +-
> arch/powerpc/include/asm/ppc-pci.h | 1 +
> arch/powerpc/kernel/pci_dn.c | 170 ++++++++++-----
> arch/powerpc/kernel/rtas_pci.c | 97 ++++++---
> arch/powerpc/platforms/powernv/eeh-powernv.c | 2 +-
> arch/powerpc/platforms/powernv/pci-ioda.c | 4 +-
> arch/powerpc/platforms/powernv/pci.c | 205 +++++++++++++++++--
> arch/powerpc/platforms/pseries/pci.c | 4 +-
> 8 files changed, 379 insertions(+), 108 deletions(-)
>
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc: Make some functions static
From: Mukesh Ojha @ 2019-03-27 12:40 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman
Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <20190326204720.18882-1-malat@debian.org>
On 3/27/2019 2:17 AM, Mathieu Malaterre wrote:
> In commit cb9e4d10c448 ("[POWERPC] Add support for 750CL Holly board")
> new functions were added. Since most of these functions can be made static,
> make it so.
>
> Both holly_power_off and holly_halt functions were not changed since they
> are unused, making them static would have triggered the following warning
> (treated as error):
>
> arch/powerpc/platforms/embedded6xx/holly.c:244:13: error: 'holly_halt' defined but not used [-Werror=unused-function]
>
> Silence the following warnings triggered using W=1:
>
> arch/powerpc/platforms/embedded6xx/holly.c:47:5: error: no previous prototype for 'holly_exclude_device' [-Werror=missing-prototypes]
> arch/powerpc/platforms/embedded6xx/holly.c:190:6: error: no previous prototype for 'holly_show_cpuinfo' [-Werror=missing-prototypes]
> arch/powerpc/platforms/embedded6xx/holly.c:196:17: error: no previous prototype for 'holly_restart' [-Werror=missing-prototypes]
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
> ---
> v2: Split the patch in two operations
>
> arch/powerpc/platforms/embedded6xx/holly.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/platforms/embedded6xx/holly.c b/arch/powerpc/platforms/embedded6xx/holly.c
> index 0409714e8070..9d2eefef7b7b 100644
> --- a/arch/powerpc/platforms/embedded6xx/holly.c
> +++ b/arch/powerpc/platforms/embedded6xx/holly.c
> @@ -44,7 +44,8 @@
>
> #define HOLLY_PCI_CFG_PHYS 0x7c000000
>
> -int holly_exclude_device(struct pci_controller *hose, u_char bus, u_char devfn)
> +static int holly_exclude_device(struct pci_controller *hose, u_char bus,
> + u_char devfn)
> {
> if (bus == 0 && PCI_SLOT(devfn) == 0)
> return PCIBIOS_DEVICE_NOT_FOUND;
> @@ -187,13 +188,13 @@ static void __init holly_init_IRQ(void)
> tsi108_write_reg(TSI108_MPIC_OFFSET + 0x30c, 0);
> }
>
> -void holly_show_cpuinfo(struct seq_file *m)
> +static void holly_show_cpuinfo(struct seq_file *m)
> {
> seq_printf(m, "vendor\t\t: IBM\n");
> seq_printf(m, "machine\t\t: PPC750 GX/CL\n");
> }
>
> -void __noreturn holly_restart(char *cmd)
> +static void __noreturn holly_restart(char *cmd)
> {
> __be32 __iomem *ocn_bar1 = NULL;
> unsigned long bar;
^ permalink raw reply
* Re: [PATCH v2 2/2] Remove functions holly_power_off and holly_halt since unused
From: Mukesh Ojha @ 2019-03-27 12:24 UTC (permalink / raw)
To: Mathieu Malaterre, Michael Ellerman
Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <20190326204720.18882-2-malat@debian.org>
On 3/27/2019 2:17 AM, Mathieu Malaterre wrote:
> Silence the following warnings triggered using W=1:
>
> arch/powerpc/platforms/embedded6xx/holly.c:236:6: error: no previous prototype for 'holly_power_off' [-Werror=missing-prototypes]
> arch/powerpc/platforms/embedded6xx/holly.c:243:6: error: no previous prototype for 'holly_halt' [-Werror=missing-prototypes]
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
-Mukesh
> ---
> arch/powerpc/platforms/embedded6xx/holly.c | 12 ------------
> 1 file changed, 12 deletions(-)
>
> diff --git a/arch/powerpc/platforms/embedded6xx/holly.c b/arch/powerpc/platforms/embedded6xx/holly.c
> index 9d2eefef7b7b..829bf3697dc9 100644
> --- a/arch/powerpc/platforms/embedded6xx/holly.c
> +++ b/arch/powerpc/platforms/embedded6xx/holly.c
> @@ -234,18 +234,6 @@ static void __noreturn holly_restart(char *cmd)
> for (;;) ;
> }
>
> -void holly_power_off(void)
> -{
> - local_irq_disable();
> - /* No way to shut power off with software */
> - for (;;) ;
> -}
> -
> -void holly_halt(void)
> -{
> - holly_power_off();
> -}
> -
> /*
> * Called very early, device-tree isn't unflattened
> */
^ permalink raw reply
* pseries on qemu-system-ppc64le crashes in doorbell_core_ipi()
From: Sebastian Andrzej Siewior @ 2019-03-27 12:36 UTC (permalink / raw)
To: linuxppc-dev, qemu-ppc; +Cc: tglx, David Gibson, Paul Mackerras
With qemu-system-ppc64le -machine pseries -smp 4 I get:
|# chrt 1 hackbench
|Running in process mode with 10 groups using 40 file descriptors each (== 400 tasks)
|Each sender will pass 100 messages of 100 bytes
| Oops: Exception in kernel mode, sig: 4 [#1]
| LE PAGE_SIZE=64K MMU=Hash PREEMPT SMP NR_CPUS=2048 NUMA pSeries
| Modules linked in:
| CPU: 0 PID: 629 Comm: hackbench Not tainted 5.1.0-rc2 #71
| NIP: c000000000046978 LR: c000000000046a38 CTR: c0000000000b0150
| REGS: c0000001fffeb8e0 TRAP: 0700 Not tainted (5.1.0-rc2)
| MSR: 8000000000089033 <SF,EE,ME,IR,DR,RI,LE> CR: 42000874 XER: 00000000
| CFAR: c000000000046a34 IRQMASK: 1
| GPR00: c0000000000b0170 c0000001fffebb70 c000000000a6ba00 0000000028000000
…
| NIP [c000000000046978] doorbell_core_ipi+0x28/0x30
| LR [c000000000046a38] doorbell_try_core_ipi+0xb8/0xf0
| Call Trace:
| [c0000001fffebb70] [c0000001fffebba0] 0xc0000001fffebba0 (unreliable)
| [c0000001fffebba0] [c0000000000b0170] smp_pseries_cause_ipi+0x20/0x70
| [c0000001fffebbd0] [c00000000004b02c] arch_send_call_function_single_ipi+0x8c/0xa0
| [c0000001fffebbf0] [c0000000001de600] irq_work_queue_on+0xe0/0x130
| [c0000001fffebc30] [c0000000001340c8] rto_push_irq_work_func+0xc8/0x120
…
| Instruction dump:
| 60000000 60000000 3c4c00a2 384250b0 3d220009 392949c8 81290000 3929ffff
| 7d231838 7c0004ac 5463017e 64632800 <7c00191c> 4e800020 3c4c00a2 38425080
| ---[ end trace eb842b544538cbdf ]---
and I was wondering whether this is a qemu bug or the kernel is using an
opcode it should rather not. If I skip doorbell_try_core_ipi() in
smp_pseries_cause_ipi() then there is no crash. The comment says "POWER9
should not use this handler" so…
(This is QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-6))
Sebastian
^ permalink raw reply
* Re: [PATCH v8 4/4] hugetlb: allow to free gigantic pages regardless of the configuration
From: Alexandre Ghiti @ 2019-03-27 12:54 UTC (permalink / raw)
To: Aneesh Kumar K.V, mpe, Andrew Morton, Vlastimil Babka,
Catalin Marinas, Will Deacon, Benjamin Herrenschmidt,
Paul Mackerras, Martin Schwidefsky, Heiko Carstens,
Yoshinori Sato, Rich Felker, David S . Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H . Peter Anvin, x86, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Mike Kravetz, linux-arm-kernel,
linux-kernel, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
In-Reply-To: <87pnqcws2u.fsf@linux.ibm.com>
On 03/27/2019 11:05 AM, Aneesh Kumar K.V wrote:
> Alexandre Ghiti <alex@ghiti.fr> writes:
>
>> On 03/27/2019 09:55 AM, Aneesh Kumar K.V wrote:
>>> On 3/27/19 2:14 PM, Alexandre Ghiti wrote:
>>>>
>>>> On 03/27/2019 08:01 AM, Aneesh Kumar K.V wrote:
>>>>> On 3/27/19 12:06 PM, Alexandre Ghiti wrote:
> .....
>
>>> This is now
>>> #define __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED
>>> static inline bool gigantic_page_runtime_supported(void)
>>> {
>>> if (firmware_has_feature(FW_FEATURE_LPAR) && !radix_enabled())
>>> return false;
>>>
>>> return true;
>>> }
>>>
>>>
>>> I am wondering whether it should be
>>>
>>> #define __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED
>>> static inline bool gigantic_page_runtime_supported(void)
>>> {
>>>
>>> if (!IS_ENABLED(CONFIG_CONTIG_ALLOC))
>>> return false;
>> I don't think this test should happen here, CONFIG_CONTIG_ALLOC only allows
>> to allocate gigantic pages, doing that check here would prevent powerpc
>> to free boottime gigantic pages when not a guest. Note that this check
>> is actually done in set_max_huge_pages.
>>
>>
>>> if (firmware_has_feature(FW_FEATURE_LPAR) && !radix_enabled())
>>> return false;
>> Maybe I did not understand this check: I understood that, in the case
>> the system
>> is virtualized, we do not want it to hand back gigantic pages. Does this
>> check
>> test if the system is currently being virtualized ?
>> If yes, I think the patch is correct: it prevents freeing gigantic pages
>> when the system
>> is virtualized but allows a 'normal' system to free gigantic pages.
>>
>>
> Ok double checked the patch applying the the tree. I got confused by the
> removal of that #ifdef. So we now disallow the runtime free by checking
> for gigantic_page_runtime_supported() in __nr_hugepages_store_common.
> Now if we allow and if CONFIG_CONTIG_ALLOC is disabled, we still should
> allow to free the boot time allocated pages back to buddy.
>
> The patch looks good. You can add for the series
>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>
> -aneesh
>
Thanks for your time Aneesh,
Alex
^ permalink raw reply
* Applied "ASoC: fsl_audmix: Fix kbuild failure" to the asoc tree
From: Mark Brown @ 2019-03-27 12:52 UTC (permalink / raw)
To: Viorel Suman
Cc: Mark Rutland, devicetree@vger.kernel.org, alsa-devel, Timur Tabi,
Xiubo Li, linux-kernel@vger.kernel.org, S.j. Wang,
linuxppc-dev@lists.ozlabs.org, Takashi Iwai, Rob Herring,
Liam Girdwood, Nicolin Chen, Cosmin Samoila, Mark Brown,
dl-linux-imx, Viorel Suman, Fabio Estevam, Jaroslav Kysela,
Daniel Baluta
In-Reply-To: <1553678953-31228-1-git-send-email-viorel.suman@nxp.com>
The patch
ASoC: fsl_audmix: Fix kbuild failure
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 5fb94d46c3179cb7afd805a5a9252111316a926f Mon Sep 17 00:00:00 2001
From: Viorel Suman <viorel.suman@nxp.com>
Date: Wed, 27 Mar 2019 09:29:38 +0000
Subject: [PATCH] ASoC: fsl_audmix: Fix kbuild failure
The format in dev_dbg function must be a constant.
Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/fsl/fsl_audmix.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_audmix.c b/sound/soc/fsl/fsl_audmix.c
index 3356cb617713..dabde0342c95 100644
--- a/sound/soc/fsl/fsl_audmix.c
+++ b/sound/soc/fsl/fsl_audmix.c
@@ -90,7 +90,7 @@ static int fsl_audmix_state_trans(struct snd_soc_component *comp,
struct fsl_audmix *priv = snd_soc_component_get_drvdata(comp);
/* Enforce all required TDMs are started */
if ((priv->tdms & prm.tdms) != prm.tdms) {
- dev_dbg(comp->dev, prm.msg);
+ dev_dbg(comp->dev, "%s", prm.msg);
return -EINVAL;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] powerpc: vmlinux.lds: Drop Binutils 2.18 workarounds
From: Segher Boessenkool @ 2019-03-27 12:47 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, Joel Stanley
In-Reply-To: <8aa0290a-908c-38d8-e040-c8c0cc226eb9@c-s.fr>
On Wed, Mar 27, 2019 at 07:40:32AM +0100, Christophe Leroy wrote:
> Le 26/03/2019 à 23:29, Segher Boessenkool a écrit :
> >I tried to reproduce this. It does not fail with a ppc6xx_defconfig
> >build, and mpc885_ads_defconfig fails with
>
> So far, the only defconfig which fails for me is ppc64_defconfig, like
> Michael.
Oh, I misunderstood then. Let me try that :-)
> 885_ads is ok, I just noticed the STACK header in vmlinux that is not
> there when the patch is not applies.
Right... The linker generates that by default, it's nothing to worry
about.
> >What is your GCC?
>
> [root@localhost linux-powerpc]# powerpc64-linux-gcc -v
> Using built-in specs.
> COLLECT_GCC=powerpc64-linux-gcc
> COLLECT_LTO_WRAPPER=/opt/gcc-8.1.0-nolibc/powerpc64-linux/bin/../libexec/gcc/powerpc64-linux/8.1.0/lto-wrapper
> Target: powerpc64-linux
> Configured with: /home/arnd/git/gcc/configure --target=powerpc64-linux
> --enable-targets=all
> --prefix=/home/arnd/cross/x86_64/gcc-8.1.0-nolibc/powerpc64-linux
> --enable-languages=c --without-headers --disable-bootstrap --disable-nls
> --disable-threads --disable-shared --disable-libmudflap --disable-libssp
> --disable-libgomp --disable-decimal-float --disable-libquadmath
> --disable-libatomic --disable-libcc1 --disable-libmpx
> --enable-checking=release
> Thread model: single
> gcc version 8.1.0 (GCC)
Okay cool, a plain GCC build, importantly not a vendor compiler. Built
with my scripts no less ;-)
> [root@localhost linux-powerpc]# powerpc64-linux-ld -v
> GNU ld (GNU Binutils) 2.30
Segher
^ permalink raw reply
* Re: linux-next: build failure after merge of the sound-asoc tree
From: Mark Brown @ 2019-03-27 11:57 UTC (permalink / raw)
To: Michael Ellerman
Cc: Stephen Rothwell, Liam Girdwood, Annaliese McDermond,
Linux Kernel Mailing List, linuxppc-dev, Linux Next Mailing List,
Paul Mackerras
In-Reply-To: <87pnqdndmk.fsf@concordia.ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 700 bytes --]
On Wed, Mar 27, 2019 at 03:29:55PM +1100, Michael Ellerman wrote:
> Mark Brown <broonie@kernel.org> writes:
> > Hrm, seems PowerPC is still not using the common clock API - is there
> > any plan for that? There are some ASoC PowerPC uses so it's going to be
> > a bit of an issue as we expand our use of the clock API.
> I don't know anything about the common clock API. What would it involve
> for powerpc to use it?
It's what's in drivers/clk - you'd have to provide clock drivers for all
the clocks that are current supported by arch-specific code, make sure
that those drivers can be instantiated and then remove the custom
implementation of the clock API in arch/powerpc in favour of those.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Bad file pattern in MAINTAINERS section 'IBM Power Virtual Accelerator Switchboard'
From: Michael Ellerman @ 2019-03-27 11:39 UTC (permalink / raw)
To: Joe Perches, linux-kernel, Sukadev Bhattiprolu; +Cc: linuxppc-dev
In-Reply-To: <20190325233521.31094-1-joe@perches.com>
Joe Perches <joe@perches.com> writes:
> A file pattern line in this section of the MAINTAINERS file in linux-next
> does not have a match in the linux source files.
>
> This could occur because a matching filename was never added, was deleted
> or renamed in some other commit.
I think it was removed before the final submission.
> The commits that added and if found renamed or removed the file pattern
> are shown below.
>
> Please fix this defect appropriately.
Sukadev can you send me a patch to fix it please?
cheers
> 1: ---------------------------------------------------------------------------
>
> linux-next MAINTAINERS section:
>
> 7396 IBM Power Virtual Accelerator Switchboard
> 7397 M: Sukadev Bhattiprolu
> 7398 L: linuxppc-dev@lists.ozlabs.org
> 7399 S: Supported
> 7400 F: arch/powerpc/platforms/powernv/vas*
> 7401 F: arch/powerpc/platforms/powernv/copy-paste.h
> 7402 F: arch/powerpc/include/asm/vas.h
> --> 7403 F: arch/powerpc/include/uapi/asm/vas.h
>
> 2: ---------------------------------------------------------------------------
>
> The most recent commit that added or modified file pattern 'arch/powerpc/include/uapi/asm/vas.h':
>
> commit 4dea2d1a927c61114a168d4509b56329ea6effb7
> Author: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> Date: Mon Aug 28 23:23:33 2017 -0700
>
> powerpc/powernv/vas: Define vas_init() and vas_exit()
>
> Implement vas_init() and vas_exit() functions for a new VAS module.
> This VAS module is essentially a library for other device drivers
> and kernel users of the NX coprocessors like NX-842 and NX-GZIP.
> In the future this will be extended to add support for user space
> to access the NX coprocessors.
>
> VAS is currently only supported with 64K page size.
>
> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>
> .../devicetree/bindings/powerpc/ibm,vas.txt | 22 +++
> MAINTAINERS | 8 ++
> arch/powerpc/platforms/powernv/Kconfig | 14 ++
> arch/powerpc/platforms/powernv/Makefile | 1 +
> arch/powerpc/platforms/powernv/vas-window.c | 19 +++
> arch/powerpc/platforms/powernv/vas.c | 151 +++++++++++++++++++++
> arch/powerpc/platforms/powernv/vas.h | 2 +
> 7 files changed, 217 insertions(+)
>
> 3: ---------------------------------------------------------------------------
>
> No commit with file pattern 'arch/powerpc/include/uapi/asm/vas.h' was found
^ permalink raw reply
* Re: [PATCH] powerpc/pseries/mce: fix misleading print for TLB mutlihit.
From: Michael Ellerman @ 2019-03-27 11:37 UTC (permalink / raw)
To: Mahesh J Salgaonkar, linuxppc-dev
Cc: Aneesh Kumar K.V, Nicholas Piggin, stable
In-Reply-To: <155360342407.7831.11678112859745188108.stgit@jupiter>
Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> writes:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> On pseries, TLB multihit are reported as D-Cache Multihit. This is because
> the wrongly populated mc_err_types[] array. Per PAPR, TLB error type is 0x04
> and mc_err_types[4] points to "D-Cache" instead of "TLB" string. Fixup the
> mc_err_types[] array.
>
> Machine check error type per PAPR:
> 0x00 = Uncorrectable Memory Error (UE)
> 0x01 = SLB error
> 0x02 = ERAT Error
> 0x04 = TLB error
> 0x05 = D-Cache error
> 0x07 = I-Cache error
>
> Fixes: 8f0b80561f21 ("powerpc/pseries: Display machine check error details.")
> Cc: <stable@vger.kernel.org> # v4.19+
> Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/pseries/ras.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
> index d97d52772789..452dcfd7e5dd 100644
> --- a/arch/powerpc/platforms/pseries/ras.c
> +++ b/arch/powerpc/platforms/pseries/ras.c
> @@ -550,6 +550,7 @@ static void pseries_print_mce_info(struct pt_regs *regs,
> "UE",
> "SLB",
> "ERAT",
> + "Unknown",
> "TLB",
> "D-Cache",
> "Unknown",
It seems like we might have avoided the bug if we'd numbered them from
the start, eg.
static const char * const mc_err_types[] = {
[0] = "UE",
[1] = "SLB",
[2] = "ERAT",
[3] = "Unknown",
[4] = "TLB",
[5] = "D-Cache",
[6] = "Unknown",
[7] = "I-Cache",
};
cheers
^ permalink raw reply
* Re: [PATCH v8 4/4] hugetlb: allow to free gigantic pages regardless of the configuration
From: Aneesh Kumar K.V @ 2019-03-27 10:05 UTC (permalink / raw)
To: Alexandre Ghiti, mpe, Andrew Morton, Vlastimil Babka,
Catalin Marinas, Will Deacon, Benjamin Herrenschmidt,
Paul Mackerras, Martin Schwidefsky, Heiko Carstens,
Yoshinori Sato, Rich Felker, David S . Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H . Peter Anvin, x86, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Mike Kravetz, linux-arm-kernel,
linux-kernel, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
In-Reply-To: <e7637427-5f17-b4f4-93a2-70cac9b3a264@ghiti.fr>
Alexandre Ghiti <alex@ghiti.fr> writes:
> On 03/27/2019 09:55 AM, Aneesh Kumar K.V wrote:
>> On 3/27/19 2:14 PM, Alexandre Ghiti wrote:
>>>
>>>
>>> On 03/27/2019 08:01 AM, Aneesh Kumar K.V wrote:
>>>> On 3/27/19 12:06 PM, Alexandre Ghiti wrote:
>
.....
>>
>> This is now
>> #define __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED
>> static inline bool gigantic_page_runtime_supported(void)
>> {
>> if (firmware_has_feature(FW_FEATURE_LPAR) && !radix_enabled())
>> return false;
>>
>> return true;
>> }
>>
>>
>> I am wondering whether it should be
>>
>> #define __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED
>> static inline bool gigantic_page_runtime_supported(void)
>> {
>>
>> if (!IS_ENABLED(CONFIG_CONTIG_ALLOC))
>> return false;
>
> I don't think this test should happen here, CONFIG_CONTIG_ALLOC only allows
> to allocate gigantic pages, doing that check here would prevent powerpc
> to free boottime gigantic pages when not a guest. Note that this check
> is actually done in set_max_huge_pages.
>
>
>>
>> if (firmware_has_feature(FW_FEATURE_LPAR) && !radix_enabled())
>> return false;
>
> Maybe I did not understand this check: I understood that, in the case
> the system
> is virtualized, we do not want it to hand back gigantic pages. Does this
> check
> test if the system is currently being virtualized ?
> If yes, I think the patch is correct: it prevents freeing gigantic pages
> when the system
> is virtualized but allows a 'normal' system to free gigantic pages.
>
>
>>
Ok double checked the patch applying the the tree. I got confused by the
removal of that #ifdef. So we now disallow the runtime free by checking
for gigantic_page_runtime_supported() in __nr_hugepages_store_common.
Now if we allow and if CONFIG_CONTIG_ALLOC is disabled, we still should
allow to free the boot time allocated pages back to buddy.
The patch looks good. You can add for the series
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
-aneesh
^ permalink raw reply
* Re: [PATCH v8 4/4] hugetlb: allow to free gigantic pages regardless of the configuration
From: Alexandre Ghiti @ 2019-03-27 9:48 UTC (permalink / raw)
To: Aneesh Kumar K.V, mpe, Andrew Morton, Vlastimil Babka,
Catalin Marinas, Will Deacon, Benjamin Herrenschmidt,
Paul Mackerras, Martin Schwidefsky, Heiko Carstens,
Yoshinori Sato, Rich Felker, David S . Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H . Peter Anvin, x86, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Mike Kravetz, linux-arm-kernel,
linux-kernel, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
In-Reply-To: <aabfc780-1681-c69a-9927-4645d6499984@linux.ibm.com>
On 03/27/2019 09:55 AM, Aneesh Kumar K.V wrote:
> On 3/27/19 2:14 PM, Alexandre Ghiti wrote:
>>
>>
>> On 03/27/2019 08:01 AM, Aneesh Kumar K.V wrote:
>>> On 3/27/19 12:06 PM, Alexandre Ghiti wrote:
>>>> On systems without CONTIG_ALLOC activated but that support gigantic
>>>> pages,
>>>> boottime reserved gigantic pages can not be freed at all. This patch
>>>> simply enables the possibility to hand back those pages to memory
>>>> allocator.
>>>>
>>>> Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
>>>> Acked-by: David S. Miller <davem@davemloft.net> [sparc]
>>>>
>>>> diff --git a/arch/powerpc/include/asm/book3s/64/hugetlb.h
>>>> b/arch/powerpc/include/asm/book3s/64/hugetlb.h
>>>> index ec2a55a553c7..7013284f0f1b 100644
>>>> --- a/arch/powerpc/include/asm/book3s/64/hugetlb.h
>>>> +++ b/arch/powerpc/include/asm/book3s/64/hugetlb.h
>>>> @@ -36,8 +36,8 @@ static inline int hstate_get_psize(struct hstate
>>>> *hstate)
>>>> }
>>>> }
>>>> -#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
>>>> -static inline bool gigantic_page_supported(void)
>>>> +#define __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED
>>>> +static inline bool gigantic_page_runtime_supported(void)
>>>> {
>>>> /*
>>>> * We used gigantic page reservation with hypervisor assist
>>>> in some case.
>>>> @@ -49,7 +49,6 @@ static inline bool gigantic_page_supported(void)
>>>> return true;
>>>> }
>>>> -#endif
>>>> /* hugepd entry valid bit */
>>>> #define HUGEPD_VAL_BITS (0x8000000000000000UL)
>>>
>>> Is that correct when CONTIG_ALLOC is not enabled? I guess we want
>>>
>>> gigantic_page_runtime_supported to return false when CONTIG_ALLOC is
>>> not enabled on all architectures and on POWER when it is enabled we
>>> want it to be conditional as it is now.
>>>
>>> -aneesh
>>>
>>
>> CONFIG_ARCH_HAS_GIGANTIC_PAGE is set by default when an architecture
>> supports gigantic
>> pages: on its own, it allows to allocate boottime gigantic pages AND
>> to free them at runtime
>> (this is the goal of this series), but not to allocate runtime
>> gigantic pages.
>> If CONTIG_ALLOC is set, it allows in addition to allocate runtime
>> gigantic pages.
>>
>> I re-introduced the runtime checks because we can't know at compile
>> time if powerpc can
>> or not support gigantic pages.
>>
>> So for all architectures, gigantic_page_runtime_supported only
>> depends on
>> CONFIG_ARCH_HAS_GIGANTIC_PAGE enabled or not. The possibility to
>> allocate runtime
>> gigantic pages is dealt with after those runtime checks.
>>
>
> you removed that #ifdef in the patch above. ie we had
> #ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
> static inline bool gigantic_page_supported(void)
> {
> /*
> * We used gigantic page reservation with hypervisor assist in
> some case.
> * We cannot use runtime allocation of gigantic pages in those
> platforms
> * This is hash translation mode LPARs.
> */
> if (firmware_has_feature(FW_FEATURE_LPAR) && !radix_enabled())
> return false;
>
> return true;
> }
> #endif
Yes, I removed the #ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE because it was
defined only
if CONTIG_ALLOC was set. But now, CONFIG_ARCH_HAS_GIGANTIC_PAGE is
inconditionally
set for powerpc so I think we don't need it anymore.
Actually I have doubts now, is this true for all configurations ? I see
that it is only set for
PPC_RADIX_MMU. I think the problem is here: instead of returning true,
it should do like
the generic version, ie return IS_ENABLED(CONFIG_ARCH_HAS_GIGANTIC_PAGE).
Do you agree ?
>
>
> This is now
> #define __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED
> static inline bool gigantic_page_runtime_supported(void)
> {
> if (firmware_has_feature(FW_FEATURE_LPAR) && !radix_enabled())
> return false;
>
> return true;
> }
>
>
> I am wondering whether it should be
>
> #define __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED
> static inline bool gigantic_page_runtime_supported(void)
> {
>
> if (!IS_ENABLED(CONFIG_CONTIG_ALLOC))
> return false;
I don't think this test should happen here, CONFIG_CONTIG_ALLOC only allows
to allocate gigantic pages, doing that check here would prevent powerpc
to free boottime gigantic pages when not a guest. Note that this check
is actually done in set_max_huge_pages.
>
> if (firmware_has_feature(FW_FEATURE_LPAR) && !radix_enabled())
> return false;
Maybe I did not understand this check: I understood that, in the case
the system
is virtualized, we do not want it to hand back gigantic pages. Does this
check
test if the system is currently being virtualized ?
If yes, I think the patch is correct: it prevents freeing gigantic pages
when the system
is virtualized but allows a 'normal' system to free gigantic pages.
>
> return true;
> }
>
> or add that #ifdef back.
>
>> By the way, I forgot to ask you why you think that if an arch cannot
>> allocate runtime gigantic
>> pages, it should not be able to free boottime gigantic pages ?
>>
>
> on virtualized platforms like powervm which use a paravirtualized page
> table update mechanism (we dont' have two level table). The ability to
> map a page huge depends on how hypervisor allocated the guest ram.
> Hypervisor also allocates the guest specific page table of a specific
> size depending on how many pages are going to be mapped by what page
> size.
>
> on POWER we indicate possible guest real address that can be mapped
> via hugepage (in this case 16G) using a device tree node
> (ibm,expected#pages) . It is expected that we will map these pages
> only as 16G pages. Hence we cannot free them back to the buddy where
> it could get mapped via 64K page size.
Thanks for the explanations.
Alex
>
> -aneesh
>
>
^ permalink raw reply
* [PATCH] ASoC: fsl_audmix: Fix kbuild failure
From: Viorel Suman @ 2019-03-27 9:29 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Mark Rutland,
Jaroslav Kysela, Takashi Iwai, Timur Tabi, Nicolin Chen, Xiubo Li,
Fabio Estevam, Viorel Suman, S.j. Wang, Daniel Baluta,
Cosmin Samoila
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
linux-kernel@vger.kernel.org, Viorel Suman, dl-linux-imx,
linuxppc-dev@lists.ozlabs.org
The format in dev_dbg function must be a constant.
Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
---
sound/soc/fsl/fsl_audmix.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_audmix.c b/sound/soc/fsl/fsl_audmix.c
index 3356cb6..dabde03 100644
--- a/sound/soc/fsl/fsl_audmix.c
+++ b/sound/soc/fsl/fsl_audmix.c
@@ -90,7 +90,7 @@ static int fsl_audmix_state_trans(struct snd_soc_component *comp,
struct fsl_audmix *priv = snd_soc_component_get_drvdata(comp);
/* Enforce all required TDMs are started */
if ((priv->tdms & prm.tdms) != prm.tdms) {
- dev_dbg(comp->dev, prm.msg);
+ dev_dbg(comp->dev, "%s", prm.msg);
return -EINVAL;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] powerpc: vmlinux.lds: Drop Binutils 2.18 workarounds
From: Christophe Leroy @ 2019-03-27 9:09 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Joel Stanley
In-Reply-To: <a8fcafac-415d-7537-4f3d-008279824fef@c-s.fr>
Le 27/03/2019 à 09:56, Christophe Leroy a écrit :
>
>
> Le 26/03/2019 à 21:12, Segher Boessenkool a écrit :
>> On Tue, Mar 26, 2019 at 08:28:58PM +0100, Christophe Leroy wrote:
>>>
>>>
>>> Le 26/03/2019 à 19:19, Segher Boessenkool a écrit :
>>>> On Tue, Mar 26, 2019 at 07:55:33AM +0000, Christophe Leroy wrote:
>>>>> STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align
>>>>> 2**4
>>>>> filesz 0x00000000 memsz 0x00000000 flags rwx
>>>>
>>>> You need to prevent this one somehow. What object file forces this?
>>>
>>> mpc885_ads_defconfig
>>
>> No, which object file, ".o file". Not defconfig :-)
>>
>
> Ok, how to I know that ? Is it based on some file flags or some headers ?
>
> Here is the list of headers in vmlinux.o, is there one that shouldn't
> exist ?
>
>
> vmlinux.o: file format elf32-powerpc
>
> Sections:
> Idx Name Size VMA LMA File off Algn
> 0 .text 003320c0 00000000 00000000 00001000 2**12
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 1 .head.text 00002340 00000000 00000000 003330c0 2**0
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 2 .init.text 00017cb8 00000000 00000000 00335400 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 3 .text.unlikely 00004154 00000000 00000000 0034d0b8 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 4 .ref.text 000013f0 00000000 00000000 0035120c 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 5 .softirqentry.text 00000258 00000000 00000000 003525fc 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 6 .sched.text 00003930 00000000 00000000 00352854 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 7 .cpuidle.text 0000007c 00000000 00000000 00356184 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 8 .meminit.text 00000584 00000000 00000000 00356200 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 9 .exit.text 00000800 00000000 00000000 00356784 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 10 .rodata 0001d7a7 00000000 00000000 00356f90 2**4
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> 11 .init.rodata 00000790 00000000 00000000 00374738 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> 12 .rodata.str1.4 00022329 00000000 00000000 00374ec8 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 13 __param 000003c0 00000000 00000000 003971f4 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> 14 .note.Linux 00000018 00000000 00000000 003975b4 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 15 __ex_table 00000ca8 00000000 00000000 003975cc 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> 16 __ftr_alt_97 00000008 00000000 00000000 00398274 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 17 __ftr_fixup 00000198 00000000 00000000 00398280 2**3
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> 18 __reservedmem_of_table 000000c4 00000000 00000000 00398418 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> 19 __irqchip_of_table_end 000000c4 00000000 00000000 003984dc 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 20 __modver 00000008 00000000 00000000 003985a0 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> 21 __reservedmem_of_table_end 000000c4 00000000 00000000 003985a8
> 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 22 .eh_frame 00134eb8 00000000 00000000 0039866c 2**2
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
> 23 .fixup 00000cc8 00000000 00000000 004cd524 2**0
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 24 .data 00013668 00000000 00000000 004cf000 2**12
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 25 __bug_table 00006ce4 00000000 00000000 004e2668 2**0
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 26 .data..read_mostly 00001ce8 00000000 00000000 004e9350 2**3
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 27 .init.data 0000244c 00000000 00000000 004eb038 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 28 .init.setup 0000039c 00000000 00000000 004ed484 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 29 .initcallrootfs.init 00000004 00000000 00000000 004ed820 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 30 .data..page_aligned 00003000 00000000 00000000 004ee000 2**12
> CONTENTS, ALLOC, LOAD, DATA
> 31 .initcall3.init 00000008 00000000 00000000 004f1000 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 32 .initcallearly.init 00000010 00000000 00000000 004f1008 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 33 .initcall6.init 00000120 00000000 00000000 004f1018 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 34 .initcall4.init 00000080 00000000 00000000 004f1138 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 35 .data.once 0000009e 00000000 00000000 004f11b8 2**0
> CONTENTS, ALLOC, LOAD, DATA
> 36 .initcall1.init 00000048 00000000 00000000 004f1258 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 37 .initcall7.init 00000030 00000000 00000000 004f12a0 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 38 .machine.desc 000000e0 00000000 00000000 004f12d0 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 39 .data..cacheline_aligned 00005000 00000000 00000000 004f13b0 2**4
> CONTENTS, ALLOC, LOAD, DATA
> 40 .data..ro_after_init 000004b8 00000000 00000000 004f63b0 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 41 .initcall2.init 00000018 00000000 00000000 004f6868 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 42 .initcall5.init 00000070 00000000 00000000 004f6880 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 43 .meminit.data 00000010 00000000 00000000 004f68f0 2**2
> CONTENTS, ALLOC, LOAD, DATA
> 44 .ref.data 00000578 00000000 00000000 004f6900 2**2
> CONTENTS, ALLOC, LOAD, DATA
> 45 .exitcall.exit 000000b0 00000000 00000000 004f6e78 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 46 .initcall0.init 0000000c 00000000 00000000 004f6f28 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 47 .con_initcall.init 00000004 00000000 00000000 004f6f34 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 48 .initcall7s.init 00000004 00000000 00000000 004f6f38 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 49 .data..shared_aligned 00000118 00000000 00000000 004f6f40 2**4
> CONTENTS, ALLOC, LOAD, DATA
> 50 .sdata 00000188 00000000 00000000 004f7058 2**3
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 51 .sbss 000002d4 00000000 00000000 004f71e0 2**3
> ALLOC
> 52 .bss 0001e728 00000000 00000000 004f71e0 2**4
> ALLOC
> 53 .stab 00000270 00000000 00000000 004f71e0 2**2
> CONTENTS, RELOC, READONLY, DEBUGGING
> 54 .stabstr 00000335 00000000 00000000 004f7450 2**0
> CONTENTS, READONLY, DEBUGGING
> 55 .comment 0000339c 00000000 00000000 004f7785 2**0
> CONTENTS, READONLY
> 56 .note.GNU-stack 00000000 00000000 00000000 004fab21 2**0
> CONTENTS, READONLY, CODE
> 57 .debug_aranges 000077e8 00000000 00000000 004fab28 2**3
> CONTENTS, RELOC, READONLY, DEBUGGING
> 58 .debug_info 030a43d8 00000000 00000000 00502310 2**0
> CONTENTS, RELOC, READONLY, DEBUGGING
> 59 .debug_abbrev 0018bdc0 00000000 00000000 035a66e8 2**0
> CONTENTS, READONLY, DEBUGGING
> 60 .debug_line 005d69b9 00000000 00000000 037324a8 2**0
> CONTENTS, RELOC, READONLY, DEBUGGING
> 61 .debug_frame 00134eb8 00000000 00000000 03d08e64 2**2
> CONTENTS, RELOC, READONLY, DEBUGGING
> 62 .debug_str 01b24fc1 00000000 00000000 03e3dd1c 2**0
> CONTENTS, READONLY, DEBUGGING
> 63 .debug_loc 00242597 00000000 00000000 05962cdd 2**0
> CONTENTS, RELOC, READONLY, DEBUGGING
> 64 .debug_ranges 001ea010 00000000 00000000 05ba5274 2**0
> CONTENTS, RELOC, READONLY, DEBUGGING
> 65 .gnu.attributes 00000012 00000000 00000000 05d8f284 2**0
> CONTENTS, READONLY
>
Using readelf, I get the following output
[root@localhost linux-powerpc]# powerpc64-linux-readelf -l vmlinux
Elf file type is EXEC (Executable file)
Entry point 0xc0000000
There are 3 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x010000 0xc0000000 0x00000000 0x3f8ce4 0x417a08 RWE
0x10000
NOTE 0x3c3ca8 0xc03b3ca8 0x003b3ca8 0x0003c 0x0003c R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x10
Section to Segment mapping:
Segment Sections...
00 .head.text .text .rodata __param __modver __ex_table .notes
.init.text .exit.text .init.data .init.setup .initcall.init
.con_initcall.init __ftr_fixup .machine.desc .data .data..init_task
.data..page_aligned .data..cacheline_aligned .data..read_mostly
__bug_table .sbss .bss
01 .notes
02
Is it the section .note.GNU-stack which implies GNU_STACK program header
? That section seems to be present in most .o files.
Christophe
^ permalink raw reply
* Re: [PATCH] powerpc: vmlinux.lds: Drop Binutils 2.18 workarounds
From: Christophe Leroy @ 2019-03-27 8:56 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Joel Stanley
In-Reply-To: <20190326201231.GV3969@gate.crashing.org>
Le 26/03/2019 à 21:12, Segher Boessenkool a écrit :
> On Tue, Mar 26, 2019 at 08:28:58PM +0100, Christophe Leroy wrote:
>>
>>
>> Le 26/03/2019 à 19:19, Segher Boessenkool a écrit :
>>> On Tue, Mar 26, 2019 at 07:55:33AM +0000, Christophe Leroy wrote:
>>>> STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**4
>>>> filesz 0x00000000 memsz 0x00000000 flags rwx
>>>
>>> You need to prevent this one somehow. What object file forces this?
>>
>> mpc885_ads_defconfig
>
> No, which object file, ".o file". Not defconfig :-)
>
Ok, how to I know that ? Is it based on some file flags or some headers ?
Here is the list of headers in vmlinux.o, is there one that shouldn't
exist ?
vmlinux.o: file format elf32-powerpc
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 003320c0 00000000 00000000 00001000 2**12
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .head.text 00002340 00000000 00000000 003330c0 2**0
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
2 .init.text 00017cb8 00000000 00000000 00335400 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
3 .text.unlikely 00004154 00000000 00000000 0034d0b8 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
4 .ref.text 000013f0 00000000 00000000 0035120c 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
5 .softirqentry.text 00000258 00000000 00000000 003525fc 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
6 .sched.text 00003930 00000000 00000000 00352854 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
7 .cpuidle.text 0000007c 00000000 00000000 00356184 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
8 .meminit.text 00000584 00000000 00000000 00356200 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
9 .exit.text 00000800 00000000 00000000 00356784 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
10 .rodata 0001d7a7 00000000 00000000 00356f90 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
11 .init.rodata 00000790 00000000 00000000 00374738 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
12 .rodata.str1.4 00022329 00000000 00000000 00374ec8 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
13 __param 000003c0 00000000 00000000 003971f4 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
14 .note.Linux 00000018 00000000 00000000 003975b4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
15 __ex_table 00000ca8 00000000 00000000 003975cc 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
16 __ftr_alt_97 00000008 00000000 00000000 00398274 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
17 __ftr_fixup 00000198 00000000 00000000 00398280 2**3
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
18 __reservedmem_of_table 000000c4 00000000 00000000 00398418 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
19 __irqchip_of_table_end 000000c4 00000000 00000000 003984dc 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
20 __modver 00000008 00000000 00000000 003985a0 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
21 __reservedmem_of_table_end 000000c4 00000000 00000000 003985a8 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
22 .eh_frame 00134eb8 00000000 00000000 0039866c 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
23 .fixup 00000cc8 00000000 00000000 004cd524 2**0
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
24 .data 00013668 00000000 00000000 004cf000 2**12
CONTENTS, ALLOC, LOAD, RELOC, DATA
25 __bug_table 00006ce4 00000000 00000000 004e2668 2**0
CONTENTS, ALLOC, LOAD, RELOC, DATA
26 .data..read_mostly 00001ce8 00000000 00000000 004e9350 2**3
CONTENTS, ALLOC, LOAD, RELOC, DATA
27 .init.data 0000244c 00000000 00000000 004eb038 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
28 .init.setup 0000039c 00000000 00000000 004ed484 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
29 .initcallrootfs.init 00000004 00000000 00000000 004ed820 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
30 .data..page_aligned 00003000 00000000 00000000 004ee000 2**12
CONTENTS, ALLOC, LOAD, DATA
31 .initcall3.init 00000008 00000000 00000000 004f1000 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
32 .initcallearly.init 00000010 00000000 00000000 004f1008 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
33 .initcall6.init 00000120 00000000 00000000 004f1018 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
34 .initcall4.init 00000080 00000000 00000000 004f1138 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
35 .data.once 0000009e 00000000 00000000 004f11b8 2**0
CONTENTS, ALLOC, LOAD, DATA
36 .initcall1.init 00000048 00000000 00000000 004f1258 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
37 .initcall7.init 00000030 00000000 00000000 004f12a0 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
38 .machine.desc 000000e0 00000000 00000000 004f12d0 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
39 .data..cacheline_aligned 00005000 00000000 00000000 004f13b0 2**4
CONTENTS, ALLOC, LOAD, DATA
40 .data..ro_after_init 000004b8 00000000 00000000 004f63b0 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
41 .initcall2.init 00000018 00000000 00000000 004f6868 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
42 .initcall5.init 00000070 00000000 00000000 004f6880 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
43 .meminit.data 00000010 00000000 00000000 004f68f0 2**2
CONTENTS, ALLOC, LOAD, DATA
44 .ref.data 00000578 00000000 00000000 004f6900 2**2
CONTENTS, ALLOC, LOAD, DATA
45 .exitcall.exit 000000b0 00000000 00000000 004f6e78 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
46 .initcall0.init 0000000c 00000000 00000000 004f6f28 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
47 .con_initcall.init 00000004 00000000 00000000 004f6f34 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
48 .initcall7s.init 00000004 00000000 00000000 004f6f38 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
49 .data..shared_aligned 00000118 00000000 00000000 004f6f40 2**4
CONTENTS, ALLOC, LOAD, DATA
50 .sdata 00000188 00000000 00000000 004f7058 2**3
CONTENTS, ALLOC, LOAD, RELOC, DATA
51 .sbss 000002d4 00000000 00000000 004f71e0 2**3
ALLOC
52 .bss 0001e728 00000000 00000000 004f71e0 2**4
ALLOC
53 .stab 00000270 00000000 00000000 004f71e0 2**2
CONTENTS, RELOC, READONLY, DEBUGGING
54 .stabstr 00000335 00000000 00000000 004f7450 2**0
CONTENTS, READONLY, DEBUGGING
55 .comment 0000339c 00000000 00000000 004f7785 2**0
CONTENTS, READONLY
56 .note.GNU-stack 00000000 00000000 00000000 004fab21 2**0
CONTENTS, READONLY, CODE
57 .debug_aranges 000077e8 00000000 00000000 004fab28 2**3
CONTENTS, RELOC, READONLY, DEBUGGING
58 .debug_info 030a43d8 00000000 00000000 00502310 2**0
CONTENTS, RELOC, READONLY, DEBUGGING
59 .debug_abbrev 0018bdc0 00000000 00000000 035a66e8 2**0
CONTENTS, READONLY, DEBUGGING
60 .debug_line 005d69b9 00000000 00000000 037324a8 2**0
CONTENTS, RELOC, READONLY, DEBUGGING
61 .debug_frame 00134eb8 00000000 00000000 03d08e64 2**2
CONTENTS, RELOC, READONLY, DEBUGGING
62 .debug_str 01b24fc1 00000000 00000000 03e3dd1c 2**0
CONTENTS, READONLY, DEBUGGING
63 .debug_loc 00242597 00000000 00000000 05962cdd 2**0
CONTENTS, RELOC, READONLY, DEBUGGING
64 .debug_ranges 001ea010 00000000 00000000 05ba5274 2**0
CONTENTS, RELOC, READONLY, DEBUGGING
65 .gnu.attributes 00000012 00000000 00000000 05d8f284 2**0
CONTENTS, READONLY
Christophe
^ permalink raw reply
* Re: [PATCH v8 4/4] hugetlb: allow to free gigantic pages regardless of the configuration
From: Aneesh Kumar K.V @ 2019-03-27 8:55 UTC (permalink / raw)
To: Alexandre Ghiti, mpe, Andrew Morton, Vlastimil Babka,
Catalin Marinas, Will Deacon, Benjamin Herrenschmidt,
Paul Mackerras, Martin Schwidefsky, Heiko Carstens,
Yoshinori Sato, Rich Felker, David S . Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H . Peter Anvin, x86, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Mike Kravetz, linux-arm-kernel,
linux-kernel, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
In-Reply-To: <fbae7220-2e6f-8516-cf93-fbe430452043@ghiti.fr>
On 3/27/19 2:14 PM, Alexandre Ghiti wrote:
>
>
> On 03/27/2019 08:01 AM, Aneesh Kumar K.V wrote:
>> On 3/27/19 12:06 PM, Alexandre Ghiti wrote:
>>> On systems without CONTIG_ALLOC activated but that support gigantic
>>> pages,
>>> boottime reserved gigantic pages can not be freed at all. This patch
>>> simply enables the possibility to hand back those pages to memory
>>> allocator.
>>>
>>> Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
>>> Acked-by: David S. Miller <davem@davemloft.net> [sparc]
>>>
>>> diff --git a/arch/powerpc/include/asm/book3s/64/hugetlb.h
>>> b/arch/powerpc/include/asm/book3s/64/hugetlb.h
>>> index ec2a55a553c7..7013284f0f1b 100644
>>> --- a/arch/powerpc/include/asm/book3s/64/hugetlb.h
>>> +++ b/arch/powerpc/include/asm/book3s/64/hugetlb.h
>>> @@ -36,8 +36,8 @@ static inline int hstate_get_psize(struct hstate
>>> *hstate)
>>> }
>>> }
>>> -#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
>>> -static inline bool gigantic_page_supported(void)
>>> +#define __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED
>>> +static inline bool gigantic_page_runtime_supported(void)
>>> {
>>> /*
>>> * We used gigantic page reservation with hypervisor assist in
>>> some case.
>>> @@ -49,7 +49,6 @@ static inline bool gigantic_page_supported(void)
>>> return true;
>>> }
>>> -#endif
>>> /* hugepd entry valid bit */
>>> #define HUGEPD_VAL_BITS (0x8000000000000000UL)
>>
>> Is that correct when CONTIG_ALLOC is not enabled? I guess we want
>>
>> gigantic_page_runtime_supported to return false when CONTIG_ALLOC is
>> not enabled on all architectures and on POWER when it is enabled we
>> want it to be conditional as it is now.
>>
>> -aneesh
>>
>
> CONFIG_ARCH_HAS_GIGANTIC_PAGE is set by default when an architecture
> supports gigantic
> pages: on its own, it allows to allocate boottime gigantic pages AND to
> free them at runtime
> (this is the goal of this series), but not to allocate runtime gigantic
> pages.
> If CONTIG_ALLOC is set, it allows in addition to allocate runtime
> gigantic pages.
>
> I re-introduced the runtime checks because we can't know at compile time
> if powerpc can
> or not support gigantic pages.
>
> So for all architectures, gigantic_page_runtime_supported only depends on
> CONFIG_ARCH_HAS_GIGANTIC_PAGE enabled or not. The possibility to
> allocate runtime
> gigantic pages is dealt with after those runtime checks.
>
you removed that #ifdef in the patch above. ie we had
#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
static inline bool gigantic_page_supported(void)
{
/*
* We used gigantic page reservation with hypervisor assist in some case.
* We cannot use runtime allocation of gigantic pages in those platforms
* This is hash translation mode LPARs.
*/
if (firmware_has_feature(FW_FEATURE_LPAR) && !radix_enabled())
return false;
return true;
}
#endif
This is now
#define __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED
static inline bool gigantic_page_runtime_supported(void)
{
if (firmware_has_feature(FW_FEATURE_LPAR) && !radix_enabled())
return false;
return true;
}
I am wondering whether it should be
#define __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED
static inline bool gigantic_page_runtime_supported(void)
{
if (!IS_ENABLED(CONFIG_CONTIG_ALLOC))
return false;
if (firmware_has_feature(FW_FEATURE_LPAR) && !radix_enabled())
return false;
return true;
}
or add that #ifdef back.
> By the way, I forgot to ask you why you think that if an arch cannot
> allocate runtime gigantic
> pages, it should not be able to free boottime gigantic pages ?
>
on virtualized platforms like powervm which use a paravirtualized page
table update mechanism (we dont' have two level table). The ability to
map a page huge depends on how hypervisor allocated the guest ram.
Hypervisor also allocates the guest specific page table of a specific
size depending on how many pages are going to be mapped by what page size.
on POWER we indicate possible guest real address that can be mapped via
hugepage (in this case 16G) using a device tree node
(ibm,expected#pages) . It is expected that we will map these pages only
as 16G pages. Hence we cannot free them back to the buddy where it could
get mapped via 64K page size.
-aneesh
^ permalink raw reply
* Re: [PATCH v8 4/4] hugetlb: allow to free gigantic pages regardless of the configuration
From: Alexandre Ghiti @ 2019-03-27 8:44 UTC (permalink / raw)
To: Aneesh Kumar K.V, mpe, Andrew Morton, Vlastimil Babka,
Catalin Marinas, Will Deacon, Benjamin Herrenschmidt,
Paul Mackerras, Martin Schwidefsky, Heiko Carstens,
Yoshinori Sato, Rich Felker, David S . Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H . Peter Anvin, x86, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Mike Kravetz, linux-arm-kernel,
linux-kernel, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
In-Reply-To: <f6e74ad8-acca-3b1e-27eb-a2881ac8437d@linux.ibm.com>
On 03/27/2019 08:01 AM, Aneesh Kumar K.V wrote:
> On 3/27/19 12:06 PM, Alexandre Ghiti wrote:
>> On systems without CONTIG_ALLOC activated but that support gigantic
>> pages,
>> boottime reserved gigantic pages can not be freed at all. This patch
>> simply enables the possibility to hand back those pages to memory
>> allocator.
>>
>> Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
>> Acked-by: David S. Miller <davem@davemloft.net> [sparc]
>>
>> diff --git a/arch/powerpc/include/asm/book3s/64/hugetlb.h
>> b/arch/powerpc/include/asm/book3s/64/hugetlb.h
>> index ec2a55a553c7..7013284f0f1b 100644
>> --- a/arch/powerpc/include/asm/book3s/64/hugetlb.h
>> +++ b/arch/powerpc/include/asm/book3s/64/hugetlb.h
>> @@ -36,8 +36,8 @@ static inline int hstate_get_psize(struct hstate
>> *hstate)
>> }
>> }
>> -#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
>> -static inline bool gigantic_page_supported(void)
>> +#define __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED
>> +static inline bool gigantic_page_runtime_supported(void)
>> {
>> /*
>> * We used gigantic page reservation with hypervisor assist in
>> some case.
>> @@ -49,7 +49,6 @@ static inline bool gigantic_page_supported(void)
>> return true;
>> }
>> -#endif
>> /* hugepd entry valid bit */
>> #define HUGEPD_VAL_BITS (0x8000000000000000UL)
>
> Is that correct when CONTIG_ALLOC is not enabled? I guess we want
>
> gigantic_page_runtime_supported to return false when CONTIG_ALLOC is
> not enabled on all architectures and on POWER when it is enabled we
> want it to be conditional as it is now.
>
> -aneesh
>
CONFIG_ARCH_HAS_GIGANTIC_PAGE is set by default when an architecture
supports gigantic
pages: on its own, it allows to allocate boottime gigantic pages AND to
free them at runtime
(this is the goal of this series), but not to allocate runtime gigantic
pages.
If CONTIG_ALLOC is set, it allows in addition to allocate runtime
gigantic pages.
I re-introduced the runtime checks because we can't know at compile time
if powerpc can
or not support gigantic pages.
So for all architectures, gigantic_page_runtime_supported only depends on
CONFIG_ARCH_HAS_GIGANTIC_PAGE enabled or not. The possibility to
allocate runtime
gigantic pages is dealt with after those runtime checks.
By the way, I forgot to ask you why you think that if an arch cannot
allocate runtime gigantic
pages, it should not be able to free boottime gigantic pages ?
^ permalink raw reply
* Re: [PATCH v8 4/4] hugetlb: allow to free gigantic pages regardless of the configuration
From: Aneesh Kumar K.V @ 2019-03-27 7:01 UTC (permalink / raw)
To: Alexandre Ghiti, mpe, Andrew Morton, Vlastimil Babka,
Catalin Marinas, Will Deacon, Benjamin Herrenschmidt,
Paul Mackerras, Martin Schwidefsky, Heiko Carstens,
Yoshinori Sato, Rich Felker, David S . Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H . Peter Anvin, x86, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Mike Kravetz, linux-arm-kernel,
linux-kernel, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
In-Reply-To: <20190327063626.18421-5-alex@ghiti.fr>
On 3/27/19 12:06 PM, Alexandre Ghiti wrote:
> On systems without CONTIG_ALLOC activated but that support gigantic pages,
> boottime reserved gigantic pages can not be freed at all. This patch
> simply enables the possibility to hand back those pages to memory
> allocator.
>
> Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
> Acked-by: David S. Miller <davem@davemloft.net> [sparc]
>
> diff --git a/arch/powerpc/include/asm/book3s/64/hugetlb.h b/arch/powerpc/include/asm/book3s/64/hugetlb.h
> index ec2a55a553c7..7013284f0f1b 100644
> --- a/arch/powerpc/include/asm/book3s/64/hugetlb.h
> +++ b/arch/powerpc/include/asm/book3s/64/hugetlb.h
> @@ -36,8 +36,8 @@ static inline int hstate_get_psize(struct hstate *hstate)
> }
> }
>
> -#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
> -static inline bool gigantic_page_supported(void)
> +#define __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED
> +static inline bool gigantic_page_runtime_supported(void)
> {
> /*
> * We used gigantic page reservation with hypervisor assist in some case.
> @@ -49,7 +49,6 @@ static inline bool gigantic_page_supported(void)
>
> return true;
> }
> -#endif
>
> /* hugepd entry valid bit */
> #define HUGEPD_VAL_BITS (0x8000000000000000UL)
Is that correct when CONTIG_ALLOC is not enabled? I guess we want
gigantic_page_runtime_supported to return false when CONTIG_ALLOC is not
enabled on all architectures and on POWER when it is enabled we want it
to be conditional as it is now.
-aneesh
^ permalink raw reply
* [PATCH v8 4/4] hugetlb: allow to free gigantic pages regardless of the configuration
From: Alexandre Ghiti @ 2019-03-27 6:36 UTC (permalink / raw)
To: aneesh.kumar, mpe, Andrew Morton, Vlastimil Babka,
Catalin Marinas, Will Deacon, Benjamin Herrenschmidt,
Paul Mackerras, Martin Schwidefsky, Heiko Carstens,
Yoshinori Sato, Rich Felker, David S . Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H . Peter Anvin, x86, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Mike Kravetz, linux-arm-kernel,
linux-kernel, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
Cc: Alexandre Ghiti
In-Reply-To: <20190327063626.18421-1-alex@ghiti.fr>
On systems without CONTIG_ALLOC activated but that support gigantic pages,
boottime reserved gigantic pages can not be freed at all. This patch
simply enables the possibility to hand back those pages to memory
allocator.
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Acked-by: David S. Miller <davem@davemloft.net> [sparc]
---
arch/arm64/Kconfig | 2 +-
arch/arm64/include/asm/hugetlb.h | 4 --
arch/powerpc/include/asm/book3s/64/hugetlb.h | 5 +-
arch/powerpc/platforms/Kconfig.cputype | 2 +-
arch/s390/Kconfig | 2 +-
arch/s390/include/asm/hugetlb.h | 8 +--
arch/sh/Kconfig | 2 +-
arch/sparc/Kconfig | 2 +-
arch/x86/Kconfig | 2 +-
arch/x86/include/asm/hugetlb.h | 4 --
include/asm-generic/hugetlb.h | 7 +++
include/linux/gfp.h | 2 +-
mm/hugetlb.c | 54 ++++++++++++++------
mm/page_alloc.c | 4 +-
14 files changed, 61 insertions(+), 39 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a8380629cb3f..d33c6a7b9fc5 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -18,7 +18,7 @@ config ARM64
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
- select ARCH_HAS_GIGANTIC_PAGE if CONTIG_ALLOC
+ select ARCH_HAS_GIGANTIC_PAGE
select ARCH_HAS_KCOV
select ARCH_HAS_MEMBARRIER_SYNC_CORE
select ARCH_HAS_PTE_SPECIAL
diff --git a/arch/arm64/include/asm/hugetlb.h b/arch/arm64/include/asm/hugetlb.h
index c6a07a3b433e..4aad6382f631 100644
--- a/arch/arm64/include/asm/hugetlb.h
+++ b/arch/arm64/include/asm/hugetlb.h
@@ -70,8 +70,4 @@ extern void set_huge_swap_pte_at(struct mm_struct *mm, unsigned long addr,
#include <asm-generic/hugetlb.h>
-#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
-static inline bool gigantic_page_supported(void) { return true; }
-#endif
-
#endif /* __ASM_HUGETLB_H */
diff --git a/arch/powerpc/include/asm/book3s/64/hugetlb.h b/arch/powerpc/include/asm/book3s/64/hugetlb.h
index ec2a55a553c7..7013284f0f1b 100644
--- a/arch/powerpc/include/asm/book3s/64/hugetlb.h
+++ b/arch/powerpc/include/asm/book3s/64/hugetlb.h
@@ -36,8 +36,8 @@ static inline int hstate_get_psize(struct hstate *hstate)
}
}
-#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
-static inline bool gigantic_page_supported(void)
+#define __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED
+static inline bool gigantic_page_runtime_supported(void)
{
/*
* We used gigantic page reservation with hypervisor assist in some case.
@@ -49,7 +49,6 @@ static inline bool gigantic_page_supported(void)
return true;
}
-#endif
/* hugepd entry valid bit */
#define HUGEPD_VAL_BITS (0x8000000000000000UL)
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index eb0f592cde69..03ca91439473 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -325,7 +325,7 @@ config ARCH_ENABLE_SPLIT_PMD_PTLOCK
config PPC_RADIX_MMU
bool "Radix MMU Support"
depends on PPC_BOOK3S_64
- select ARCH_HAS_GIGANTIC_PAGE if CONTIG_ALLOC
+ select ARCH_HAS_GIGANTIC_PAGE
default y
help
Enable support for the Power ISA 3.0 Radix style MMU. Currently this
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 1c8cb55b4e5d..5a9cc12c32c6 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -69,7 +69,7 @@ config S390
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
- select ARCH_HAS_GIGANTIC_PAGE if CONTIG_ALLOC
+ select ARCH_HAS_GIGANTIC_PAGE
select ARCH_HAS_KCOV
select ARCH_HAS_PTE_SPECIAL
select ARCH_HAS_SET_MEMORY
diff --git a/arch/s390/include/asm/hugetlb.h b/arch/s390/include/asm/hugetlb.h
index 2d1afa58a4b6..bb59dd964590 100644
--- a/arch/s390/include/asm/hugetlb.h
+++ b/arch/s390/include/asm/hugetlb.h
@@ -116,7 +116,9 @@ static inline pte_t huge_pte_modify(pte_t pte, pgprot_t newprot)
return pte_modify(pte, newprot);
}
-#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
-static inline bool gigantic_page_supported(void) { return true; }
-#endif
+static inline bool gigantic_page_runtime_supported(void)
+{
+ return true;
+}
+
#endif /* _ASM_S390_HUGETLB_H */
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 67931bdaf32f..6d3db745ab7c 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -53,7 +53,7 @@ config SUPERH
select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_NMI
select NEED_SG_DMA_LENGTH
- select ARCH_HAS_GIGANTIC_PAGE if CONTIG_ALLOC
+ select ARCH_HAS_GIGANTIC_PAGE
help
The SuperH is a RISC processor targeted for use in embedded systems
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 52193cfb0f32..98f8dd663fd8 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -91,7 +91,7 @@ config SPARC64
select ARCH_CLOCKSOURCE_DATA
select ARCH_HAS_PTE_SPECIAL
select PCI_DOMAINS if PCI
- select ARCH_HAS_GIGANTIC_PAGE if CONTIG_ALLOC
+ select ARCH_HAS_GIGANTIC_PAGE
config ARCH_DEFCONFIG
string
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 749bab313dc1..1b7584d17a5a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -21,7 +21,7 @@ config X86_64
def_bool y
depends on 64BIT
# Options that are inherently 64-bit kernel only:
- select ARCH_HAS_GIGANTIC_PAGE if CONTIG_ALLOC
+ select ARCH_HAS_GIGANTIC_PAGE
select ARCH_SUPPORTS_INT128
select ARCH_USE_CMPXCHG_LOCKREF
select HAVE_ARCH_SOFT_DIRTY
diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include/asm/hugetlb.h
index 7469d321f072..f65cfb48cfdd 100644
--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@ -17,8 +17,4 @@ static inline void arch_clear_hugepage_flags(struct page *page)
{
}
-#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
-static inline bool gigantic_page_supported(void) { return true; }
-#endif
-
#endif /* _ASM_X86_HUGETLB_H */
diff --git a/include/asm-generic/hugetlb.h b/include/asm-generic/hugetlb.h
index 71d7b77eea50..822f433ac95c 100644
--- a/include/asm-generic/hugetlb.h
+++ b/include/asm-generic/hugetlb.h
@@ -126,4 +126,11 @@ static inline pte_t huge_ptep_get(pte_t *ptep)
}
#endif
+#ifndef __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED
+static inline bool gigantic_page_runtime_supported(void)
+{
+ return IS_ENABLED(CONFIG_ARCH_HAS_GIGANTIC_PAGE);
+}
+#endif /* __HAVE_ARCH_GIGANTIC_PAGE_RUNTIME_SUPPORTED */
+
#endif /* _ASM_GENERIC_HUGETLB_H */
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index e77ab30e9328..fb07b503dc45 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -589,8 +589,8 @@ static inline bool pm_suspended_storage(void)
/* The below functions must be run on a range from a single zone. */
extern int alloc_contig_range(unsigned long start, unsigned long end,
unsigned migratetype, gfp_t gfp_mask);
-extern void free_contig_range(unsigned long pfn, unsigned nr_pages);
#endif
+void free_contig_range(unsigned long pfn, unsigned int nr_pages);
#ifdef CONFIG_CMA
/* CMA stuff */
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 97b1e0290c66..f3e84c1bef11 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1059,6 +1059,7 @@ static void free_gigantic_page(struct page *page, unsigned int order)
free_contig_range(page_to_pfn(page), 1 << order);
}
+#ifdef CONFIG_CONTIG_ALLOC
static int __alloc_gigantic_page(unsigned long start_pfn,
unsigned long nr_pages, gfp_t gfp_mask)
{
@@ -1143,11 +1144,20 @@ static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
static void prep_new_huge_page(struct hstate *h, struct page *page, int nid);
static void prep_compound_gigantic_page(struct page *page, unsigned int order);
+#else /* !CONFIG_CONTIG_ALLOC */
+static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
+ int nid, nodemask_t *nodemask)
+{
+ return NULL;
+}
+#endif /* CONFIG_CONTIG_ALLOC */
#else /* !CONFIG_ARCH_HAS_GIGANTIC_PAGE */
-static inline bool gigantic_page_supported(void) { return false; }
static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
- int nid, nodemask_t *nodemask) { return NULL; }
+ int nid, nodemask_t *nodemask)
+{
+ return NULL;
+}
static inline void free_gigantic_page(struct page *page, unsigned int order) { }
static inline void destroy_compound_gigantic_page(struct page *page,
unsigned int order) { }
@@ -1157,7 +1167,7 @@ static void update_and_free_page(struct hstate *h, struct page *page)
{
int i;
- if (hstate_is_gigantic(h) && !gigantic_page_supported())
+ if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported())
return;
h->nr_huge_pages--;
@@ -2277,13 +2287,27 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed,
}
#define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages)
-static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
- nodemask_t *nodes_allowed)
+static int set_max_huge_pages(struct hstate *h, unsigned long count,
+ nodemask_t *nodes_allowed)
{
unsigned long min_count, ret;
- if (hstate_is_gigantic(h) && !gigantic_page_supported())
- return h->max_huge_pages;
+ spin_lock(&hugetlb_lock);
+
+ /*
+ * Gigantic pages runtime allocation depend on the capability for large
+ * page range allocation.
+ * If the system does not provide this feature, return an error when
+ * the user tries to allocate gigantic pages but let the user free the
+ * boottime allocated gigantic pages.
+ */
+ if (hstate_is_gigantic(h) && !IS_ENABLED(CONFIG_CONTIG_ALLOC)) {
+ if (count > persistent_huge_pages(h)) {
+ spin_unlock(&hugetlb_lock);
+ return -EINVAL;
+ }
+ /* Fall through to decrease pool */
+ }
/*
* Increase the pool size
@@ -2296,7 +2320,6 @@ static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
* pool might be one hugepage larger than it needs to be, but
* within all the constraints specified by the sysctls.
*/
- spin_lock(&hugetlb_lock);
while (h->surplus_huge_pages && count > persistent_huge_pages(h)) {
if (!adjust_pool_surplus(h, nodes_allowed, -1))
break;
@@ -2351,9 +2374,10 @@ static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
break;
}
out:
- ret = persistent_huge_pages(h);
+ h->max_huge_pages = persistent_huge_pages(h);
spin_unlock(&hugetlb_lock);
- return ret;
+
+ return 0;
}
#define HSTATE_ATTR_RO(_name) \
@@ -2405,7 +2429,7 @@ static ssize_t __nr_hugepages_store_common(bool obey_mempolicy,
int err;
NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY);
- if (hstate_is_gigantic(h) && !gigantic_page_supported()) {
+ if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported()) {
err = -EINVAL;
goto out;
}
@@ -2429,15 +2453,13 @@ static ssize_t __nr_hugepages_store_common(bool obey_mempolicy,
} else
nodes_allowed = &node_states[N_MEMORY];
- h->max_huge_pages = set_max_huge_pages(h, count, nodes_allowed);
+ err = set_max_huge_pages(h, count, nodes_allowed);
+out:
if (nodes_allowed != &node_states[N_MEMORY])
NODEMASK_FREE(nodes_allowed);
- return len;
-out:
- NODEMASK_FREE(nodes_allowed);
- return err;
+ return err ? err : len;
}
static ssize_t nr_hugepages_store_common(bool obey_mempolicy,
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index ecb115a74a9d..cad000879f14 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -8318,8 +8318,9 @@ int alloc_contig_range(unsigned long start, unsigned long end,
pfn_max_align_up(end), migratetype);
return ret;
}
+#endif /* CONFIG_CONTIG_ALLOC */
-void free_contig_range(unsigned long pfn, unsigned nr_pages)
+void free_contig_range(unsigned long pfn, unsigned int nr_pages)
{
unsigned int count = 0;
@@ -8331,7 +8332,6 @@ void free_contig_range(unsigned long pfn, unsigned nr_pages)
}
WARN(count != 0, "%d pages are still in use!\n", count);
}
-#endif
#ifdef CONFIG_MEMORY_HOTPLUG
/*
--
2.20.1
^ permalink raw reply related
* [PATCH v8 0/4] Fix free/allocation of runtime gigantic pages
From: Alexandre Ghiti @ 2019-03-27 6:36 UTC (permalink / raw)
To: aneesh.kumar, mpe, Andrew Morton, Vlastimil Babka,
Catalin Marinas, Will Deacon, Benjamin Herrenschmidt,
Paul Mackerras, Martin Schwidefsky, Heiko Carstens,
Yoshinori Sato, Rich Felker, David S . Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H . Peter Anvin, x86, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Mike Kravetz, linux-arm-kernel,
linux-kernel, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
Cc: Alexandre Ghiti
This series fixes sh and sparc that did not advertise their gigantic page
support and then were not able to allocate and free those pages at runtime.
It renames MEMORY_ISOLATION && COMPACTION || CMA condition into the more
accurate CONTIG_ALLOC, since it allows the definition of alloc_contig_range
function.
Finally, it then fixes the wrong definition of ARCH_HAS_GIGANTIC_PAGE config
that, without MEMORY_ISOLATION && COMPACTION || CMA defined, did not allow
architectures to free boottime allocated gigantic pages although unrelated.
Changes in v8:
This (hopefully last) version is rebased against v5.1-rc2 so that
it takes into account https://patchwork.ozlabs.org/patch/1047003/.
This version:
- factorizes gigantic_page_runtime_supported such as suggested
by Christophe.
- fix checkpath warning regarding the use of 'extern'
- fix s390 build that does not include asm-generic/hugetlb.h
And note that I did not add the reviewed-by and acked-by received in v6
since the patch differs a little.
Changes in v7:
I thought gigantic page support was settled at compile time, but Aneesh
and Michael have just come up with a patch proving me wrong for
powerpc: https://patchwork.ozlabs.org/patch/1047003/. So this version:
- reintroduces gigantic_page_supported renamed into
gigantic_page_runtime_supported
- reintroduces gigantic page page support corresponding checks (not
everywhere though: set_max_huge_pages check was redundant with
__nr_hugepages_store_common)
- introduces the possibility for arch to override this function
by using asm-generic/hugetlb.h current semantics although Aneesh
proposed something else.
Changes in v6:
- Remove unnecessary goto since the fallthrough path does the same and is
the 'normal' behaviour, as suggested by Dave Hensen
- Be more explicit in comment in set_max_huge_page: we return an error
if alloc_contig_range is not defined and the user tries to allocate a
gigantic page (we keep the same behaviour as before this patch), but we
now let her free boottime gigantic page, as suggested by Dave Hensen
- Add Acked-by, thanks.
Changes in v5:
- Fix bug in previous version thanks to Mike Kravetz
- Fix block comments that did not respect coding style thanks to Dave Hensen
- Define ARCH_HAS_GIGANTIC_PAGE only for sparc64 as advised by David Miller
- Factorize "def_bool" and "depends on" thanks to Vlastimil Babka
Changes in v4 as suggested by Dave Hensen:
- Split previous version into small patches
- Do not compile alloc_gigantic** functions for architectures that do not
support those pages
- Define correct ARCH_HAS_GIGANTIC_PAGE in all arch that support them to avoid
useless runtime check
- Add comment in set_max_huge_pages to explain that freeing is possible even
without CONTIG_ALLOC defined
- Remove gigantic_page_supported function across all archs
Changes in v3 as suggested by Vlastimil Babka and Dave Hansen:
- config definition was wrong and is now in mm/Kconfig
- COMPACTION_CORE was renamed in CONTIG_ALLOC
Changes in v2 as suggested by Vlastimil Babka:
- Get rid of ARCH_HAS_GIGANTIC_PAGE
- Get rid of architecture specific gigantic_page_supported
- Factorize CMA or (MEMORY_ISOLATION && COMPACTION) into COMPACTION_CORE
Alexandre Ghiti (4):
sh: Advertise gigantic page support
sparc: Advertise gigantic page support
mm: Simplify MEMORY_ISOLATION && COMPACTION || CMA into CONTIG_ALLOC
hugetlb: allow to free gigantic pages regardless of the configuration
arch/arm64/Kconfig | 2 +-
arch/arm64/include/asm/hugetlb.h | 4 --
arch/powerpc/include/asm/book3s/64/hugetlb.h | 5 +-
arch/powerpc/platforms/Kconfig.cputype | 2 +-
arch/s390/Kconfig | 2 +-
arch/s390/include/asm/hugetlb.h | 8 +--
arch/sh/Kconfig | 1 +
arch/sparc/Kconfig | 1 +
arch/x86/Kconfig | 2 +-
arch/x86/include/asm/hugetlb.h | 4 --
arch/x86/mm/hugetlbpage.c | 2 +-
include/asm-generic/hugetlb.h | 7 +++
include/linux/gfp.h | 4 +-
mm/Kconfig | 3 ++
mm/hugetlb.c | 54 ++++++++++++++------
mm/page_alloc.c | 7 ++-
16 files changed, 67 insertions(+), 41 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH] powerpc: vmlinux.lds: Drop Binutils 2.18 workarounds
From: Christophe Leroy @ 2019-03-27 6:40 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Joel Stanley
In-Reply-To: <20190326222941.GW3969@gate.crashing.org>
Le 26/03/2019 à 23:29, Segher Boessenkool a écrit :
> On Tue, Mar 26, 2019 at 03:12:31PM -0500, Segher Boessenkool wrote:
>> On Tue, Mar 26, 2019 at 08:28:58PM +0100, Christophe Leroy wrote:
>>>
>>>
>>> Le 26/03/2019 à 19:19, Segher Boessenkool a écrit :
>>>> On Tue, Mar 26, 2019 at 07:55:33AM +0000, Christophe Leroy wrote:
>>>>> STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**4
>>>>> filesz 0x00000000 memsz 0x00000000 flags rwx
>>>>
>>>> You need to prevent this one somehow. What object file forces this?
>>>
>>> mpc885_ads_defconfig
>>
>> No, which object file, ".o file". Not defconfig :-)
>
> I tried to reproduce this. It does not fail with a ppc6xx_defconfig
> build, and mpc885_ads_defconfig fails with
So far, the only defconfig which fails for me is ppc64_defconfig, like
Michael.
885_ads is ok, I just noticed the STACK header in vmlinux that is not
there when the patch is not applies.
>
> INFO: Uncompressed kernel (size 0x435178) overlaps the address of the wrapper(0x400000)
> INFO: Fixing the link_address of wrapper to (0x500000)
> ln: failed to access 'arch/powerpc/boot/cuImage.mpc885ads': No such file or directory
>
> What is your GCC?
[root@localhost linux-powerpc]# powerpc64-linux-gcc -v
Using built-in specs.
COLLECT_GCC=powerpc64-linux-gcc
COLLECT_LTO_WRAPPER=/opt/gcc-8.1.0-nolibc/powerpc64-linux/bin/../libexec/gcc/powerpc64-linux/8.1.0/lto-wrapper
Target: powerpc64-linux
Configured with: /home/arnd/git/gcc/configure --target=powerpc64-linux
--enable-targets=all
--prefix=/home/arnd/cross/x86_64/gcc-8.1.0-nolibc/powerpc64-linux
--enable-languages=c --without-headers --disable-bootstrap --disable-nls
--disable-threads --disable-shared --disable-libmudflap --disable-libssp
--disable-libgomp --disable-decimal-float --disable-libquadmath
--disable-libatomic --disable-libcc1 --disable-libmpx
--enable-checking=release
Thread model: single
gcc version 8.1.0 (GCC)
[root@localhost linux-powerpc]# powerpc64-linux-ld -v
GNU ld (GNU Binutils) 2.30
Christophe
^ permalink raw reply
* [PATCH v8 3/4] mm: Simplify MEMORY_ISOLATION && COMPACTION || CMA into CONTIG_ALLOC
From: Alexandre Ghiti @ 2019-03-27 6:36 UTC (permalink / raw)
To: aneesh.kumar, mpe, Andrew Morton, Vlastimil Babka,
Catalin Marinas, Will Deacon, Benjamin Herrenschmidt,
Paul Mackerras, Martin Schwidefsky, Heiko Carstens,
Yoshinori Sato, Rich Felker, David S . Miller, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H . Peter Anvin, x86, Dave Hansen,
Andy Lutomirski, Peter Zijlstra, Mike Kravetz, linux-arm-kernel,
linux-kernel, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
Cc: Alexandre Ghiti
In-Reply-To: <20190327063626.18421-1-alex@ghiti.fr>
This condition allows to define alloc_contig_range, so simplify
it into a more accurate naming.
Suggested-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
---
arch/arm64/Kconfig | 2 +-
arch/powerpc/platforms/Kconfig.cputype | 2 +-
arch/s390/Kconfig | 2 +-
arch/sh/Kconfig | 2 +-
arch/sparc/Kconfig | 2 +-
arch/x86/Kconfig | 2 +-
arch/x86/mm/hugetlbpage.c | 2 +-
include/linux/gfp.h | 2 +-
mm/Kconfig | 3 +++
mm/page_alloc.c | 3 +--
10 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7e34b9eba5de..a8380629cb3f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -18,7 +18,7 @@ config ARM64
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
- select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
+ select ARCH_HAS_GIGANTIC_PAGE if CONTIG_ALLOC
select ARCH_HAS_KCOV
select ARCH_HAS_MEMBARRIER_SYNC_CORE
select ARCH_HAS_PTE_SPECIAL
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 842b2c7e156a..eb0f592cde69 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -325,7 +325,7 @@ config ARCH_ENABLE_SPLIT_PMD_PTLOCK
config PPC_RADIX_MMU
bool "Radix MMU Support"
depends on PPC_BOOK3S_64
- select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
+ select ARCH_HAS_GIGANTIC_PAGE if CONTIG_ALLOC
default y
help
Enable support for the Power ISA 3.0 Radix style MMU. Currently this
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index b6e3d0653002..1c8cb55b4e5d 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -69,7 +69,7 @@ config S390
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_GCOV_PROFILE_ALL
- select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
+ select ARCH_HAS_GIGANTIC_PAGE if CONTIG_ALLOC
select ARCH_HAS_KCOV
select ARCH_HAS_PTE_SPECIAL
select ARCH_HAS_SET_MEMORY
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 0d9fb2468e0b..67931bdaf32f 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -53,7 +53,7 @@ config SUPERH
select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_NMI
select NEED_SG_DMA_LENGTH
- select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
+ select ARCH_HAS_GIGANTIC_PAGE if CONTIG_ALLOC
help
The SuperH is a RISC processor targeted for use in embedded systems
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index ebcc9435db08..52193cfb0f32 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -91,7 +91,7 @@ config SPARC64
select ARCH_CLOCKSOURCE_DATA
select ARCH_HAS_PTE_SPECIAL
select PCI_DOMAINS if PCI
- select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
+ select ARCH_HAS_GIGANTIC_PAGE if CONTIG_ALLOC
config ARCH_DEFCONFIG
string
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c1f9b3cf437c..749bab313dc1 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -21,7 +21,7 @@ config X86_64
def_bool y
depends on 64BIT
# Options that are inherently 64-bit kernel only:
- select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
+ select ARCH_HAS_GIGANTIC_PAGE if CONTIG_ALLOC
select ARCH_SUPPORTS_INT128
select ARCH_USE_CMPXCHG_LOCKREF
select HAVE_ARCH_SOFT_DIRTY
diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
index 92e4c4b85bba..fab095362c50 100644
--- a/arch/x86/mm/hugetlbpage.c
+++ b/arch/x86/mm/hugetlbpage.c
@@ -203,7 +203,7 @@ static __init int setup_hugepagesz(char *opt)
}
__setup("hugepagesz=", setup_hugepagesz);
-#if (defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || defined(CONFIG_CMA)
+#ifdef CONFIG_CONTIG_ALLOC
static __init int gigantic_pages_init(void)
{
/* With compaction or CMA we can allocate gigantic pages at runtime */
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index fdab7de7490d..e77ab30e9328 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -585,7 +585,7 @@ static inline bool pm_suspended_storage(void)
}
#endif /* CONFIG_PM_SLEEP */
-#if (defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || defined(CONFIG_CMA)
+#ifdef CONFIG_CONTIG_ALLOC
/* The below functions must be run on a range from a single zone. */
extern int alloc_contig_range(unsigned long start, unsigned long end,
unsigned migratetype, gfp_t gfp_mask);
diff --git a/mm/Kconfig b/mm/Kconfig
index 25c71eb8a7db..137eadc18732 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -258,6 +258,9 @@ config ARCH_ENABLE_HUGEPAGE_MIGRATION
config ARCH_ENABLE_THP_MIGRATION
bool
+config CONTIG_ALLOC
+ def_bool (MEMORY_ISOLATION && COMPACTION) || CMA
+
config PHYS_ADDR_T_64BIT
def_bool 64BIT
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 03fcf73d47da..ecb115a74a9d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -8109,8 +8109,7 @@ bool has_unmovable_pages(struct zone *zone, struct page *page, int count,
return true;
}
-#if (defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || defined(CONFIG_CMA)
-
+#ifdef CONFIG_CONTIG_ALLOC
static unsigned long pfn_max_align_down(unsigned long pfn)
{
return pfn & ~(max_t(unsigned long, MAX_ORDER_NR_PAGES,
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox