* 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: [PATCH RFC v4 03/21] PCI: Enable bridge's I/O and MEM access for hotplugged devices
From: Sergey Miroshnichenko @ 2019-03-27 17:13 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci, linuxppc-dev, linux
In-Reply-To: <20190326191307.GM24180@google.com>
On 3/26/19 10:13 PM, Bjorn Helgaas wrote:
> On Mon, Mar 11, 2019 at 04:31:04PM +0300, Sergey Miroshnichenko wrote:
>> After updating the bridge window resources, the PCI_COMMAND_IO and
>> PCI_COMMAND_MEMORY bits of the bridge must be addressed as well.
>>
>> Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
>> ---
>> drivers/pci/pci.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index 895201d4c9e6..69898fe5255e 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -1622,6 +1622,14 @@ static void pci_enable_bridge(struct pci_dev *dev)
>> pci_enable_bridge(bridge);
>>
>> if (pci_is_enabled(dev)) {
>> + int i, bars = 0;
>> +
>> + for (i = PCI_BRIDGE_RESOURCES; i < DEVICE_COUNT_RESOURCE; i++) {
>> + if (dev->resource[i].flags & (IORESOURCE_MEM | IORESOURCE_IO))
>> + bars |= (1 << i);
>> + }
>> + do_pci_enable_device(dev, bars);
>
> In what situation is this needed, exactly? This code already exists
> in pci_enable_device_flags(). Why isn't that enough?
>
> I guess maybe there's some case where we enable the bridge, then
> assign bridge windows, then enable a downstream device?
>
> Does this fix a bug with current hotplug?
>
Sure, this change was implemented because of the issue: pci_enable_device_flags() returns
early if the device is already pci_is_enabled(), so if a bridge was already enabled before
the hotplug event, but without MEM and/or IO being set, these bits will not be set even if
a new device wants them.
I've chosen the pci_enable_bridge() for this snippet because it recursively updates all
the parent bridges.
Serge
>> if (!dev->is_busmaster)
>> pci_set_master(dev);
>> mutex_unlock(&dev->enable_mutex);
>> --
>> 2.20.1
>>
^ permalink raw reply
* Re: [PATCH RFC v4 05/21] PCI: hotplug: Add a flag for the movable BARs feature
From: Sergey Miroshnichenko @ 2019-03-27 17:16 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci, linuxppc-dev, linux
In-Reply-To: <20190326192455.GN24180@google.com>
On 3/26/19 10:24 PM, Bjorn Helgaas wrote:
> On Mon, Mar 11, 2019 at 04:31:06PM +0300, Sergey Miroshnichenko wrote:
>> If a new PCIe device has been hot-plugged between the two active ones
>> without big enough gap between their BARs,
>
> Just to speak precisely here, a hot-added device is not "between" two
> active ones because the new device has zeros in its BARs.
>
> BARs from different devices can be interleaved arbitrarily, subject to
> bridge window constraints, so we can really only speak about a *BAR*
> (not the entire device) being between two other BARs.
>
> Also, I don't think there's anything here that is PCIe-specific, so we
> should talk about "PCI", not "PCIe".
>
I agree, that should be rephrased. This patchset intends to solve the problem when a
bridge window is not big enough (or fragmented too much) to fit new BARs, and it can't be
expanded enough because blocked by "neighboring" BARs.
>> these BARs should be moved
>> if their drivers support this feature. The drivers should be notified
>> and paused during the procedure:
>>
>> 1) dev 8 (new)
>> |
>> v
>> .. | dev 3 | dev 3 | dev 5 | dev 7 |
>> .. | BAR 0 | BAR 1 | BAR 0 | BAR 0 |
>>
>> 2) dev 8
>> |
>> v
>> .. | dev 3 | dev 3 | --> --> | dev 5 | dev 7 |
>> .. | BAR 0 | BAR 1 | --> --> | BAR 0 | BAR 0 |
>>
>> 3)
>>
>> .. | dev 3 | dev 3 | dev 8 | dev 8 | dev 5 | dev 7 |
>> .. | BAR 0 | BAR 1 | BAR 0 | BAR 1 | BAR 0 | BAR 0 |
>>
>> Thus, prior reservation of memory regions by BIOS/bootloader/firmware
>> is not required anymore for the PCIe hotplug.
>>
>> The PCI_MOVABLE_BARS flag is set by the platform is this feature is
>> supported and tested, but can be overridden by the following command
>> line option:
>> pcie_movable_bars={ off | force }
>
> A chicken switch to turn this functionality off is OK, but I think it
> should be enabled by default. There isn't anything about this that's
> platform-specific, is there?
>
I'm a bit afraid to suppose that; I was once surprised that bus numbers can't be assigned
arbitrarily on some platforms [1], so probably there are some similar restrictions on BARs
too.
Was going to propose adding pci_add_flags(PCI_MOVABLE_BARS) into arch/.../init.c for
tested platforms, so there will be less upset people with their BARs suddenly broken. But
this logic can be reversed: pci_clear_flags(PCI_MOVABLE_BARS) for platforms where movable
BARs can't work.
Serge
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-September/178103.html
>> Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
>> ---
>> .../admin-guide/kernel-parameters.txt | 7 ++++++
>> drivers/pci/pci.c | 24 +++++++++++++++++++
>> include/linux/pci.h | 2 ++
>> 3 files changed, 33 insertions(+)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 2b8ee90bb644..d40eaf993f80 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -3417,6 +3417,13 @@
>> nomsi Do not use MSI for native PCIe PME signaling (this makes
>> all PCIe root ports use INTx for all services).
>>
>> + pcie_movable_bars=[PCIE]
>> + Override the movable BARs support detection:
>> + off
>> + Disable even if supported by the platform
>> + force
>> + Enable even if not explicitly declared as supported
>> +
>> pcmv= [HW,PCMCIA] BadgePAD 4
>>
>> pd_ignore_unused
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index 69898fe5255e..4dac49a887ec 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -139,6 +139,30 @@ static int __init pcie_port_pm_setup(char *str)
>> }
>> __setup("pcie_port_pm=", pcie_port_pm_setup);
>>
>> +static bool pcie_movable_bars_off;
>> +static bool pcie_movable_bars_force;
>> +static int __init pcie_movable_bars_setup(char *str)
>> +{
>> + if (!strcmp(str, "off"))
>> + pcie_movable_bars_off = true;
>> + else if (!strcmp(str, "force"))
>> + pcie_movable_bars_force = true;
>> + return 1;
>> +}
>> +__setup("pcie_movable_bars=", pcie_movable_bars_setup);
>> +
>> +bool pci_movable_bars_enabled(void)
>> +{
>> + if (pcie_movable_bars_off)
>> + return false;
>> +
>> + if (pcie_movable_bars_force)
>> + return true;
>> +
>> + return pci_has_flag(PCI_MOVABLE_BARS);
>> +}
>> +EXPORT_SYMBOL(pci_movable_bars_enabled);
>> +
>> /* Time to wait after a reset for device to become responsive */
>> #define PCIE_RESET_READY_POLL_MS 60000
>>
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index cb2760a31fe2..cbe661aff9f5 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -866,6 +866,7 @@ enum {
>> PCI_ENABLE_PROC_DOMAINS = 0x00000010, /* Enable domains in /proc */
>> PCI_COMPAT_DOMAIN_0 = 0x00000020, /* ... except domain 0 */
>> PCI_SCAN_ALL_PCIE_DEVS = 0x00000040, /* Scan all, not just dev 0 */
>> + PCI_MOVABLE_BARS = 0x00000080, /* Runtime BAR reassign after hotplug */
>> };
>>
>> /* These external functions are only available when PCI support is enabled */
>> @@ -1345,6 +1346,7 @@ unsigned char pci_bus_max_busnr(struct pci_bus *bus);
>> void pci_setup_bridge(struct pci_bus *bus);
>> resource_size_t pcibios_window_alignment(struct pci_bus *bus,
>> unsigned long type);
>> +bool pci_movable_bars_enabled(void);
>>
>> #define PCI_VGA_STATE_CHANGE_BRIDGE (1 << 0)
>> #define PCI_VGA_STATE_CHANGE_DECODES (1 << 1)
>> --
>> 2.20.1
>>
^ permalink raw reply
* Re: [PATCH RFC v4 08/21] nvme-pci: Handle movable BARs
From: Sergey Miroshnichenko @ 2019-03-27 17:30 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Jens Axboe, Sagi Grimberg, linux-pci, linux-kernel, linux-nvme,
linux, Keith Busch, linuxppc-dev, Christoph Hellwig
In-Reply-To: <20190326202055.GP24180@google.com>
On 3/26/19 11:20 PM, Bjorn Helgaas wrote:
> [+cc Keith, Jens, Christoph, Sagi, linux-nvme, LKML]
>
> On Mon, Mar 11, 2019 at 04:31:09PM +0300, Sergey Miroshnichenko wrote:
>> Hotplugged devices can affect the existing ones by moving their BARs.
>> PCI subsystem will inform the NVME driver about this by invoking
>> reset_prepare()+reset_done(), then iounmap()+ioremap() must be called.
>
> Do you mean the PCI core will invoke ->rescan_prepare() and
> ->rescan_done() (as opposed to *reset*)?
>
Yes, of course, sorry for the confusion!
These are new callbacks, so drivers can explicitly show their support of movable BARs, and
the PCI core can detect if they don't and note that the corresponding BARs can't be moved
for now.
>> Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
>> ---
>> drivers/nvme/host/pci.c | 29 +++++++++++++++++++++++++++--
>> 1 file changed, 27 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
>> index 92bad1c810ac..ccea3033a67a 100644
>> --- a/drivers/nvme/host/pci.c
>> +++ b/drivers/nvme/host/pci.c
>> @@ -106,6 +106,7 @@ struct nvme_dev {
>> unsigned int num_vecs;
>> int q_depth;
>> u32 db_stride;
>> + resource_size_t current_phys_bar;
>> void __iomem *bar;
>> unsigned long bar_mapped_size;
>> struct work_struct remove_work;
>> @@ -1672,13 +1673,16 @@ static int nvme_remap_bar(struct nvme_dev *dev, unsigned long size)
>> {
>> struct pci_dev *pdev = to_pci_dev(dev->dev);
>>
>> - if (size <= dev->bar_mapped_size)
>> + if (dev->bar &&
>> + dev->current_phys_bar == pci_resource_start(pdev, 0) &&
>> + size <= dev->bar_mapped_size)
>> return 0;
>> if (size > pci_resource_len(pdev, 0))
>> return -ENOMEM;
>> if (dev->bar)
>> iounmap(dev->bar);
>> - dev->bar = ioremap(pci_resource_start(pdev, 0), size);
>> + dev->current_phys_bar = pci_resource_start(pdev, 0);
>> + dev->bar = ioremap(dev->current_phys_bar, size);
>
> dev->current_phys_bar is different from pci_resource_start() in the
> case where the PCI core has moved the nvme BAR, but nvme has not yet
> remapped it.
>
> I'm not sure it's worth keeping track of current_phys_bar, as opposed
> to always unmapping and remapping. Is this a performance path? I
> think there are advantages to always exercising the same code path,
> regardless of whether the BAR happened to be moved, e.g., if there's a
> bug in the "BAR moved" path, it may be a heisenbug because whether we
> exercise that path depends on the current configuration.
>
> If you do need to cache current_phys_bar, maybe this, so it's a little
> easier to see that you're not changing the ioremap() itself:
>
> dev->bar = ioremap(pci_resource_start(pdev, 0), size);
> dev->current_phys_bar = pci_resource_start(pdev, 0);
>
Oh, I see now. Rescan is rather a rare event, and unconditional remapping is simpler, so a
bit more resistant to bugs.
>> if (!dev->bar) {
>> dev->bar_mapped_size = 0;
>> return -ENOMEM;
>> @@ -2504,6 +2508,8 @@ static void nvme_reset_work(struct work_struct *work)
>> if (WARN_ON(dev->ctrl.state != NVME_CTRL_RESETTING))
>> goto out;
>>
>> + nvme_remap_bar(dev, db_bar_size(dev, 0));
>
> How is this change connected to rescan? This looks reset-related.
>
Thanks for catching that! This has also slipped form early stage of this pathset, when
reset_done() (which is rescan_done() now) just initiated an NVME reset.
Best regards,
Serge
>> /*
>> * If we're called to reset a live controller first shut it down before
>> * moving on.
>> @@ -2910,6 +2916,23 @@ static void nvme_error_resume(struct pci_dev *pdev)
>> flush_work(&dev->ctrl.reset_work);
>> }
>>
>> +void nvme_rescan_prepare(struct pci_dev *pdev)
>> +{
>> + struct nvme_dev *dev = pci_get_drvdata(pdev);
>> +
>> + nvme_dev_disable(dev, false);
>> + nvme_dev_unmap(dev);
>> + dev->bar = NULL;
>> +}
>> +
>> +void nvme_rescan_done(struct pci_dev *pdev)
>> +{
>> + struct nvme_dev *dev = pci_get_drvdata(pdev);
>> +
>> + nvme_dev_map(dev);
>> + nvme_reset_ctrl_sync(&dev->ctrl);
>> +}
>> +
>> static const struct pci_error_handlers nvme_err_handler = {
>> .error_detected = nvme_error_detected,
>> .slot_reset = nvme_slot_reset,
>> @@ -2974,6 +2997,8 @@ static struct pci_driver nvme_driver = {
>> },
>> .sriov_configure = pci_sriov_configure_simple,
>> .err_handler = &nvme_err_handler,
>> + .rescan_prepare = nvme_rescan_prepare,
>> + .rescan_done = nvme_rescan_done,
>> };
>>
>> static int __init nvme_init(void)
>> --
>> 2.20.1
>>
^ permalink raw reply
* Re: [PATCH RFC v4 09/21] PCI: Mark immovable BARs with PCI_FIXED
From: Sergey Miroshnichenko @ 2019-03-27 17:39 UTC (permalink / raw)
To: David Laight, 'Bjorn Helgaas'
Cc: linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux@yadro.com
In-Reply-To: <3e3e163cbf35446ea575bb7fae1912be@AcuMS.aculab.com>
On 3/27/19 8:03 PM, David Laight wrote:
> From: Bjorn Helgaas
>> Sent: 26 March 2019 20:29
>>
>> On Mon, Mar 11, 2019 at 04:31:10PM +0300, Sergey Miroshnichenko wrote:
>>> If a PCIe device driver doesn't yet have support for movable BARs,
>>> mark device's BARs with IORESOURCE_PCI_FIXED.
>>
>> I'm hesitant about using IORESOURCE_PCI_FIXED for this purpose. That
>> was originally added to describe resources that can not be changed
>> because they're hardwired in the device, e.g., legacy resources and
>> Enhanced Allocation resources.
>>
>> In general, I think the bits in res->flags should tell us things about
>> the hardware. This particular use would be something about the
>> *driver*, and I think we should figure that out by looking at
>> dev->driver.
>
> There will also be drivers that don't support BARs being moved,
> but may be in a state (ie not actually open) where they can go
> through a remove-rescan sequence to allow the BAR be moved.
>
> This might even be true if the open count is non-zero.
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
>
This approach with IORESOURCE_PCI_FIXED was used because struct resource doesn't have a
pointer to its device (and so to its driver). But now, after you have mentioned that, I
can see that in every place I use the FIXED flag to mark the immovable resources - also
has the according struct pci_dev *dev nearby.
So, replacing every
if (r->flags & IORESOURCE_PCI_FIXED)
with
if (!dev->driver->rescan_prepare)
or something like
if (pci_dev_movable_bars_capable(dev))
will reduce this huge patchset a little, and also makes irrelevant the case I've
completely forgotten about - IORESOURCE_PCI_FIXED must be unset on removing (rmmod) the
"immovable" driver.
Thanks a lot! I'll rework the changes in this way and resend it as v5.
Serge
^ permalink raw reply
* Re: [PATCH RFC v4 11/21] PCI: Release and reassign the root bridge resources during rescan
From: Sergey Miroshnichenko @ 2019-03-27 17:40 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci, linuxppc-dev, linux
In-Reply-To: <20190326204102.GS24180@google.com>
On 3/26/19 11:41 PM, Bjorn Helgaas wrote:
> On Mon, Mar 11, 2019 at 04:31:12PM +0300, Sergey Miroshnichenko wrote:
>> When the movable BARs feature is enabled, don't rely on the memory gaps
>> reserved by the BIOS/bootloader/firmware, but instead rearrange the BARs
>> and bridge windows starting from the root.
>>
>> Endpoint device's BARs, after being released, are resorted and written
>> back by the pci_assign_unassigned_root_bus_resources().
>>
>> The last step of writing the recalculated windows to the bridges is done
>> by the new pci_setup_bridges() function.
>>
>> Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
>> ---
>> drivers/pci/pci.h | 1 +
>> drivers/pci/probe.c | 22 ++++++++++++++++++++++
>> drivers/pci/setup-bus.c | 11 ++++++++++-
>> 3 files changed, 33 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
>> index 224d88634115..e06e8692a7b1 100644
>> --- a/drivers/pci/pci.h
>> +++ b/drivers/pci/pci.h
>> @@ -248,6 +248,7 @@ void __pci_bus_assign_resources(const struct pci_bus *bus,
>> struct list_head *realloc_head,
>> struct list_head *fail_head);
>> bool pci_bus_clip_resource(struct pci_dev *dev, int idx);
>> +void pci_bus_release_root_bridge_resources(struct pci_bus *bus);
>>
>> void pci_reassigndev_resource_alignment(struct pci_dev *dev);
>> void pci_disable_bridge_window(struct pci_dev *dev);
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 1cf6ec960236..692752c71f71 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -3299,6 +3299,25 @@ static void pci_bus_rescan_done(struct pci_bus *bus)
>> pm_runtime_put(&bus->dev);
>> }
>>
>> +static void pci_setup_bridges(struct pci_bus *bus)
>> +{
>> + struct pci_dev *dev;
>> +
>> + list_for_each_entry(dev, &bus->devices, bus_list) {
>> + struct pci_bus *child;
>> +
>> + if (!pci_dev_is_added(dev) || pci_dev_is_ignored(dev))
>> + continue;
>> +
>> + child = dev->subordinate;
>> + if (child)
>> + pci_setup_bridges(child);
>> + }
>> +
>> + if (bus->self)
>> + pci_setup_bridge(bus);
>> +}
>> +
>> /**
>> * pci_rescan_bus - Scan a PCI bus for devices
>> * @bus: PCI bus to scan
>> @@ -3321,8 +3340,11 @@ unsigned int pci_rescan_bus(struct pci_bus *bus)
>> pci_bus_rescan_prepare(root);
>>
>> max = pci_scan_child_bus(root);
>> +
>> + pci_bus_release_root_bridge_resources(root);
>> pci_assign_unassigned_root_bus_resources(root);
>>
>> + pci_setup_bridges(root);
>> pci_bus_rescan_done(root);
>> } else {
>> max = pci_scan_child_bus(bus);
>> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
>> index be7d4e6d7b65..36a1907d9509 100644
>> --- a/drivers/pci/setup-bus.c
>> +++ b/drivers/pci/setup-bus.c
>> @@ -1584,7 +1584,7 @@ static void pci_bridge_release_resources(struct pci_bus *bus,
>> pci_printk(KERN_DEBUG, dev, "resource %d %pR released\n",
>> PCI_BRIDGE_RESOURCES + idx, r);
>> /* keep the old size */
>> - r->end = resource_size(r) - 1;
>> + r->end = pci_movable_bars_enabled() ? 0 : (resource_size(r) - 1);
>
> Doesn't this mean we're throwing away the information about the BAR
> size, and we'll have to size the BAR again somewhere? I would like to
> avoid that. But I don't know yet where you rely on this, so maybe
> it's not possible to avoid it.
>
This resource is not a BAR, but a bridge window, I'm freeing it intentionally, so
pbus_size_mem() can later recalculate a new size.
Serge
>> r->start = 0;
>> r->flags = 0;
>>
>> @@ -1637,6 +1637,15 @@ static void pci_bus_release_bridge_resources(struct pci_bus *bus,
>> pci_bridge_release_resources(bus, type);
>> }
>>
>> +void pci_bus_release_root_bridge_resources(struct pci_bus *root_bus)
>> +{
>> + pci_bus_release_bridge_resources(root_bus, IORESOURCE_IO, whole_subtree);
>> + pci_bus_release_bridge_resources(root_bus, IORESOURCE_MEM, whole_subtree);
>> + pci_bus_release_bridge_resources(root_bus,
>> + IORESOURCE_MEM_64 | IORESOURCE_PREFETCH,
>> + whole_subtree);
>> +}
>> +
>> static void pci_bus_dump_res(struct pci_bus *bus)
>> {
>> struct resource *res;
>> --
>> 2.20.1
>>
^ permalink raw reply
* Re: [PATCH RFC v4 12/21] PCI: Don't allow hotplugged devices to steal resources
From: Sergey Miroshnichenko @ 2019-03-27 18:02 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci, linuxppc-dev, linux
In-Reply-To: <20190326205533.GT24180@google.com>
On 3/26/19 11:55 PM, Bjorn Helgaas wrote:
> On Mon, Mar 11, 2019 at 04:31:13PM +0300, Sergey Miroshnichenko wrote:
>> When movable BARs are enabled, the PCI subsystem at first releases
>> all the bridge windows and then performs an attempt to assign new
>> requested resources and re-assign the existing ones.
>
> s/performs an attempt/attempts/
>
> I guess "new requested resources" means "resources to newly hotplugged
> devices"?
>
Yes, that's exactly what I've tried to express :) Will rephrase that in v5.
>> If a hotplugged device gets its resources first, there could be no
>> space left to re-assign resources of already working devices, which
>> is unacceptable. If this happens, this patch marks one of the new
>> devices with the new introduced flag PCI_DEV_IGNORE and retries the
>> resource assignment.
>>
>> This patch adds a new res_mask bitmask to the struct pci_dev for
>> storing the indices of assigned resources.
>>
>> Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
>> ---
>> drivers/pci/bus.c | 5 ++
>> drivers/pci/pci.h | 11 +++++
>> drivers/pci/probe.c | 100 +++++++++++++++++++++++++++++++++++++++-
>> drivers/pci/setup-bus.c | 15 ++++++
>> include/linux/pci.h | 1 +
>> 5 files changed, 130 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
>> index 5cb40b2518f9..a9784144d6f2 100644
>> --- a/drivers/pci/bus.c
>> +++ b/drivers/pci/bus.c
>> @@ -311,6 +311,11 @@ void pci_bus_add_device(struct pci_dev *dev)
>> {
>> int retval;
>>
>> + if (pci_dev_is_ignored(dev)) {
>> + pci_warn(dev, "%s: don't enable the ignored device\n", __func__);
>> + return;
>
> I'm not sure about this. Even if we're unable to assign space for all
> the device's BARs, it still should respond to config accesses, and I
> think it should show up in sysfs and lspci.
>
I agree, that would be better.
Also, this patch introduces a new issue to think about: how to recover BARs for such
devices when their neighbors was removed and it's enough space now.
>> + }
>> +
>> /*
>> * Can not put in pci_device_add yet because resources
>> * are not assigned yet for some devices.
>> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
>> index e06e8692a7b1..56b905068ac5 100644
>> --- a/drivers/pci/pci.h
>> +++ b/drivers/pci/pci.h
>> @@ -366,6 +366,7 @@ static inline bool pci_dev_is_disconnected(const struct pci_dev *dev)
>>
>> /* pci_dev priv_flags */
>> #define PCI_DEV_ADDED 0
>> +#define PCI_DEV_IGNORE 1
>>
>> static inline void pci_dev_assign_added(struct pci_dev *dev, bool added)
>> {
>> @@ -377,6 +378,16 @@ static inline bool pci_dev_is_added(const struct pci_dev *dev)
>> return test_bit(PCI_DEV_ADDED, &dev->priv_flags);
>> }
>>
>> +static inline void pci_dev_ignore(struct pci_dev *dev, bool ignore)
>> +{
>> + assign_bit(PCI_DEV_IGNORE, &dev->priv_flags, ignore);
>> +}
>> +
>> +static inline bool pci_dev_is_ignored(const struct pci_dev *dev)
>> +{
>> + return test_bit(PCI_DEV_IGNORE, &dev->priv_flags);
>> +}
>> +
>> #ifdef CONFIG_PCIEAER
>> #include <linux/aer.h>
>>
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 692752c71f71..62f4058a001f 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -3248,6 +3248,23 @@ unsigned int pci_rescan_bus_bridge_resize(struct pci_dev *bridge)
>> return max;
>> }
>>
>> +static unsigned int pci_dev_res_mask(struct pci_dev *dev)
>> +{
>> + unsigned int res_mask = 0;
>> + int i;
>> +
>> + for (i = 0; i < PCI_BRIDGE_RESOURCES; i++) {
>> + struct resource *r = &dev->resource[i];
>> +
>> + if (!r->flags || (r->flags & IORESOURCE_UNSET) || !r->parent)
>> + continue;
>> +
>> + res_mask |= (1 << i);
>> + }
>> +
>> + return res_mask;
>> +}
>> +
>> static void pci_bus_rescan_prepare(struct pci_bus *bus)
>> {
>> struct pci_dev *dev;
>> @@ -3257,6 +3274,8 @@ static void pci_bus_rescan_prepare(struct pci_bus *bus)
>> list_for_each_entry(dev, &bus->devices, bus_list) {
>> struct pci_bus *child = dev->subordinate;
>>
>> + dev->res_mask = pci_dev_res_mask(dev);
>> +
>> if (child) {
>> pci_bus_rescan_prepare(child);
>> } else if (dev->driver &&
>> @@ -3318,6 +3337,84 @@ static void pci_setup_bridges(struct pci_bus *bus)
>> pci_setup_bridge(bus);
>> }
>>
>> +static struct pci_dev *pci_find_next_new_device(struct pci_bus *bus)
>> +{
>> + struct pci_dev *dev;
>> +
>> + if (!bus)
>> + return NULL;
>> +
>> + list_for_each_entry(dev, &bus->devices, bus_list) {
>> + struct pci_bus *child_bus = dev->subordinate;
>> +
>> + if (!pci_dev_is_added(dev) && !pci_dev_is_ignored(dev))
>> + return dev;
>> +
>> + if (child_bus) {
>> + struct pci_dev *next_new_dev;
>> +
>> + next_new_dev = pci_find_next_new_device(child_bus);
>> + if (next_new_dev)
>> + return next_new_dev;
>> + }
>> + }
>> +
>> + return NULL;
>> +}
>> +
>> +static bool pci_bus_validate_resources(struct pci_bus *bus)
>
> The name of this function should tell us what the return value means.
> Just from the name "pci_bus_validate_resources", I can't tell whether we
> call it for side-effects, or whether true or false indicates success.
>
Sure, now I realize this too. Would the pci_bus_check_all_bars_reassigned() be better choice?
>> +{
>> + struct pci_dev *dev;
>> + bool ret = true;
>> +
>> + if (!bus)
>> + return false;
>> +
>> + list_for_each_entry(dev, &bus->devices, bus_list) {
>> + struct pci_bus *child = dev->subordinate;
>> + unsigned int res_mask = pci_dev_res_mask(dev);
>> +
>> + if (pci_dev_is_ignored(dev))
>> + continue;
>> +
>> + if (dev->res_mask & ~res_mask) {
>> + pci_err(dev, "%s: Non-re-enabled resources found: 0x%x -> 0x%x\n",
>> + __func__, dev->res_mask, res_mask);
>
> I don't think __func__ really tells users anything useful, so I would
> just omit them. Searching for the text of the message is almost as
> good.
>
Ok, I'll drop __func__'s.
Serge
>> + ret = false;
>> + }
>> +
>> + if (child && !pci_bus_validate_resources(child))
>> + ret = false;
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static void pci_reassign_root_bus_resources(struct pci_bus *root)
>> +{
>> + do {
>> + struct pci_dev *next_new_dev;
>> +
>> + pci_bus_release_root_bridge_resources(root);
>> + pci_assign_unassigned_root_bus_resources(root);
>> +
>> + if (pci_bus_validate_resources(root))
>> + break;
>> +
>> + next_new_dev = pci_find_next_new_device(root);
>> + if (!next_new_dev) {
>> + dev_err(&root->dev, "%s: failed to re-assign resources even after ignoring all the hotplugged devices\n",
>> + __func__);
>> + break;
>> + }
>> +
>> + dev_warn(&root->dev, "%s: failed to re-assign resources, disable the next hotplugged device %s and retry\n",
>> + __func__, dev_name(&next_new_dev->dev));
>> +
>> + pci_dev_ignore(next_new_dev, true);
>> + } while (true);
>> +}
>> +
>> /**
>> * pci_rescan_bus - Scan a PCI bus for devices
>> * @bus: PCI bus to scan
>> @@ -3341,8 +3438,7 @@ unsigned int pci_rescan_bus(struct pci_bus *bus)
>>
>> max = pci_scan_child_bus(root);
>>
>> - pci_bus_release_root_bridge_resources(root);
>> - pci_assign_unassigned_root_bus_resources(root);
>> + pci_reassign_root_bus_resources(root);
>>
>> pci_setup_bridges(root);
>> pci_bus_rescan_done(root);
>> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
>> index 36a1907d9509..551108f48df7 100644
>> --- a/drivers/pci/setup-bus.c
>> +++ b/drivers/pci/setup-bus.c
>> @@ -131,6 +131,9 @@ static void pdev_sort_resources(struct pci_dev *dev, struct list_head *head)
>> {
>> int i;
>>
>> + if (pci_dev_is_ignored(dev))
>> + return;
>> +
>> for (i = 0; i < PCI_NUM_RESOURCES; i++) {
>> struct resource *r;
>> struct pci_dev_resource *dev_res, *tmp;
>> @@ -181,6 +184,9 @@ static void __dev_sort_resources(struct pci_dev *dev,
>> {
>> u16 class = dev->class >> 8;
>>
>> + if (pci_dev_is_ignored(dev))
>> + return;
>> +
>> /* Don't touch classless devices or host bridges or ioapics. */
>> if (class == PCI_CLASS_NOT_DEFINED || class == PCI_CLASS_BRIDGE_HOST)
>> return;
>> @@ -284,6 +290,9 @@ static void assign_requested_resources_sorted(struct list_head *head,
>> int idx;
>>
>> list_for_each_entry(dev_res, head, list) {
>> + if (pci_dev_is_ignored(dev_res->dev))
>> + continue;
>> +
>> res = dev_res->res;
>> idx = res - &dev_res->dev->resource[0];
>> if (resource_size(res) &&
>> @@ -991,6 +1000,9 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask,
>> list_for_each_entry(dev, &bus->devices, bus_list) {
>> int i;
>>
>> + if (pci_dev_is_ignored(dev))
>> + continue;
>> +
>> for (i = 0; i < PCI_NUM_RESOURCES; i++) {
>> struct resource *r = &dev->resource[i];
>> resource_size_t r_size;
>> @@ -1353,6 +1365,9 @@ void __pci_bus_assign_resources(const struct pci_bus *bus,
>> pbus_assign_resources_sorted(bus, realloc_head, fail_head);
>>
>> list_for_each_entry(dev, &bus->devices, bus_list) {
>> + if (pci_dev_is_ignored(dev))
>> + continue;
>> +
>> pdev_assign_fixed_resources(dev);
>>
>> b = dev->subordinate;
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index 3d52f5538282..26aa59cb6220 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -369,6 +369,7 @@ struct pci_dev {
>> */
>> unsigned int irq;
>> struct resource resource[DEVICE_COUNT_RESOURCE]; /* I/O and memory regions + expansion ROMs */
>> + unsigned int res_mask; /* Bitmask of assigned resources */
>>
>> bool match_driver; /* Skip attaching driver */
>>
>> --
>> 2.20.1
>>
^ permalink raw reply
* [PATCH AUTOSEL 5.0 015/262] memblock: memblock_phys_alloc_try_nid(): don't panic
From: Sasha Levin @ 2019-03-27 17:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Rich Felker, Petr Mladek, Catalin Marinas, Heiko Carstens,
Max Filippov, Guo Ren, Christoph Hellwig, Sasha Levin,
Rob Herring, Yoshinori Sato, Richard Weinberger, Russell King,
Mike Rapoport, Geert Uytterhoeven, Guo Ren, Mark Salter,
Dennis Zhou, Matt Turner, Juergen Gross, linuxppc-dev,
Rob Herring, Greentime Hu, Stafford Horne, Guan Xuetao,
Michal Simek, Tony Luck, linux-mm, Greg Kroah-Hartman,
Paul Burton, Vineet Gupta, Andrew Morton, Linus Torvalds,
David S. Miller
In-Reply-To: <20190327180158.10245-1-sashal@kernel.org>
From: Mike Rapoport <rppt@linux.ibm.com>
[ Upstream commit 337555744e6e39dd1d87698c6084dd88a606d60a ]
The memblock_phys_alloc_try_nid() function tries to allocate memory from
the requested node and then falls back to allocation from any node in
the system. The memblock_alloc_base() fallback used by this function
panics if the allocation fails.
Replace the memblock_alloc_base() fallback with the direct call to
memblock_alloc_range_nid() and update the memblock_phys_alloc_try_nid()
callers to check the returned value and panic in case of error.
Link: http://lkml.kernel.org/r/1548057848-15136-7-git-send-email-rppt@linux.ibm.com
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> [powerpc]
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Christoph Hellwig <hch@lst.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Dennis Zhou <dennis@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Greentime Hu <green.hu@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Guan Xuetao <gxt@pku.edu.cn>
Cc: Guo Ren <guoren@kernel.org>
Cc: Guo Ren <ren_guo@c-sky.com> [c-sky]
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Juergen Gross <jgross@suse.com> [Xen]
Cc: Mark Salter <msalter@redhat.com>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Paul Burton <paul.burton@mips.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Rich Felker <dalias@libc.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Stafford Horne <shorne@gmail.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/mm/numa.c | 4 ++++
arch/powerpc/mm/numa.c | 4 ++++
mm/memblock.c | 4 +++-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index ae34e3a1cef1..2c61ea4e290b 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -237,6 +237,10 @@ static void __init setup_node_data(int nid, u64 start_pfn, u64 end_pfn)
pr_info("Initmem setup node %d [<memory-less node>]\n", nid);
nd_pa = memblock_phys_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
+ if (!nd_pa)
+ panic("Cannot allocate %zu bytes for node %d data\n",
+ nd_size, nid);
+
nd = __va(nd_pa);
/* report and initialize */
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 87f0dd004295..8ec2ed30d44c 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -788,6 +788,10 @@ static void __init setup_node_data(int nid, u64 start_pfn, u64 end_pfn)
int tnid;
nd_pa = memblock_phys_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
+ if (!nd_pa)
+ panic("Cannot allocate %zu bytes for node %d data\n",
+ nd_size, nid);
+
nd = __va(nd_pa);
/* report and initialize */
diff --git a/mm/memblock.c b/mm/memblock.c
index ea31045ba704..d5923df56acc 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1342,7 +1342,9 @@ phys_addr_t __init memblock_phys_alloc_try_nid(phys_addr_t size, phys_addr_t ali
if (res)
return res;
- return memblock_alloc_base(size, align, MEMBLOCK_ALLOC_ACCESSIBLE);
+ return memblock_alloc_range_nid(size, align, 0,
+ MEMBLOCK_ALLOC_ACCESSIBLE,
+ NUMA_NO_NODE, MEMBLOCK_NONE);
}
/**
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 061/262] mm/resource: Return real error codes from walk failures
From: Sasha Levin @ 2019-03-27 17:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Tom Lendacky, Michal Hocko, Dave Jiang, linux-nvdimm,
Takashi Iwai, Vishal Verma, Dave Hansen, Huang Ying, Keith Busch,
linux-mm, Jerome Glisse, Borislav Petkov, Yaowei Bai,
Ross Zwisler, Paul Mackerras, Dan Williams, Fengguang Wu,
linuxppc-dev, Andrew Morton
In-Reply-To: <20190327180158.10245-1-sashal@kernel.org>
From: Dave Hansen <dave.hansen@linux.intel.com>
[ Upstream commit 5cd401ace914dc68556c6d2fcae0c349444d5f86 ]
walk_system_ram_range() can return an error code either becuase
*it* failed, or because the 'func' that it calls returned an
error. The memory hotplug does the following:
ret = walk_system_ram_range(..., func);
if (ret)
return ret;
and 'ret' makes it out to userspace, eventually. The problem
s, walk_system_ram_range() failues that result from *it* failing
(as opposed to 'func') return -1. That leads to a very odd
-EPERM (-1) return code out to userspace.
Make walk_system_ram_range() return -EINVAL for internal
failures to keep userspace less confused.
This return code is compatible with all the callers that I
audited.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ross Zwisler <zwisler@kernel.org>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: linux-nvdimm@lists.01.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: Huang Ying <ying.huang@intel.com>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Keith Busch <keith.busch@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/resource.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/resource.c b/kernel/resource.c
index 915c02e8e5dd..ca7ed5158cff 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -382,7 +382,7 @@ static int __walk_iomem_res_desc(resource_size_t start, resource_size_t end,
int (*func)(struct resource *, void *))
{
struct resource res;
- int ret = -1;
+ int ret = -EINVAL;
while (start < end &&
!find_next_iomem_res(start, end, flags, desc, first_lvl, &res)) {
@@ -462,7 +462,7 @@ int walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
unsigned long flags;
struct resource res;
unsigned long pfn, end_pfn;
- int ret = -1;
+ int ret = -EINVAL;
start = (u64) start_pfn << PAGE_SHIFT;
end = ((u64)(start_pfn + nr_pages) << PAGE_SHIFT) - 1;
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 072/262] powerpc/powernv/ioda: Fix locked_vm counting for memory used by IOMMU tables
From: Sasha Levin @ 2019-03-27 17:58 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Alexey Kardashevskiy, linuxppc-dev, Sasha Levin
In-Reply-To: <20190327180158.10245-1-sashal@kernel.org>
From: Alexey Kardashevskiy <aik@ozlabs.ru>
[ Upstream commit 11f5acce2fa43b015a8120fa7620fa4efd0a2952 ]
We store 2 multilevel tables in iommu_table - one for the hardware and
one with the corresponding userspace addresses. Before allocating
the tables, the iommu_table_group_ops::get_table_size() hook returns
the combined size of the two and VFIO SPAPR TCE IOMMU driver adjusts
the locked_vm counter correctly. When the table is actually allocated,
the amount of allocated memory is stored in iommu_table::it_allocated_size
and used to decrement the locked_vm counter when we release the memory
used by the table; .get_table_size() and .create_table() calculate it
independently but the result is expected to be the same.
However the allocator does not add the userspace table size to
.it_allocated_size so when we destroy the table because of VFIO PCI
unplug (i.e. VFIO container is gone but the userspace keeps running),
we decrement locked_vm by just a half of size of memory we are
releasing.
To make things worse, since we enabled on-demand allocation of
indirect levels, it_allocated_size contains only the amount of memory
actually allocated at the table creation time which can just be a
fraction. It is not a problem with incrementing locked_vm (as
get_table_size() value is used) but it is with decrementing.
As the result, we leak locked_vm and may not be able to allocate more
IOMMU tables after few iterations of hotplug/unplug.
This sets it_allocated_size in the pnv_pci_ioda2_ops::create_table()
hook to what pnv_pci_ioda2_get_table_size() returns so from now on we
have a single place which calculates the maximum memory a table can
occupy. The original meaning of it_allocated_size is somewhat lost now
though.
We do not ditch it_allocated_size whatsoever here and we do not call
get_table_size() from vfio_iommu_spapr_tce.c when decrementing
locked_vm as we may have multiple IOMMU groups per container and even
though they all are supposed to have the same get_table_size()
implementation, there is a small chance for failure or confusion.
Fixes: 090bad39b237 ("powerpc/powernv: Add indirect levels to it_userspace")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/platforms/powernv/pci-ioda-tce.c | 1 -
arch/powerpc/platforms/powernv/pci-ioda.c | 7 ++++++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda-tce.c b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
index 697449afb3f7..e28f03e1eb5e 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda-tce.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
@@ -313,7 +313,6 @@ long pnv_pci_ioda2_table_alloc_pages(int nid, __u64 bus_offset,
page_shift);
tbl->it_level_size = 1ULL << (level_shift - 3);
tbl->it_indirect_levels = levels - 1;
- tbl->it_allocated_size = total_allocated;
tbl->it_userspace = uas;
tbl->it_nid = nid;
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 145373f0e5dc..2d62c58f9a4c 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -2594,8 +2594,13 @@ static long pnv_pci_ioda2_create_table_userspace(
int num, __u32 page_shift, __u64 window_size, __u32 levels,
struct iommu_table **ptbl)
{
- return pnv_pci_ioda2_create_table(table_group,
+ long ret = pnv_pci_ioda2_create_table(table_group,
num, page_shift, window_size, levels, true, ptbl);
+
+ if (!ret)
+ (*ptbl)->it_allocated_size = pnv_pci_ioda2_get_table_size(
+ page_shift, window_size, levels);
+ return ret;
}
static void pnv_ioda2_take_ownership(struct iommu_table_group *table_group)
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 076/262] powerpc/fsl: Fix the flush of branch predictor.
From: Sasha Levin @ 2019-03-27 17:58 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Diana Craciun, linuxppc-dev, Sasha Levin
In-Reply-To: <20190327180158.10245-1-sashal@kernel.org>
From: Christophe Leroy <christophe.leroy@c-s.fr>
[ Upstream commit 27da80719ef132cf8c80eb406d5aeb37dddf78cc ]
The commit identified below adds MC_BTB_FLUSH macro only when
CONFIG_PPC_FSL_BOOK3E is defined. This results in the following error
on some configs (seen several times with kisskb randconfig_defconfig)
arch/powerpc/kernel/exceptions-64e.S:576: Error: Unrecognized opcode: `mc_btb_flush'
make[3]: *** [scripts/Makefile.build:367: arch/powerpc/kernel/exceptions-64e.o] Error 1
make[2]: *** [scripts/Makefile.build:492: arch/powerpc/kernel] Error 2
make[1]: *** [Makefile:1043: arch/powerpc] Error 2
make: *** [Makefile:152: sub-make] Error 2
This patch adds a blank definition of MC_BTB_FLUSH for other cases.
Fixes: 10c5e83afd4a ("powerpc/fsl: Flush the branch predictor at each kernel entry (64bit)")
Cc: Diana Craciun <diana.craciun@nxp.com>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Reviewed-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Diana Craciun <diana.craciun@nxp.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kernel/exceptions-64e.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index afb638778f44..447defdd4503 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -349,6 +349,7 @@ ret_from_mc_except:
#define GEN_BTB_FLUSH
#define CRIT_BTB_FLUSH
#define DBG_BTB_FLUSH
+#define MC_BTB_FLUSH
#define GDBELL_BTB_FLUSH
#endif
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 080/262] powerpc/xmon: Fix opcode being uninitialized in print_insn_powerpc
From: Sasha Levin @ 2019-03-27 17:58 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, Nathan Chancellor, linuxppc-dev
In-Reply-To: <20190327180158.10245-1-sashal@kernel.org>
From: Nathan Chancellor <natechancellor@gmail.com>
[ Upstream commit e7140639b1de65bba435a6bd772d134901141f86 ]
When building with -Wsometimes-uninitialized, Clang warns:
arch/powerpc/xmon/ppc-dis.c:157:7: warning: variable 'opcode' is used
uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]
if (cpu_has_feature(CPU_FTRS_POWER9))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/xmon/ppc-dis.c:167:7: note: uninitialized use occurs here
if (opcode == NULL)
^~~~~~
arch/powerpc/xmon/ppc-dis.c:157:3: note: remove the 'if' if its
condition is always true
if (cpu_has_feature(CPU_FTRS_POWER9))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/xmon/ppc-dis.c:132:38: note: initialize the variable
'opcode' to silence this warning
const struct powerpc_opcode *opcode;
^
= NULL
1 warning generated.
This warning seems to make no sense on the surface because opcode is set
to NULL right below this statement. However, there is a comma instead of
semicolon to end the dialect assignment, meaning that the opcode
assignment only happens in the if statement. Properly terminate that
line so that Clang no longer warns.
Fixes: 5b102782c7f4 ("powerpc/xmon: Enable disassembly files (compilation changes)")
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/xmon/ppc-dis.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/xmon/ppc-dis.c b/arch/powerpc/xmon/ppc-dis.c
index 9deea5ee13f6..27f1e6415036 100644
--- a/arch/powerpc/xmon/ppc-dis.c
+++ b/arch/powerpc/xmon/ppc-dis.c
@@ -158,7 +158,7 @@ int print_insn_powerpc (unsigned long insn, unsigned long memaddr)
dialect |= (PPC_OPCODE_POWER5 | PPC_OPCODE_POWER6 | PPC_OPCODE_POWER7
| PPC_OPCODE_POWER8 | PPC_OPCODE_POWER9 | PPC_OPCODE_HTM
| PPC_OPCODE_ALTIVEC | PPC_OPCODE_ALTIVEC2
- | PPC_OPCODE_VSX | PPC_OPCODE_VSX3),
+ | PPC_OPCODE_VSX | PPC_OPCODE_VSX3);
/* Get the major opcode of the insn. */
opcode = NULL;
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 086/262] powerpc/hugetlb: Handle mmap_min_addr correctly in get_unmapped_area callback
From: Sasha Levin @ 2019-03-27 17:59 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20190327180158.10245-1-sashal@kernel.org>
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
[ Upstream commit 5330367fa300742a97e20e953b1f77f48392faae ]
After we ALIGN up the address we need to make sure we didn't overflow
and resulted in zero address. In that case, we need to make sure that
the returned address is greater than mmap_min_addr.
This fixes selftest va_128TBswitch --run-hugetlb reporting failures when
run as non root user for
mmap(-1, MAP_HUGETLB)
The bug is that a non-root user requesting address -1 will be given address 0
which will then fail, whereas they should have been given something else that
would have succeeded.
We also avoid the first mmap(-1, MAP_HUGETLB) returning NULL address as mmap address
with this change. So we think this is not a security issue, because it only affects
whether we choose an address below mmap_min_addr, not whether we
actually allow that address to be mapped. ie. there are existing capability
checks to prevent a user mapping below mmap_min_addr and those will still be
honoured even without this fix.
Fixes: 484837601d4d ("powerpc/mm: Add radix support for hugetlb")
Reviewed-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/mm/hugetlbpage-radix.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage-radix.c b/arch/powerpc/mm/hugetlbpage-radix.c
index 2486bee0f93e..97c7a39ebc00 100644
--- a/arch/powerpc/mm/hugetlbpage-radix.c
+++ b/arch/powerpc/mm/hugetlbpage-radix.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
#include <linux/mm.h>
#include <linux/hugetlb.h>
+#include <linux/security.h>
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
#include <asm/cacheflush.h>
@@ -73,7 +74,7 @@ radix__hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
if (addr) {
addr = ALIGN(addr, huge_page_size(h));
vma = find_vma(mm, addr);
- if (high_limit - len >= addr &&
+ if (high_limit - len >= addr && addr >= mmap_min_addr &&
(!vma || addr + len <= vm_start_gap(vma)))
return addr;
}
@@ -83,7 +84,7 @@ radix__hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
*/
info.flags = VM_UNMAPPED_AREA_TOPDOWN;
info.length = len;
- info.low_limit = PAGE_SIZE;
+ info.low_limit = max(PAGE_SIZE, mmap_min_addr);
info.high_limit = mm->mmap_base + (high_limit - DEFAULT_MAP_WINDOW);
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 106/262] powerpc/44x: Force PCI on for CURRITUCK
From: Sasha Levin @ 2019-03-27 17:59 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev
In-Reply-To: <20190327180158.10245-1-sashal@kernel.org>
From: Michael Ellerman <mpe@ellerman.id.au>
[ Upstream commit aa7150ba378650d0e9d84b8e4d805946965a5926 ]
The recent rework of PCI kconfig symbols exposed an existing bug in
the CURRITUCK kconfig logic.
It selects PPC4xx_PCI_EXPRESS which depends on PCI, but PCI is user
selectable and might be disabled, leading to a warning:
WARNING: unmet direct dependencies detected for PPC4xx_PCI_EXPRESS
Depends on [n]: PCI [=n] && 4xx [=y]
Selected by [y]:
- CURRITUCK [=y] && PPC_47x [=y]
Prior to commit eb01d42a7778 ("PCI: consolidate PCI config entry in
drivers/pci") PCI was enabled by default for currituck_defconfig so we
didn't see the warning. The bad logic was still there, it just
required someone disabling PCI in their .config to hit it.
Fix it by forcing PCI on for CURRITUCK, which seems was always the
expectation anyway.
Fixes: eb01d42a7778 ("PCI: consolidate PCI config entry in drivers/pci")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/platforms/44x/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 4a9a72d01c3c..35be81fd2dc2 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -180,6 +180,7 @@ config CURRITUCK
depends on PPC_47x
select SWIOTLB
select 476FPE
+ select FORCE_PCI
select PPC4xx_PCI_EXPRESS
help
This option enables support for the IBM Currituck (476fpe) evaluation board
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 118/262] SoC: imx-sgtl5000: add missing put_device()
From: Sasha Levin @ 2019-03-27 17:59 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li,
Wen Yang, Sascha Hauer, Takashi Iwai, Liam Girdwood,
Jaroslav Kysela, Nicolin Chen, Mark Brown, NXP Linux Team,
Pengutronix Kernel Team, Shawn Guo, Fabio Estevam,
linux-arm-kernel
In-Reply-To: <20190327180158.10245-1-sashal@kernel.org>
From: Wen Yang <yellowriver2010@hotmail.com>
[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
Signed-off-by: Wen Yang <yellowriver2010@hotmail.com>
Cc: Timur Tabi <timur@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/fsl/imx-sgtl5000.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index c29200cf755a..9b9a7ec52905 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -108,6 +108,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev)
ret = -EPROBE_DEFER;
goto fail;
}
+ put_device(&ssi_pdev->dev);
codec_dev = of_find_i2c_device_by_node(codec_np);
if (!codec_dev) {
dev_err(&pdev->dev, "failed to find codec platform device\n");
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 174/262] powerpc/ptrace: Mitigate potential Spectre v1
From: Sasha Levin @ 2019-03-27 18:00 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Breno Leitao, linuxppc-dev, Sasha Levin
In-Reply-To: <20190327180158.10245-1-sashal@kernel.org>
From: Breno Leitao <leitao@debian.org>
[ Upstream commit ebb0e13ead2ddc186a80b1b0235deeefc5a1a667 ]
'regno' is directly controlled by user space, hence leading to a potential
exploitation of the Spectre variant 1 vulnerability.
On PTRACE_SETREGS and PTRACE_GETREGS requests, user space passes the
register number that would be read or written. This register number is
called 'regno' which is part of the 'addr' syscall parameter.
This 'regno' value is checked against the maximum pt_regs structure size,
and then used to dereference it, which matches the initial part of a
Spectre v1 (and Spectre v1.1) attack. The dereferenced value, then,
is returned to userspace in the GETREGS case.
This patch sanitizes 'regno' before using it to dereference pt_reg.
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
Signed-off-by: Breno Leitao <leitao@debian.org>
Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kernel/ptrace.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 53151698bfe0..d9ac7d94656e 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -33,6 +33,7 @@
#include <linux/hw_breakpoint.h>
#include <linux/perf_event.h>
#include <linux/context_tracking.h>
+#include <linux/nospec.h>
#include <linux/uaccess.h>
#include <linux/pkeys.h>
@@ -274,6 +275,8 @@ static int set_user_trap(struct task_struct *task, unsigned long trap)
*/
int ptrace_get_reg(struct task_struct *task, int regno, unsigned long *data)
{
+ unsigned int regs_max;
+
if ((task->thread.regs == NULL) || !data)
return -EIO;
@@ -297,7 +300,9 @@ int ptrace_get_reg(struct task_struct *task, int regno, unsigned long *data)
}
#endif
- if (regno < (sizeof(struct user_pt_regs) / sizeof(unsigned long))) {
+ regs_max = sizeof(struct user_pt_regs) / sizeof(unsigned long);
+ if (regno < regs_max) {
+ regno = array_index_nospec(regno, regs_max);
*data = ((unsigned long *)task->thread.regs)[regno];
return 0;
}
@@ -321,6 +326,7 @@ int ptrace_put_reg(struct task_struct *task, int regno, unsigned long data)
return set_user_dscr(task, data);
if (regno <= PT_MAX_PUT_REG) {
+ regno = array_index_nospec(regno, PT_MAX_PUT_REG + 1);
((unsigned long *)task->thread.regs)[regno] = data;
return 0;
}
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 183/262] ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe
From: Sasha Levin @ 2019-03-27 18:00 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li,
wen yang, Takashi Iwai, Liam Girdwood, Jaroslav Kysela,
Nicolin Chen, Mark Brown, Wen Yang, Fabio Estevam
In-Reply-To: <20190327180158.10245-1-sashal@kernel.org>
From: wen yang <yellowriver2010@hotmail.com>
[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Signed-off-by: Wen Yang <yellowriver2010@hotmil.com>
Cc: Timur Tabi <timur@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/fsl/fsl-asoc-card.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 81f2fe2c6d23..60f87a0d99f4 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -689,6 +689,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
asrc_fail:
of_node_put(asrc_np);
of_node_put(codec_np);
+ put_device(&cpu_pdev->dev);
fail:
of_node_put(cpu_np);
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 202/262] powerpc/64s: Clear on-stack exception marker upon exception return
From: Sasha Levin @ 2019-03-27 18:00 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Joe Lawrence, linuxppc-dev, Nicolai Stange
In-Reply-To: <20190327180158.10245-1-sashal@kernel.org>
From: Nicolai Stange <nstange@suse.de>
[ Upstream commit eddd0b332304d554ad6243942f87c2fcea98c56b ]
The ppc64 specific implementation of the reliable stacktracer,
save_stack_trace_tsk_reliable(), bails out and reports an "unreliable
trace" whenever it finds an exception frame on the stack. Stack frames
are classified as exception frames if the STACK_FRAME_REGS_MARKER
magic, as written by exception prologues, is found at a particular
location.
However, as observed by Joe Lawrence, it is possible in practice that
non-exception stack frames can alias with prior exception frames and
thus, that the reliable stacktracer can find a stale
STACK_FRAME_REGS_MARKER on the stack. It in turn falsely reports an
unreliable stacktrace and blocks any live patching transition to
finish. Said condition lasts until the stack frame is
overwritten/initialized by function call or other means.
In principle, we could mitigate this by making the exception frame
classification condition in save_stack_trace_tsk_reliable() stronger:
in addition to testing for STACK_FRAME_REGS_MARKER, we could also take
into account that for all exceptions executing on the kernel stack
- their stack frames's backlink pointers always match what is saved
in their pt_regs instance's ->gpr[1] slot and that
- their exception frame size equals STACK_INT_FRAME_SIZE, a value
uncommonly large for non-exception frames.
However, while these are currently true, relying on them would make
the reliable stacktrace implementation more sensitive towards future
changes in the exception entry code. Note that false negatives, i.e.
not detecting exception frames, would silently break the live patching
consistency model.
Furthermore, certain other places (diagnostic stacktraces, perf, xmon)
rely on STACK_FRAME_REGS_MARKER as well.
Make the exception exit code clear the on-stack
STACK_FRAME_REGS_MARKER for those exceptions running on the "normal"
kernel stack and returning to kernelspace: because the topmost frame
is ignored by the reliable stack tracer anyway, returns to userspace
don't need to take care of clearing the marker.
Furthermore, as I don't have the ability to test this on Book 3E or 32
bits, limit the change to Book 3S and 64 bits.
Fixes: df78d3f61480 ("powerpc/livepatch: Implement reliable stack tracing for the consistency model")
Reported-by: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Nicolai Stange <nstange@suse.de>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kernel/entry_64.S | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 435927f549c4..a2c168b395d2 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -1002,6 +1002,13 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
ld r2,_NIP(r1)
mtspr SPRN_SRR0,r2
+ /*
+ * Leaving a stale exception_marker on the stack can confuse
+ * the reliable stack unwinder later on. Clear it.
+ */
+ li r2,0
+ std r2,STACK_FRAME_OVERHEAD-16(r1)
+
ld r0,GPR0(r1)
ld r2,GPR2(r1)
ld r3,GPR3(r1)
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.0 206/262] powerpc/pseries: Perform full re-add of CPU for topology update post-migration
From: Sasha Levin @ 2019-03-27 18:01 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Nathan Fontenot, Michael W . Bringmann, linuxppc-dev
In-Reply-To: <20190327180158.10245-1-sashal@kernel.org>
From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
[ Upstream commit 81b61324922c67f73813d8a9c175f3c153f6a1c6 ]
On pseries systems, performing a partition migration can result in
altering the nodes a CPU is assigned to on the destination system. For
exampl, pre-migration on the source system CPUs are in node 1 and 3,
post-migration on the destination system CPUs are in nodes 2 and 3.
Handling the node change for a CPU can cause corruption in the slab
cache if we hit a timing where a CPUs node is changed while cache_reap()
is invoked. The corruption occurs because the slab cache code appears
to rely on the CPU and slab cache pages being on the same node.
The current dynamic updating of a CPUs node done in arch/powerpc/mm/numa.c
does not prevent us from hitting this scenario.
Changing the device tree property update notification handler that
recognizes an affinity change for a CPU to do a full DLPAR remove and
add of the CPU instead of dynamically changing its node resolves this
issue.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael W. Bringmann <mwb@linux.vnet.ibm.com>
Tested-by: Michael W. Bringmann <mwb@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/topology.h | 2 ++
arch/powerpc/mm/numa.c | 9 +--------
arch/powerpc/platforms/pseries/hotplug-cpu.c | 19 +++++++++++++++++++
3 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index a4a718dbfec6..f85e2b01c3df 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -132,6 +132,8 @@ static inline void shared_proc_topology_init(void) {}
#define topology_sibling_cpumask(cpu) (per_cpu(cpu_sibling_map, cpu))
#define topology_core_cpumask(cpu) (per_cpu(cpu_core_map, cpu))
#define topology_core_id(cpu) (cpu_to_core_id(cpu))
+
+int dlpar_cpu_readd(int cpu);
#endif
#endif
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 8ec2ed30d44c..bdb663da7327 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1464,13 +1464,6 @@ static void reset_topology_timer(void)
#ifdef CONFIG_SMP
-static void stage_topology_update(int core_id)
-{
- cpumask_or(&cpu_associativity_changes_mask,
- &cpu_associativity_changes_mask, cpu_sibling_mask(core_id));
- reset_topology_timer();
-}
-
static int dt_update_callback(struct notifier_block *nb,
unsigned long action, void *data)
{
@@ -1483,7 +1476,7 @@ static int dt_update_callback(struct notifier_block *nb,
!of_prop_cmp(update->prop->name, "ibm,associativity")) {
u32 core_id;
of_property_read_u32(update->dn, "reg", &core_id);
- stage_topology_update(core_id);
+ rc = dlpar_cpu_readd(core_id);
rc = NOTIFY_OK;
}
break;
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 2f8e62163602..97feb6e79f1a 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -802,6 +802,25 @@ static int dlpar_cpu_add_by_count(u32 cpus_to_add)
return rc;
}
+int dlpar_cpu_readd(int cpu)
+{
+ struct device_node *dn;
+ struct device *dev;
+ u32 drc_index;
+ int rc;
+
+ dev = get_cpu_device(cpu);
+ dn = dev->of_node;
+
+ rc = of_property_read_u32(dn, "ibm,my-drc-index", &drc_index);
+
+ rc = dlpar_cpu_remove_by_index(drc_index);
+ if (!rc)
+ rc = dlpar_cpu_add(drc_index);
+
+ return rc;
+}
+
int dlpar_cpu(struct pseries_hp_errorlog *hp_elog)
{
u32 count, drc_index;
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 052/192] powerpc/powernv/ioda: Fix locked_vm counting for memory used by IOMMU tables
From: Sasha Levin @ 2019-03-27 18:08 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Alexey Kardashevskiy, linuxppc-dev, Sasha Levin
In-Reply-To: <20190327181025.13507-1-sashal@kernel.org>
From: Alexey Kardashevskiy <aik@ozlabs.ru>
[ Upstream commit 11f5acce2fa43b015a8120fa7620fa4efd0a2952 ]
We store 2 multilevel tables in iommu_table - one for the hardware and
one with the corresponding userspace addresses. Before allocating
the tables, the iommu_table_group_ops::get_table_size() hook returns
the combined size of the two and VFIO SPAPR TCE IOMMU driver adjusts
the locked_vm counter correctly. When the table is actually allocated,
the amount of allocated memory is stored in iommu_table::it_allocated_size
and used to decrement the locked_vm counter when we release the memory
used by the table; .get_table_size() and .create_table() calculate it
independently but the result is expected to be the same.
However the allocator does not add the userspace table size to
.it_allocated_size so when we destroy the table because of VFIO PCI
unplug (i.e. VFIO container is gone but the userspace keeps running),
we decrement locked_vm by just a half of size of memory we are
releasing.
To make things worse, since we enabled on-demand allocation of
indirect levels, it_allocated_size contains only the amount of memory
actually allocated at the table creation time which can just be a
fraction. It is not a problem with incrementing locked_vm (as
get_table_size() value is used) but it is with decrementing.
As the result, we leak locked_vm and may not be able to allocate more
IOMMU tables after few iterations of hotplug/unplug.
This sets it_allocated_size in the pnv_pci_ioda2_ops::create_table()
hook to what pnv_pci_ioda2_get_table_size() returns so from now on we
have a single place which calculates the maximum memory a table can
occupy. The original meaning of it_allocated_size is somewhat lost now
though.
We do not ditch it_allocated_size whatsoever here and we do not call
get_table_size() from vfio_iommu_spapr_tce.c when decrementing
locked_vm as we may have multiple IOMMU groups per container and even
though they all are supposed to have the same get_table_size()
implementation, there is a small chance for failure or confusion.
Fixes: 090bad39b237 ("powerpc/powernv: Add indirect levels to it_userspace")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/platforms/powernv/pci-ioda-tce.c | 1 -
arch/powerpc/platforms/powernv/pci-ioda.c | 7 ++++++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda-tce.c b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
index 7639b2168755..f5adb6b756f7 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda-tce.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
@@ -313,7 +313,6 @@ long pnv_pci_ioda2_table_alloc_pages(int nid, __u64 bus_offset,
page_shift);
tbl->it_level_size = 1ULL << (level_shift - 3);
tbl->it_indirect_levels = levels - 1;
- tbl->it_allocated_size = total_allocated;
tbl->it_userspace = uas;
tbl->it_nid = nid;
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index cde710297a4e..326ca6288bb1 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -2603,8 +2603,13 @@ static long pnv_pci_ioda2_create_table_userspace(
int num, __u32 page_shift, __u64 window_size, __u32 levels,
struct iommu_table **ptbl)
{
- return pnv_pci_ioda2_create_table(table_group,
+ long ret = pnv_pci_ioda2_create_table(table_group,
num, page_shift, window_size, levels, true, ptbl);
+
+ if (!ret)
+ (*ptbl)->it_allocated_size = pnv_pci_ioda2_get_table_size(
+ page_shift, window_size, levels);
+ return ret;
}
static void pnv_ioda2_take_ownership(struct iommu_table_group *table_group)
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 055/192] powerpc/xmon: Fix opcode being uninitialized in print_insn_powerpc
From: Sasha Levin @ 2019-03-27 18:08 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, Nathan Chancellor, linuxppc-dev
In-Reply-To: <20190327181025.13507-1-sashal@kernel.org>
From: Nathan Chancellor <natechancellor@gmail.com>
[ Upstream commit e7140639b1de65bba435a6bd772d134901141f86 ]
When building with -Wsometimes-uninitialized, Clang warns:
arch/powerpc/xmon/ppc-dis.c:157:7: warning: variable 'opcode' is used
uninitialized whenever 'if' condition is false
[-Wsometimes-uninitialized]
if (cpu_has_feature(CPU_FTRS_POWER9))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/xmon/ppc-dis.c:167:7: note: uninitialized use occurs here
if (opcode == NULL)
^~~~~~
arch/powerpc/xmon/ppc-dis.c:157:3: note: remove the 'if' if its
condition is always true
if (cpu_has_feature(CPU_FTRS_POWER9))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/xmon/ppc-dis.c:132:38: note: initialize the variable
'opcode' to silence this warning
const struct powerpc_opcode *opcode;
^
= NULL
1 warning generated.
This warning seems to make no sense on the surface because opcode is set
to NULL right below this statement. However, there is a comma instead of
semicolon to end the dialect assignment, meaning that the opcode
assignment only happens in the if statement. Properly terminate that
line so that Clang no longer warns.
Fixes: 5b102782c7f4 ("powerpc/xmon: Enable disassembly files (compilation changes)")
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/xmon/ppc-dis.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/xmon/ppc-dis.c b/arch/powerpc/xmon/ppc-dis.c
index 9deea5ee13f6..27f1e6415036 100644
--- a/arch/powerpc/xmon/ppc-dis.c
+++ b/arch/powerpc/xmon/ppc-dis.c
@@ -158,7 +158,7 @@ int print_insn_powerpc (unsigned long insn, unsigned long memaddr)
dialect |= (PPC_OPCODE_POWER5 | PPC_OPCODE_POWER6 | PPC_OPCODE_POWER7
| PPC_OPCODE_POWER8 | PPC_OPCODE_POWER9 | PPC_OPCODE_HTM
| PPC_OPCODE_ALTIVEC | PPC_OPCODE_ALTIVEC2
- | PPC_OPCODE_VSX | PPC_OPCODE_VSX3),
+ | PPC_OPCODE_VSX | PPC_OPCODE_VSX3);
/* Get the major opcode of the insn. */
opcode = NULL;
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 060/192] powerpc/hugetlb: Handle mmap_min_addr correctly in get_unmapped_area callback
From: Sasha Levin @ 2019-03-27 18:08 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20190327181025.13507-1-sashal@kernel.org>
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
[ Upstream commit 5330367fa300742a97e20e953b1f77f48392faae ]
After we ALIGN up the address we need to make sure we didn't overflow
and resulted in zero address. In that case, we need to make sure that
the returned address is greater than mmap_min_addr.
This fixes selftest va_128TBswitch --run-hugetlb reporting failures when
run as non root user for
mmap(-1, MAP_HUGETLB)
The bug is that a non-root user requesting address -1 will be given address 0
which will then fail, whereas they should have been given something else that
would have succeeded.
We also avoid the first mmap(-1, MAP_HUGETLB) returning NULL address as mmap address
with this change. So we think this is not a security issue, because it only affects
whether we choose an address below mmap_min_addr, not whether we
actually allow that address to be mapped. ie. there are existing capability
checks to prevent a user mapping below mmap_min_addr and those will still be
honoured even without this fix.
Fixes: 484837601d4d ("powerpc/mm: Add radix support for hugetlb")
Reviewed-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/mm/hugetlbpage-radix.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage-radix.c b/arch/powerpc/mm/hugetlbpage-radix.c
index 2486bee0f93e..97c7a39ebc00 100644
--- a/arch/powerpc/mm/hugetlbpage-radix.c
+++ b/arch/powerpc/mm/hugetlbpage-radix.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
#include <linux/mm.h>
#include <linux/hugetlb.h>
+#include <linux/security.h>
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
#include <asm/cacheflush.h>
@@ -73,7 +74,7 @@ radix__hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
if (addr) {
addr = ALIGN(addr, huge_page_size(h));
vma = find_vma(mm, addr);
- if (high_limit - len >= addr &&
+ if (high_limit - len >= addr && addr >= mmap_min_addr &&
(!vma || addr + len <= vm_start_gap(vma)))
return addr;
}
@@ -83,7 +84,7 @@ radix__hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
*/
info.flags = VM_UNMAPPED_AREA_TOPDOWN;
info.length = len;
- info.low_limit = PAGE_SIZE;
+ info.low_limit = max(PAGE_SIZE, mmap_min_addr);
info.high_limit = mm->mmap_base + (high_limit - DEFAULT_MAP_WINDOW);
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 083/192] SoC: imx-sgtl5000: add missing put_device()
From: Sasha Levin @ 2019-03-27 18:08 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li,
Wen Yang, Sascha Hauer, Takashi Iwai, Liam Girdwood,
Jaroslav Kysela, Nicolin Chen, Mark Brown, NXP Linux Team,
Pengutronix Kernel Team, Shawn Guo, Fabio Estevam,
linux-arm-kernel
In-Reply-To: <20190327181025.13507-1-sashal@kernel.org>
From: Wen Yang <yellowriver2010@hotmail.com>
[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
Signed-off-by: Wen Yang <yellowriver2010@hotmail.com>
Cc: Timur Tabi <timur@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/fsl/imx-sgtl5000.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index c29200cf755a..9b9a7ec52905 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -108,6 +108,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev)
ret = -EPROBE_DEFER;
goto fail;
}
+ put_device(&ssi_pdev->dev);
codec_dev = of_find_i2c_device_by_node(codec_np);
if (!codec_dev) {
dev_err(&pdev->dev, "failed to find codec platform device\n");
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 133/192] ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe
From: Sasha Levin @ 2019-03-27 18:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, alsa-devel, linuxppc-dev, Timur Tabi, Xiubo Li,
wen yang, Takashi Iwai, Liam Girdwood, Jaroslav Kysela,
Nicolin Chen, Mark Brown, Wen Yang, Fabio Estevam
In-Reply-To: <20190327181025.13507-1-sashal@kernel.org>
From: wen yang <yellowriver2010@hotmail.com>
[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Signed-off-by: Wen Yang <yellowriver2010@hotmil.com>
Cc: Timur Tabi <timur@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/fsl/fsl-asoc-card.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 44433b20435c..600d9be9706e 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -689,6 +689,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
asrc_fail:
of_node_put(asrc_np);
of_node_put(codec_np);
+ put_device(&cpu_pdev->dev);
fail:
of_node_put(cpu_np);
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 148/192] powerpc/64s: Clear on-stack exception marker upon exception return
From: Sasha Levin @ 2019-03-27 18:09 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Joe Lawrence, linuxppc-dev, Nicolai Stange
In-Reply-To: <20190327181025.13507-1-sashal@kernel.org>
From: Nicolai Stange <nstange@suse.de>
[ Upstream commit eddd0b332304d554ad6243942f87c2fcea98c56b ]
The ppc64 specific implementation of the reliable stacktracer,
save_stack_trace_tsk_reliable(), bails out and reports an "unreliable
trace" whenever it finds an exception frame on the stack. Stack frames
are classified as exception frames if the STACK_FRAME_REGS_MARKER
magic, as written by exception prologues, is found at a particular
location.
However, as observed by Joe Lawrence, it is possible in practice that
non-exception stack frames can alias with prior exception frames and
thus, that the reliable stacktracer can find a stale
STACK_FRAME_REGS_MARKER on the stack. It in turn falsely reports an
unreliable stacktrace and blocks any live patching transition to
finish. Said condition lasts until the stack frame is
overwritten/initialized by function call or other means.
In principle, we could mitigate this by making the exception frame
classification condition in save_stack_trace_tsk_reliable() stronger:
in addition to testing for STACK_FRAME_REGS_MARKER, we could also take
into account that for all exceptions executing on the kernel stack
- their stack frames's backlink pointers always match what is saved
in their pt_regs instance's ->gpr[1] slot and that
- their exception frame size equals STACK_INT_FRAME_SIZE, a value
uncommonly large for non-exception frames.
However, while these are currently true, relying on them would make
the reliable stacktrace implementation more sensitive towards future
changes in the exception entry code. Note that false negatives, i.e.
not detecting exception frames, would silently break the live patching
consistency model.
Furthermore, certain other places (diagnostic stacktraces, perf, xmon)
rely on STACK_FRAME_REGS_MARKER as well.
Make the exception exit code clear the on-stack
STACK_FRAME_REGS_MARKER for those exceptions running on the "normal"
kernel stack and returning to kernelspace: because the topmost frame
is ignored by the reliable stack tracer anyway, returns to userspace
don't need to take care of clearing the marker.
Furthermore, as I don't have the ability to test this on Book 3E or 32
bits, limit the change to Book 3S and 64 bits.
Fixes: df78d3f61480 ("powerpc/livepatch: Implement reliable stack tracing for the consistency model")
Reported-by: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Nicolai Stange <nstange@suse.de>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kernel/entry_64.S | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 2206912ea4f0..1f39ce40ae11 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -989,6 +989,13 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
ld r2,_NIP(r1)
mtspr SPRN_SRR0,r2
+ /*
+ * Leaving a stale exception_marker on the stack can confuse
+ * the reliable stack unwinder later on. Clear it.
+ */
+ li r2,0
+ std r2,STACK_FRAME_OVERHEAD-16(r1)
+
ld r0,GPR0(r1)
ld r2,GPR2(r1)
ld r3,GPR3(r1)
--
2.19.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