* [PATCH v5 11/23] PCI: hotplug: movable BARs: Calculate immovable parts of bridge windows
From: Sergey Miroshnichenko @ 2019-08-16 16:50 UTC (permalink / raw)
To: linux-pci, linuxppc-dev; +Cc: Sergey Miroshnichenko, Bjorn Helgaas, linux
In-Reply-To: <20190816165101.911-1-s.miroshnichenko@yadro.com>
When movable BARs are enabled, and if a bridge contains a device with fixed
(IORESOURCE_PCI_FIXED) or immovable BARs, the corresponing windows can't be
moved too far away from their original positions - they must still contain
all the fixed/immovable BARs, like that:
1) Window position before a bus rescan:
| <-- root bridge window --> |
| |
| | <-- bridge window --> | |
| | movable BARs | **fixed BAR** | |
2) Possible valid outcome after rescan and move:
| <-- root bridge window --> |
| |
| | <-- bridge window --> | |
| | **fixed BAR** | Movable BARs | |
An immovable area of a bridge (separare for IO, MEM and MEM64 window types)
is a range that covers all the fixed and immovable BARs of direct children,
and all the fixed area of children bridges:
| <-- root bridge window --> |
| |
| | <-- bridge window level 1 --> | |
| | ******** immovable area of this bridge window ******** | |
| | | |
| | **fixed BAR** | <-- bridge window level 2 --> | BARs | |
| | | ***** fixed area of this bridge ***** | | |
| | | | | |
| | | ***fixed BAR*** | | ***fixed BAR*** | | |
To store these areas, the .immovable_range field has been added to struct
pci_bus. It is filled recursively from leaves to the root before a rescan.
Also make pbus_size_io() and pbus_size_mem() return their usual result OR
the size of an immovable range of according type, depending on which one is
larger.
Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
---
drivers/pci/pci.h | 14 +++++++
drivers/pci/probe.c | 88 +++++++++++++++++++++++++++++++++++++++++
drivers/pci/setup-bus.c | 17 ++++++++
include/linux/pci.h | 6 +++
4 files changed, 125 insertions(+)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 53249cbc21b6..12add575faf1 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -371,6 +371,20 @@ static inline bool pci_dev_is_disconnected(const struct pci_dev *dev)
return dev->error_state == pci_channel_io_perm_failure;
}
+static inline int pci_get_bridge_resource_idx(struct resource *r)
+{
+ int idx = 1;
+
+ if (r->flags & IORESOURCE_IO)
+ idx = 0;
+ else if (!(r->flags & IORESOURCE_PREFETCH))
+ idx = 1;
+ else if (r->flags & IORESOURCE_MEM_64)
+ idx = 2;
+
+ return idx;
+}
+
/* pci_dev priv_flags */
#define PCI_DEV_ADDED 0
#define PCI_DEV_DISABLED_BARS 1
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index bf0a7d1c5d09..5f52a19738aa 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -550,6 +550,7 @@ void pci_read_bridge_bases(struct pci_bus *child)
static struct pci_bus *pci_alloc_bus(struct pci_bus *parent)
{
struct pci_bus *b;
+ int idx;
b = kzalloc(sizeof(*b), GFP_KERNEL);
if (!b)
@@ -566,6 +567,11 @@ static struct pci_bus *pci_alloc_bus(struct pci_bus *parent)
if (parent)
b->domain_nr = parent->domain_nr;
#endif
+ for (idx = 0; idx < PCI_BRIDGE_RESOURCE_NUM; ++idx) {
+ b->immovable_range[idx].start = 0;
+ b->immovable_range[idx].end = 0;
+ }
+
return b;
}
@@ -3512,6 +3518,87 @@ static void pci_setup_bridges(struct pci_bus *bus)
pci_setup_bridge(bus);
}
+static void pci_bus_update_immovable_range(struct pci_bus *bus)
+{
+ struct pci_dev *dev;
+ int idx;
+ resource_size_t start, end;
+
+ for (idx = 0; idx < PCI_BRIDGE_RESOURCE_NUM; ++idx) {
+ bus->immovable_range[idx].start = 0;
+ bus->immovable_range[idx].end = 0;
+ }
+
+ list_for_each_entry(dev, &bus->devices, bus_list)
+ if (dev->subordinate)
+ pci_bus_update_immovable_range(dev->subordinate);
+
+ list_for_each_entry(dev, &bus->devices, bus_list) {
+ int i;
+ bool dev_is_movable = pci_dev_movable_bars_supported(dev);
+ struct pci_bus *child = dev->subordinate;
+
+ for (i = 0; i < PCI_BRIDGE_RESOURCES; ++i) {
+ struct resource *r = &dev->resource[i];
+
+ if (!r->flags || (r->flags & IORESOURCE_UNSET) || !r->parent)
+ continue;
+
+ if (!dev_is_movable || (r->flags & IORESOURCE_PCI_FIXED)) {
+ idx = pci_get_bridge_resource_idx(r);
+ start = bus->immovable_range[idx].start;
+ end = bus->immovable_range[idx].end;
+
+ if (!start || start > r->start)
+ start = r->start;
+ if (end < r->end)
+ end = r->end;
+
+ if (bus->immovable_range[idx].start != start ||
+ bus->immovable_range[idx].end != end) {
+ dev_dbg(&bus->dev, "Found fixed 0x%llx-0x%llx in %s, expand the fixed bridge window %d to 0x%llx-0x%llx\n",
+ (unsigned long long)r->start,
+ (unsigned long long)r->end,
+ dev_name(&dev->dev), idx,
+ (unsigned long long)start,
+ (unsigned long long)end);
+ bus->immovable_range[idx].start = start;
+ bus->immovable_range[idx].end = end;
+ }
+ }
+ }
+
+ if (child) {
+ for (idx = 0; idx < PCI_BRIDGE_RESOURCE_NUM; ++idx) {
+ struct resource *child_immovable_range =
+ &child->immovable_range[idx];
+
+ if (child_immovable_range->start >=
+ child_immovable_range->end)
+ continue;
+
+ start = bus->immovable_range[idx].start;
+ end = bus->immovable_range[idx].end;
+
+ if (!start || start > child_immovable_range->start)
+ start = child_immovable_range->start;
+ if (end < child_immovable_range->end)
+ end = child_immovable_range->end;
+
+ if (start < bus->immovable_range[idx].start ||
+ end > bus->immovable_range[idx].end) {
+ dev_dbg(&bus->dev, "Expand the fixed bridge window %d from %s to 0x%llx-0x%llx\n",
+ idx, dev_name(&child->dev),
+ (unsigned long long)start,
+ (unsigned long long)end);
+ bus->immovable_range[idx].start = start;
+ bus->immovable_range[idx].end = end;
+ }
+ }
+ }
+ }
+}
+
static struct pci_dev *pci_find_next_new_device(struct pci_bus *bus)
{
struct pci_dev *dev;
@@ -3610,6 +3697,7 @@ unsigned int pci_rescan_bus(struct pci_bus *bus)
pci_bus_rescan_prepare(root);
max = pci_scan_child_bus(root);
+ pci_bus_update_immovable_range(root);
pci_reassign_root_bus_resources(root);
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 33f709095675..420510a1a257 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -882,9 +882,17 @@ static void pbus_size_io(struct pci_bus *bus, resource_size_t min_size,
resource_size_t children_add_size = 0;
resource_size_t min_align, align;
+ resource_size_t fixed_start = bus->immovable_range[0].start;
+ resource_size_t fixed_end = bus->immovable_range[0].end;
+ resource_size_t fixed_size = (fixed_start < fixed_end) ?
+ (fixed_end - fixed_start + 1) : 0;
+
if (!b_res)
return;
+ if (min_size < fixed_size)
+ min_size = fixed_size;
+
min_align = window_alignment(bus, IORESOURCE_IO);
list_for_each_entry(dev, &bus->devices, bus_list) {
int i;
@@ -993,6 +1001,15 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask,
resource_size_t children_add_size = 0;
resource_size_t children_add_align = 0;
resource_size_t add_align = 0;
+ bool is_mem64 = (mask & IORESOURCE_MEM_64);
+
+ resource_size_t fixed_start = bus->immovable_range[is_mem64 ? 2 : 1].start;
+ resource_size_t fixed_end = bus->immovable_range[is_mem64 ? 2 : 1].end;
+ resource_size_t fixed_size = (fixed_start < fixed_end) ?
+ (fixed_end - fixed_start + 1) : 0;
+
+ if (min_size < fixed_size)
+ min_size = fixed_size;
if (!b_res)
return -ENOSPC;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 95a8113c2157..efafbf816fe6 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -581,6 +581,12 @@ struct pci_bus {
struct list_head resources; /* Address space routed to this bus */
struct resource busn_res; /* Bus numbers routed to this bus */
+ /*
+ * If there are fixed or immovable resources in the bridge window, this range
+ * contains the lowest start address and highest end address of them.
+ */
+ struct resource immovable_range[PCI_BRIDGE_RESOURCE_NUM];
+
struct pci_ops *ops; /* Configuration access functions */
struct msi_controller *msi; /* MSI controller */
void *sysdata; /* Hook for sys-specific extension */
--
2.21.0
^ permalink raw reply related
* [PATCH v5 12/23] PCI: hotplug: movable BARs: Compute limits for relocated bridge windows
From: Sergey Miroshnichenko @ 2019-08-16 16:50 UTC (permalink / raw)
To: linux-pci, linuxppc-dev; +Cc: Sergey Miroshnichenko, Bjorn Helgaas, linux
In-Reply-To: <20190816165101.911-1-s.miroshnichenko@yadro.com>
With enabled movable BARs, bridge windows are recalculated during each pci
rescan. Some of the BARs below the bridge may be fixed/immovable: these
areas are represented by the .immovable_range field in struct pci_bus.
If a bridge window size is equal to its immovable range, it can only be
assigned to the start of this range. But if a bridge window size is larger,
and this difference in size is denoted as "delta", the window can start
from (immovable_range.start - delta) to (immovable_range.start), and it can
end from (immovable_range.end) to (immovable_range.end + delta). This range
(the new .realloc_range field in struct pci_bus) must then be compared with
immovable ranges of neighbouring bridges to guarantee no intersections.
This patch only calculates valid ranges for reallocated bridges during pci
rescan, and the next one will make use of these values during allocation.
Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
---
drivers/pci/setup-bus.c | 67 +++++++++++++++++++++++++++++++++++++++++
include/linux/pci.h | 6 ++++
2 files changed, 73 insertions(+)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 420510a1a257..586aaa9578b2 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1819,6 +1819,72 @@ static enum enable_type pci_realloc_detect(struct pci_bus *bus,
}
#endif
+/*
+ * Calculate the address margins where the bridge windows may be allocated to fit all
+ * the fixed and immovable BARs beneath.
+ */
+static void pci_bus_update_realloc_range(struct pci_bus *bus)
+{
+ struct pci_dev *dev;
+ struct pci_bus *parent = bus->parent;
+ int idx;
+
+ list_for_each_entry(dev, &bus->devices, bus_list)
+ if (dev->subordinate)
+ pci_bus_update_realloc_range(dev->subordinate);
+
+ if (!parent || !bus->self)
+ return;
+
+ for (idx = 0; idx < PCI_BRIDGE_RESOURCE_NUM; ++idx) {
+ struct resource *immovable_range = &bus->immovable_range[idx];
+ resource_size_t window_size = resource_size(bus->resource[idx]);
+ resource_size_t realloc_start, realloc_end;
+
+ bus->realloc_range[idx].start = 0;
+ bus->realloc_range[idx].end = 0;
+
+ /* Check if there any immovable BARs under the bridge */
+ if (immovable_range->start >= immovable_range->end)
+ continue;
+
+ /* The lowest possible address where the bridge window can start */
+ realloc_start = immovable_range->end - window_size + 1;
+ /* The highest possible address where the bridge window can end */
+ realloc_end = immovable_range->start + window_size - 1;
+
+ if (realloc_start > immovable_range->start)
+ realloc_start = immovable_range->start;
+
+ if (realloc_end < immovable_range->end)
+ realloc_end = immovable_range->end;
+
+ /*
+ * Check that realloc range doesn't intersect with hard fixed ranges
+ * of neighboring bridges
+ */
+ list_for_each_entry(dev, &parent->devices, bus_list) {
+ struct pci_bus *neighbor = dev->subordinate;
+ struct resource *n_imm_range;
+
+ if (!neighbor || neighbor == bus)
+ continue;
+
+ n_imm_range = &neighbor->immovable_range[idx];
+
+ if (n_imm_range->start >= n_imm_range->end)
+ continue;
+
+ if (n_imm_range->end < immovable_range->start &&
+ n_imm_range->end > realloc_start)
+ realloc_start = n_imm_range->end;
+ }
+
+ bus->realloc_range[idx].start = realloc_start;
+ bus->realloc_range[idx].end = realloc_end;
+ }
+}
+
/*
* First try will not touch PCI bridge res.
* Second and later try will clear small leaf bridge res.
@@ -1838,6 +1904,7 @@ void pci_assign_unassigned_root_bus_resources(struct pci_bus *bus)
if (pci_movable_bars_enabled()) {
__pci_bus_size_bridges(bus, NULL);
+ pci_bus_update_realloc_range(bus);
__pci_bus_assign_resources(bus, NULL, NULL);
goto dump;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index efafbf816fe6..bf6638cf2525 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -587,6 +587,12 @@ struct pci_bus {
*/
struct resource immovable_range[PCI_BRIDGE_RESOURCE_NUM];
+ /*
+ * Acceptable address range, where the bridge window may reside, considering its
+ * size, so it will cover all the fixed and immovable BARs below.
+ */
+ struct resource realloc_range[PCI_BRIDGE_RESOURCE_NUM];
+
struct pci_ops *ops; /* Configuration access functions */
struct msi_controller *msi; /* MSI controller */
void *sysdata; /* Hook for sys-specific extension */
--
2.21.0
^ permalink raw reply related
* [PATCH v5 14/23] PCI: Fix assigning the fixed prefetchable resources
From: Sergey Miroshnichenko @ 2019-08-16 16:50 UTC (permalink / raw)
To: linux-pci, linuxppc-dev; +Cc: Sergey Miroshnichenko, Bjorn Helgaas, linux
In-Reply-To: <20190816165101.911-1-s.miroshnichenko@yadro.com>
Allow matching IORESOURCE_PCI_FIXED prefetchable BARs to non-prefetchable
windows, so they follow the same rules as immovable BARs.
Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
---
drivers/pci/setup-bus.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 586aaa9578b2..6f12411357f3 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1340,15 +1340,20 @@ static void assign_fixed_resource_on_bus(struct pci_bus *b, struct resource *r)
{
int i;
struct resource *parent_r;
- unsigned long mask = IORESOURCE_IO | IORESOURCE_MEM |
- IORESOURCE_PREFETCH;
+ unsigned long mask = IORESOURCE_TYPE_BITS;
pci_bus_for_each_resource(b, parent_r, i) {
if (!parent_r)
continue;
- if ((r->flags & mask) == (parent_r->flags & mask) &&
- resource_contains(parent_r, r))
+ if ((r->flags & mask) != (parent_r->flags & mask))
+ continue;
+
+ if (parent_r->flags & IORESOURCE_PREFETCH &&
+ !(r->flags & IORESOURCE_PREFETCH))
+ continue;
+
+ if (resource_contains(parent_r, r))
request_resource(parent_r, r);
}
}
--
2.21.0
^ permalink raw reply related
* [PATCH v5 13/23] PCI: Make sure bridge windows include their fixed BARs
From: Sergey Miroshnichenko @ 2019-08-16 16:50 UTC (permalink / raw)
To: linux-pci, linuxppc-dev; +Cc: Sergey Miroshnichenko, Bjorn Helgaas, linux
In-Reply-To: <20190816165101.911-1-s.miroshnichenko@yadro.com>
When the time comes to select a start address for the bridge window during
the root bus rescan, it should be not just a lowest possible address: this
window must cover all the underlying fixed and immovable BARs. The lowest
address that satisfies this requirement is the .realloc_range field of
struct pci_bus, which is calculated during the preparation to the rescan.
Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
---
drivers/pci/bus.c | 2 +-
drivers/pci/setup-res.c | 28 ++++++++++++++++++++++++++--
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 495059d923f7..7aae830751e9 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -192,7 +192,7 @@ static int pci_bus_alloc_from_region(struct pci_bus *bus, struct resource *res,
* this is an already-configured bridge window, its start
* overrides "min".
*/
- if (avail.start)
+ if (min_used < avail.start)
min_used = avail.start;
max = avail.end;
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 732d18f60f1b..7357bcc12a53 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -248,9 +248,20 @@ static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
struct resource *res = dev->resource + resno;
resource_size_t min;
int ret;
+ resource_size_t start = (resource_size_t)-1;
+ resource_size_t end = 0;
min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
+ if (dev->subordinate && resno >= PCI_BRIDGE_RESOURCES) {
+ struct pci_bus *child_bus = dev->subordinate;
+ int b_resno = resno - PCI_BRIDGE_RESOURCES;
+ struct resource *immovable_range = &child_bus->immovable_range[b_resno];
+
+ if (immovable_range->start < immovable_range->end)
+ min = child_bus->realloc_range[b_resno].start;
+ }
+
/*
* First, try exact prefetching match. Even if a 64-bit
* prefetchable bridge window is below 4GB, we can't put a 32-bit
@@ -262,7 +273,7 @@ static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
IORESOURCE_PREFETCH | IORESOURCE_MEM_64,
pcibios_align_resource, dev);
if (ret == 0)
- return 0;
+ goto check_fixed;
/*
* If the prefetchable window is only 32 bits wide, we can put
@@ -274,7 +285,7 @@ static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
IORESOURCE_PREFETCH,
pcibios_align_resource, dev);
if (ret == 0)
- return 0;
+ goto check_fixed;
}
/*
@@ -287,6 +298,19 @@ static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
ret = pci_bus_alloc_resource(bus, res, size, align, min, 0,
pcibios_align_resource, dev);
+check_fixed:
+ if (ret == 0 && start < end) {
+ if (res->start > start || res->end < end) {
+ dev_err(&bus->dev, "fixed area 0x%llx-0x%llx for %s doesn't fit in the allocated %pR (0x%llx-0x%llx)",
+ (unsigned long long)start, (unsigned long long)end,
+ dev_name(&dev->dev),
+ res, (unsigned long long)res->start,
+ (unsigned long long)res->end);
+ release_resource(res);
+ return -1;
+ }
+ }
+
return ret;
}
--
2.21.0
^ permalink raw reply related
* [PATCH v5 16/23] PCI: hotplug: movable BARs: Don't reserve IO/mem bus space
From: Sergey Miroshnichenko @ 2019-08-16 16:50 UTC (permalink / raw)
To: linux-pci, linuxppc-dev; +Cc: Sergey Miroshnichenko, Bjorn Helgaas, linux
In-Reply-To: <20190816165101.911-1-s.miroshnichenko@yadro.com>
A hotplugged bridge with many hotplug-capable ports may request
reserving more IO space than the machine has. This could be overridden
with the "hpiosize=" kernel argument though.
But when BARs are movable, there are no need to reserve space anymore:
new BARs are allocated not from reserved gaps, but via rearranging the
existing BARs. Requesting a precise amount of space for bridge windows
increases the chances of adding the new bridge successfully.
Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
---
drivers/pci/setup-bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index c7b7e30c6284..7d64ec8e7088 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1287,7 +1287,7 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct list_head *realloc_head)
case PCI_HEADER_TYPE_BRIDGE:
pci_bridge_check_ranges(bus);
- if (bus->self->is_hotplug_bridge) {
+ if (bus->self->is_hotplug_bridge && !pci_movable_bars_enabled()) {
additional_io_size = pci_hotplug_io_size;
additional_mem_size = pci_hotplug_mem_size;
}
--
2.21.0
^ permalink raw reply related
* [PATCH v5 17/23] powerpc/pci: Fix crash with enabled movable BARs
From: Sergey Miroshnichenko @ 2019-08-16 16:50 UTC (permalink / raw)
To: linux-pci, linuxppc-dev
Cc: Alexey Kardashevskiy, Sergey Miroshnichenko, Bjorn Helgaas, linux
In-Reply-To: <20190816165101.911-1-s.miroshnichenko@yadro.com>
Add a check for the UNSET resource flag to skip the released BARs
CC: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index d8080558d020..362eac42f463 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -2986,7 +2986,8 @@ static void pnv_ioda_setup_pe_res(struct pnv_ioda_pe *pe,
int index;
int64_t rc;
- if (!res || !res->flags || res->start > res->end)
+ if (!res || !res->flags || res->start > res->end ||
+ (res->flags & IORESOURCE_UNSET))
return;
if (res->flags & IORESOURCE_IO) {
--
2.21.0
^ permalink raw reply related
* [PATCH v5 15/23] PCI: hotplug: movable BARs: Assign fixed and immovable BARs before others
From: Sergey Miroshnichenko @ 2019-08-16 16:50 UTC (permalink / raw)
To: linux-pci, linuxppc-dev; +Cc: Sergey Miroshnichenko, Bjorn Helgaas, linux
In-Reply-To: <20190816165101.911-1-s.miroshnichenko@yadro.com>
Reassign resources during rescan in two steps: first the fixed/immovable
BARs and bridge windows that have fixed areas, so the movable ones will not
steal these reserved areas; then the rest - so the movable BARs will divide
the rest of the space.
With this change, pci_assign_resource() is now able to assign all types of
BARs, so the pdev_assign_fixed_resources() became unused and thus removed.
Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
---
drivers/pci/pci.h | 2 ++
drivers/pci/setup-bus.c | 79 ++++++++++++++++++++++++-----------------
drivers/pci/setup-res.c | 8 +++--
3 files changed, 55 insertions(+), 34 deletions(-)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 12add575faf1..e1fcc46f9c40 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -260,6 +260,8 @@ void pci_disable_bridge_window(struct pci_dev *dev);
bool pci_dev_movable_bars_supported(struct pci_dev *dev);
+int assign_fixed_resource_on_bus(struct pci_bus *b, struct resource *r);
+
/* PCIe link information */
#define PCIE_SPEED2STR(speed) \
((speed) == PCIE_SPEED_16_0GT ? "16 GT/s" : \
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 6f12411357f3..c7b7e30c6284 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -38,6 +38,15 @@ struct pci_dev_resource {
unsigned long flags;
};
+enum assign_step {
+ assign_fixed_resources,
+ assign_float_resources,
+};
+
+static void _assign_requested_resources_sorted(struct list_head *head,
+ struct list_head *fail_head,
+ enum assign_step step);
+
static void free_list(struct list_head *head)
{
struct pci_dev_resource *dev_res, *tmp;
@@ -278,19 +287,48 @@ static void reassign_resources_sorted(struct list_head *realloc_head,
*/
static void assign_requested_resources_sorted(struct list_head *head,
struct list_head *fail_head)
+{
+ _assign_requested_resources_sorted(head, fail_head, assign_fixed_resources);
+ _assign_requested_resources_sorted(head, fail_head, assign_float_resources);
+}
+
+static void _assign_requested_resources_sorted(struct list_head *head,
+ struct list_head *fail_head,
+ enum assign_step step)
{
struct resource *res;
struct pci_dev_resource *dev_res;
int idx;
list_for_each_entry(dev_res, head, list) {
+ bool is_fixed = false;
+
if (!pci_dev_bars_enabled(dev_res->dev))
continue;
res = dev_res->res;
+ if (!resource_size(res))
+ continue;
+
idx = res - &dev_res->dev->resource[0];
- if (resource_size(res) &&
- pci_assign_resource(dev_res->dev, idx)) {
+
+ if (idx < PCI_BRIDGE_RESOURCES) {
+ is_fixed = (res->flags & IORESOURCE_PCI_FIXED) ||
+ !pci_dev_movable_bars_supported(dev_res->dev);
+ } else {
+ int b_res_idx = pci_get_bridge_resource_idx(res);
+ struct resource *fixed_res =
+ &dev_res->dev->subordinate->immovable_range[b_res_idx];
+
+ is_fixed = (fixed_res->start < fixed_res->end);
+ }
+
+ if (assign_fixed_resources == step && !is_fixed)
+ continue;
+ else if (assign_float_resources == step && is_fixed)
+ continue;
+
+ if (pci_assign_resource(dev_res->dev, idx)) {
if (fail_head) {
/*
* If the failed resource is a ROM BAR and
@@ -1336,7 +1374,7 @@ void pci_bus_size_bridges(struct pci_bus *bus)
}
EXPORT_SYMBOL(pci_bus_size_bridges);
-static void assign_fixed_resource_on_bus(struct pci_bus *b, struct resource *r)
+int assign_fixed_resource_on_bus(struct pci_bus *b, struct resource *r)
{
int i;
struct resource *parent_r;
@@ -1353,35 +1391,14 @@ static void assign_fixed_resource_on_bus(struct pci_bus *b, struct resource *r)
!(r->flags & IORESOURCE_PREFETCH))
continue;
- if (resource_contains(parent_r, r))
- request_resource(parent_r, r);
- }
-}
-
-/*
- * Try to assign any resources marked as IORESOURCE_PCI_FIXED, as they are
- * skipped by pbus_assign_resources_sorted().
- */
-static void pdev_assign_fixed_resources(struct pci_dev *dev)
-{
- int i;
-
- for (i = 0; i < PCI_NUM_RESOURCES; i++) {
- struct pci_bus *b;
- struct resource *r = &dev->resource[i];
-
- if (r->parent || !(r->flags & IORESOURCE_PCI_FIXED) ||
- !(r->flags & (IORESOURCE_IO | IORESOURCE_MEM)))
- continue;
-
- b = dev->bus;
- while (b && !r->parent) {
- assign_fixed_resource_on_bus(b, r);
- b = b->parent;
- if (!r->parent && pci_movable_bars_enabled())
- break;
+ if (resource_contains(parent_r, r)) {
+ if (!request_resource(parent_r, r))
+ return 0;
}
}
+
+ dev_err(&b->dev, "failed to assign immovable %pR\n", r);
+ return -EBUSY;
}
void __pci_bus_assign_resources(const struct pci_bus *bus,
@@ -1397,8 +1414,6 @@ void __pci_bus_assign_resources(const struct pci_bus *bus,
if (!pci_dev_bars_enabled(dev))
continue;
- pdev_assign_fixed_resources(dev);
-
b = dev->subordinate;
if (!b)
continue;
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 7357bcc12a53..02620cfac0c7 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -348,8 +348,12 @@ int pci_assign_resource(struct pci_dev *dev, int resno)
resource_size_t align, size;
int ret;
- if (res->flags & IORESOURCE_PCI_FIXED)
- return 0;
+ if ((res->flags & IORESOURCE_PCI_FIXED) ||
+ (resno < PCI_BRIDGE_RESOURCES &&
+ !pci_dev_movable_bars_supported(dev) &&
+ res->start)) {
+ return assign_fixed_resource_on_bus(dev->bus, res);
+ }
res->flags |= IORESOURCE_UNSET;
align = pci_resource_alignment(dev, res);
--
2.21.0
^ permalink raw reply related
* [PATCH v5 18/23] powerpc/pci: Handle BAR movement
From: Sergey Miroshnichenko @ 2019-08-16 16:50 UTC (permalink / raw)
To: linux-pci, linuxppc-dev
Cc: Sergey Miroshnichenko, Oliver O'Halloran, Bjorn Helgaas,
linux
In-Reply-To: <20190816165101.911-1-s.miroshnichenko@yadro.com>
Add pcibios_rescan_prepare()/_done() hooks for the powerpc platform. Now if
the device's driver supports movable BARs, pcibios_rescan_prepare() will be
called after the device is stopped, and pcibios_rescan_done() - before it
resumes. There are no memory requests to this device between the hooks, so
it it safe to rebuild the EEH address cache during that.
CC: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
---
arch/powerpc/kernel/pci-hotplug.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/kernel/pci-hotplug.c b/arch/powerpc/kernel/pci-hotplug.c
index 0b0cf8168b47..18cf13bba228 100644
--- a/arch/powerpc/kernel/pci-hotplug.c
+++ b/arch/powerpc/kernel/pci-hotplug.c
@@ -144,3 +144,13 @@ void pci_hp_add_devices(struct pci_bus *bus)
pcibios_finish_adding_to_bus(bus);
}
EXPORT_SYMBOL_GPL(pci_hp_add_devices);
+
+void pcibios_rescan_prepare(struct pci_dev *pdev)
+{
+ eeh_addr_cache_rmv_dev(pdev);
+}
+
+void pcibios_rescan_done(struct pci_dev *pdev)
+{
+ eeh_addr_cache_insert_dev(pdev);
+}
--
2.21.0
^ permalink raw reply related
* [PATCH v5 19/23] PCI: hotplug: Configure MPS for hot-added bridges during bus rescan
From: Sergey Miroshnichenko @ 2019-08-16 16:50 UTC (permalink / raw)
To: linux-pci, linuxppc-dev; +Cc: Sergey Miroshnichenko, Bjorn Helgaas, linux
In-Reply-To: <20190816165101.911-1-s.miroshnichenko@yadro.com>
Assure that MPS settings are set up for bridges which are discovered
during manually triggered rescan via sysfs. This sequence of bridge
init (using pci_rescan_bus()) will be used for pciehp hot-add events
when BARs are movable.
Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
---
drivers/pci/probe.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 5f52a19738aa..4bb10d27cb3a 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -3688,7 +3688,7 @@ static void pci_reassign_root_bus_resources(struct pci_bus *root)
unsigned int pci_rescan_bus(struct pci_bus *bus)
{
unsigned int max;
- struct pci_bus *root = bus;
+ struct pci_bus *root = bus, *child;
while (!pci_is_root_bus(root))
root = root->parent;
@@ -3708,6 +3708,9 @@ unsigned int pci_rescan_bus(struct pci_bus *bus)
pci_assign_unassigned_bus_resources(bus);
}
+ list_for_each_entry(child, &root->children, node)
+ pcie_bus_configure_settings(child);
+
pci_bus_add_devices(bus);
return max;
--
2.21.0
^ permalink raw reply related
* [PATCH v5 20/23] PCI: hotplug: movable BARs: Enable the feature by default
From: Sergey Miroshnichenko @ 2019-08-16 16:50 UTC (permalink / raw)
To: linux-pci, linuxppc-dev; +Cc: Sergey Miroshnichenko, Bjorn Helgaas, linux
In-Reply-To: <20190816165101.911-1-s.miroshnichenko@yadro.com>
This is the last patch in the series which implements the essentials of the
Movable BARs feature, so it is turned by default now. Tested on:
- x86_64 with "pci=realloc,assign-busses,use_crs,pcie_bus_peer2peer"
command line argument;
- POWER8 PowerNV+PHB3 ppc64le with "pci=realloc,pcie_bus_peer2peer".
In case of problems it is still can be overridden by the following command
line option:
pcie_movable_bars=off
Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
---
drivers/pci/pci-driver.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index d11909e79263..a8124e47bf6e 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1688,8 +1688,6 @@ static int __init pci_driver_init(void)
{
int ret;
- pci_add_flags(PCI_IMMOVABLE_BARS);
-
ret = bus_register(&pci_bus_type);
if (ret)
return ret;
--
2.21.0
^ permalink raw reply related
* [PATCH v5 21/23] nvme-pci: Handle movable BARs
From: Sergey Miroshnichenko @ 2019-08-16 16:50 UTC (permalink / raw)
To: linux-pci, linuxppc-dev
Cc: Sergey Miroshnichenko, Bjorn Helgaas, Christoph Hellwig,
linux-nvme, linux
In-Reply-To: <20190816165101.911-1-s.miroshnichenko@yadro.com>
Hotplugged devices can affect the existing ones by moving their BARs. The
PCI subsystem will inform the NVME driver about this by invoking the
.rescan_prepare() and .rescan_done() hooks, so the BARs can by re-mapped.
Tested under the "randrw" mode of the fio tool. Before the hotplugging:
% sudo cat /proc/iomem
...
3fe800000000-3fe8007fffff : PCI Bus 0020:0b
3fe800000000-3fe8007fffff : PCI Bus 0020:18
3fe800000000-3fe8000fffff : 0020:18:00.0
3fe800000000-3fe8000fffff : nvme
3fe800100000-3fe80017ffff : 0020:18:00.0
...
, then another NVME drive was hot-added, so BARs of the 0020:18:00.0 are
moved:
% sudo cat /proc/iomem
...
3fe800000000-3fe800ffffff : PCI Bus 0020:0b
3fe800000000-3fe8007fffff : PCI Bus 0020:10
3fe800000000-3fe800003fff : 0020:10:00.0
3fe800000000-3fe800003fff : nvme
3fe800010000-3fe80001ffff : 0020:10:00.0
3fe800800000-3fe800ffffff : PCI Bus 0020:18
3fe800800000-3fe8008fffff : 0020:18:00.0
3fe800800000-3fe8008fffff : nvme
3fe800900000-3fe80097ffff : 0020:18:00.0
...
During the rescanning, both READ and WRITE speeds drop to zero for a while
due to driver's pause, then restore.
Cc: linux-nvme@lists.infradead.org
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
---
drivers/nvme/host/pci.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index db160cee42ad..a805d80082ca 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1645,7 +1645,7 @@ 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 && size <= dev->bar_mapped_size)
return 0;
if (size > pci_resource_len(pdev, 0))
return -ENOMEM;
@@ -2980,6 +2980,23 @@ static void nvme_error_resume(struct pci_dev *pdev)
flush_work(&dev->ctrl.reset_work);
}
+static 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;
+}
+
+static 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,
@@ -3049,6 +3066,8 @@ static struct pci_driver nvme_driver = {
#endif
.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.21.0
^ permalink raw reply related
* [PATCH v5 22/23] PCI/portdrv: Declare support of movable BARs
From: Sergey Miroshnichenko @ 2019-08-16 16:51 UTC (permalink / raw)
To: linux-pci, linuxppc-dev; +Cc: Sergey Miroshnichenko, Bjorn Helgaas, linux
In-Reply-To: <20190816165101.911-1-s.miroshnichenko@yadro.com>
Switch's BARs are not used by the portdrv driver, but they are still
considered as immovable until the .rescan_prepare() and .rescan_done()
hooks are added. Add these hooks to increase chances to allocate new BARs.
Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
---
drivers/pci/pcie/portdrv_pci.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c
index 0a87091a0800..9dbddc7faaa7 100644
--- a/drivers/pci/pcie/portdrv_pci.c
+++ b/drivers/pci/pcie/portdrv_pci.c
@@ -197,6 +197,14 @@ static const struct pci_error_handlers pcie_portdrv_err_handler = {
.resume = pcie_portdrv_err_resume,
};
+static void pcie_portdrv_rescan_prepare(struct pci_dev *pdev)
+{
+}
+
+static void pcie_portdrv_rescan_done(struct pci_dev *pdev)
+{
+}
+
static struct pci_driver pcie_portdriver = {
.name = "pcieport",
.id_table = &port_pci_ids[0],
@@ -207,6 +215,9 @@ static struct pci_driver pcie_portdriver = {
.err_handler = &pcie_portdrv_err_handler,
+ .rescan_prepare = pcie_portdrv_rescan_prepare,
+ .rescan_done = pcie_portdrv_rescan_done,
+
.driver.pm = PCIE_PORTDRV_PM_OPS,
};
--
2.21.0
^ permalink raw reply related
* [PATCH v5 23/23] PCI: pciehp: movable BARs: Trigger a domain rescan on hp events
From: Sergey Miroshnichenko @ 2019-08-16 16:51 UTC (permalink / raw)
To: linux-pci, linuxppc-dev
Cc: Sergey Miroshnichenko, Lukas Wunner, Bjorn Helgaas, linux
In-Reply-To: <20190816165101.911-1-s.miroshnichenko@yadro.com>
With movable BARs, adding a hotplugged device is not local to its bridge
anymore, but it affects the whole domain: BARs, bridge windows and bus
numbers can be substantially rearranged. So instead of trying to fit the
new devices into preallocated reserved gaps, initiate a full domain rescan.
The pci_rescan_bus() covers all the operations of the replaced functions:
- assigning new bus numbers, as the pci_hp_add_bridge() does it;
- allocating BARs (pci_assign_unassigned_bridge_resources());
- cofiguring MPS settings (pcie_bus_configure_settings());
- binding devices to their drivers (pci_bus_add_devices()).
CC: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com>
---
drivers/pci/hotplug/pciehp_pci.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_pci.c b/drivers/pci/hotplug/pciehp_pci.c
index d17f3bf36f70..66c4e6d88fe3 100644
--- a/drivers/pci/hotplug/pciehp_pci.c
+++ b/drivers/pci/hotplug/pciehp_pci.c
@@ -58,6 +58,11 @@ int pciehp_configure_device(struct controller *ctrl)
goto out;
}
+ if (pci_movable_bars_enabled()) {
+ pci_rescan_bus(parent);
+ goto out;
+ }
+
for_each_pci_bridge(dev, parent)
pci_hp_add_bridge(dev);
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v4 1/3] kasan: support backing vmalloc space with real shadow memory
From: Mark Rutland @ 2019-08-16 17:08 UTC (permalink / raw)
To: Christophe Leroy
Cc: gor, x86, linux-kernel, kasan-dev, linux-mm, glider, luto,
aryabinin, linuxppc-dev, dvyukov, Daniel Axtens
In-Reply-To: <15c6110a-9e6e-495c-122e-acbde6e698d9@c-s.fr>
Hi Christophe,
On Fri, Aug 16, 2019 at 09:47:00AM +0200, Christophe Leroy wrote:
> Le 15/08/2019 à 02:16, Daniel Axtens a écrit :
> > Hook into vmalloc and vmap, and dynamically allocate real shadow
> > memory to back the mappings.
> >
> > Most mappings in vmalloc space are small, requiring less than a full
> > page of shadow space. Allocating a full shadow page per mapping would
> > therefore be wasteful. Furthermore, to ensure that different mappings
> > use different shadow pages, mappings would have to be aligned to
> > KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE.
> >
> > Instead, share backing space across multiple mappings. Allocate
> > a backing page the first time a mapping in vmalloc space uses a
> > particular page of the shadow region. Keep this page around
> > regardless of whether the mapping is later freed - in the mean time
> > the page could have become shared by another vmalloc mapping.
> >
> > This can in theory lead to unbounded memory growth, but the vmalloc
> > allocator is pretty good at reusing addresses, so the practical memory
> > usage grows at first but then stays fairly stable.
>
> I guess people having gigabytes of memory don't mind, but I'm concerned
> about tiny targets with very little amount of memory. I have boards with as
> little as 32Mbytes of RAM. The shadow region for the linear space already
> takes one eighth of the RAM. I'd rather avoid keeping unused shadow pages
> busy.
I think this depends on how much shadow would be in constant use vs what
would get left unused. If the amount in constant use is sufficiently
large (or the residue is sufficiently small), then it may not be
worthwhile to support KASAN_VMALLOC on such small systems.
> Each page of shadow memory represent 8 pages of real memory. Could we use
> page_ref to count how many pieces of a shadow page are used so that we can
> free it when the ref count decreases to 0.
>
> > This requires architecture support to actually use: arches must stop
> > mapping the read-only zero page over portion of the shadow region that
> > covers the vmalloc space and instead leave it unmapped.
>
> Why 'must' ? Couldn't we switch back and forth from the zero page to real
> page on demand ?
>
> If the zero page is not mapped for unused vmalloc space, bad memory accesses
> will Oops on the shadow memory access instead of Oopsing on the real bad
> access, making it more difficult to locate and identify the issue.
I agree this isn't nice, though FWIW this can already happen today for
bad addresses that fall outside of the usual kernel address space. We
could make the !KASAN_INLINE checks resilient to this by using
probe_kernel_read() to check the shadow, and treating unmapped shadow as
poison.
It's also worth noting that flipping back and forth isn't generally safe
unless going via an invalid table entry, so there'd still be windows
where a bad access might not have shadow mapped.
We'd need to reuse the common p4d/pud/pmd/pte tables for unallocated
regions, or the tables alone would consume significant amounts of memory
(e..g ~32GiB for arm64 defconfig), and thus we'd need to be able to
switch all levels between pgd and pte, which is much more complicated.
I strongly suspect that the additional complexity will outweigh the
benefit.
[...]
> > +#ifdef CONFIG_KASAN_VMALLOC
> > +static int kasan_populate_vmalloc_pte(pte_t *ptep, unsigned long addr,
> > + void *unused)
> > +{
> > + unsigned long page;
> > + pte_t pte;
> > +
> > + if (likely(!pte_none(*ptep)))
> > + return 0;
>
> Prior to this, the zero shadow area should be mapped, and the test should
> be:
>
> if (likely(pte_pfn(*ptep) != PHYS_PFN(__pa(kasan_early_shadow_page))))
> return 0;
As above, this would need a more comprehensive redesign, so I don't
think it's worth going into that level of nit here. :)
If we do try to use common shadow for unallocate VA ranges, it probably
makes sense to have a common poison page that we can use, so that we can
report vmalloc-out-of-bounfds.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH 6/6] arm64: document the choice of page attributes for pgprot_dmacoherent
From: Will Deacon @ 2019-08-16 17:31 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Shawn Anastasio, linux-m68k, Guan Xuetao, linuxppc-dev,
linux-kernel, Russell King, linux-mips, iommu, Geert Uytterhoeven,
Paul Burton, Catalin Marinas, James Hogan, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190816070754.15653-7-hch@lst.de>
Hi Christoph,
Thanks for spinning this into a patch.
On Fri, Aug 16, 2019 at 09:07:54AM +0200, Christoph Hellwig wrote:
> Based on an email from Will Deacon.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/arm64/include/asm/pgtable.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 6700371227d1..6ff221d9a631 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -435,6 +435,14 @@ static inline pmd_t pmd_mkdevmap(pmd_t pmd)
> __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
> #define pgprot_device(prot) \
> __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRE) | PTE_PXN | PTE_UXN)
> +/*
> + * DMA allocations for non-coherent devices use what the Arm architecture calls
> + * "Normal non-cacheable" memory, which permits speculation, unaligned accesses
> + * and merging of writes. This is different from "Strongly Ordered" memory
> + * which is intended for MMIO and thus forbids speculation, preserves access
> + * size, requires strict alignment and also forces write responses to come from
> + * the endpoint.
> + */
Mind if I tweak the second sentence to be:
This is different from "Device-nGnR[nE]" memory which is intended for MMIO
and thus forbids speculation, preserves access size, requires strict
alignment and can also force write responses to come from the endpoint.
? It's a small change, but it better fits with the arm64 terminology
("strongly ordered" is no longer used in the architecture).
If you're happy with that, I can make the change and queue this patch
for 5.4.
Thanks,
Will
^ permalink raw reply
* Re: [PATCH 6/6] arm64: document the choice of page attributes for pgprot_dmacoherent
From: Mark Rutland @ 2019-08-16 17:36 UTC (permalink / raw)
To: Will Deacon
Cc: Shawn Anastasio, linux-m68k, Catalin Marinas, linuxppc-dev,
linux-kernel, Russell King, linux-mips, iommu, Geert Uytterhoeven,
Paul Burton, James Hogan, Guan Xuetao, Christoph Hellwig,
linux-arm-kernel, Robin Murphy
In-Reply-To: <20190816173118.4rbbzuogfamfa554@willie-the-truck>
On Fri, Aug 16, 2019 at 06:31:18PM +0100, Will Deacon wrote:
> Hi Christoph,
>
> Thanks for spinning this into a patch.
>
> On Fri, Aug 16, 2019 at 09:07:54AM +0200, Christoph Hellwig wrote:
> > Based on an email from Will Deacon.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > ---
> > arch/arm64/include/asm/pgtable.h | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> > index 6700371227d1..6ff221d9a631 100644
> > --- a/arch/arm64/include/asm/pgtable.h
> > +++ b/arch/arm64/include/asm/pgtable.h
> > @@ -435,6 +435,14 @@ static inline pmd_t pmd_mkdevmap(pmd_t pmd)
> > __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
> > #define pgprot_device(prot) \
> > __pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRE) | PTE_PXN | PTE_UXN)
> > +/*
> > + * DMA allocations for non-coherent devices use what the Arm architecture calls
> > + * "Normal non-cacheable" memory, which permits speculation, unaligned accesses
> > + * and merging of writes. This is different from "Strongly Ordered" memory
> > + * which is intended for MMIO and thus forbids speculation, preserves access
> > + * size, requires strict alignment and also forces write responses to come from
> > + * the endpoint.
> > + */
>
> Mind if I tweak the second sentence to be:
>
> This is different from "Device-nGnR[nE]" memory which is intended for MMIO
> and thus forbids speculation, preserves access size, requires strict
> alignment and can also force write responses to come from the endpoint.
>
> ? It's a small change, but it better fits with the arm64 terminology
> ("strongly ordered" is no longer used in the architecture).
>
> If you're happy with that, I can make the change and queue this patch
> for 5.4.
FWIW, with that wording:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
^ permalink raw reply
* Re: [PATCH v4 1/3] kasan: support backing vmalloc space with real shadow memory
From: Andy Lutomirski @ 2019-08-16 17:41 UTC (permalink / raw)
To: Mark Rutland
Cc: Vasily Gorbik, X86 ML, LKML, kasan-dev, Linux-MM,
Alexander Potapenko, Andrew Lutomirski, Andrey Ryabinin,
linuxppc-dev, Dmitry Vyukov, Daniel Axtens
In-Reply-To: <20190816170813.GA7417@lakrids.cambridge.arm.com>
On Fri, Aug 16, 2019 at 10:08 AM Mark Rutland <mark.rutland@arm.com> wrote:
>
> Hi Christophe,
>
> On Fri, Aug 16, 2019 at 09:47:00AM +0200, Christophe Leroy wrote:
> > Le 15/08/2019 à 02:16, Daniel Axtens a écrit :
> > > Hook into vmalloc and vmap, and dynamically allocate real shadow
> > > memory to back the mappings.
> > >
> > > Most mappings in vmalloc space are small, requiring less than a full
> > > page of shadow space. Allocating a full shadow page per mapping would
> > > therefore be wasteful. Furthermore, to ensure that different mappings
> > > use different shadow pages, mappings would have to be aligned to
> > > KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE.
> > >
> > > Instead, share backing space across multiple mappings. Allocate
> > > a backing page the first time a mapping in vmalloc space uses a
> > > particular page of the shadow region. Keep this page around
> > > regardless of whether the mapping is later freed - in the mean time
> > > the page could have become shared by another vmalloc mapping.
> > >
> > > This can in theory lead to unbounded memory growth, but the vmalloc
> > > allocator is pretty good at reusing addresses, so the practical memory
> > > usage grows at first but then stays fairly stable.
> >
> > I guess people having gigabytes of memory don't mind, but I'm concerned
> > about tiny targets with very little amount of memory. I have boards with as
> > little as 32Mbytes of RAM. The shadow region for the linear space already
> > takes one eighth of the RAM. I'd rather avoid keeping unused shadow pages
> > busy.
>
> I think this depends on how much shadow would be in constant use vs what
> would get left unused. If the amount in constant use is sufficiently
> large (or the residue is sufficiently small), then it may not be
> worthwhile to support KASAN_VMALLOC on such small systems.
>
> > Each page of shadow memory represent 8 pages of real memory. Could we use
> > page_ref to count how many pieces of a shadow page are used so that we can
> > free it when the ref count decreases to 0.
> >
> > > This requires architecture support to actually use: arches must stop
> > > mapping the read-only zero page over portion of the shadow region that
> > > covers the vmalloc space and instead leave it unmapped.
> >
> > Why 'must' ? Couldn't we switch back and forth from the zero page to real
> > page on demand ?
> >
> > If the zero page is not mapped for unused vmalloc space, bad memory accesses
> > will Oops on the shadow memory access instead of Oopsing on the real bad
> > access, making it more difficult to locate and identify the issue.
>
> I agree this isn't nice, though FWIW this can already happen today for
> bad addresses that fall outside of the usual kernel address space. We
> could make the !KASAN_INLINE checks resilient to this by using
> probe_kernel_read() to check the shadow, and treating unmapped shadow as
> poison.
Could we instead modify the page fault handlers to detect this case
and print a useful message?
^ permalink raw reply
* Re: [PATCH 6/6] arm64: document the choice of page attributes for pgprot_dmacoherent
From: Christoph Hellwig @ 2019-08-16 17:59 UTC (permalink / raw)
To: Will Deacon
Cc: Shawn Anastasio, linux-m68k, Catalin Marinas, linuxppc-dev,
linux-kernel, Russell King, linux-mips, iommu, Geert Uytterhoeven,
Paul Burton, James Hogan, Guan Xuetao, Christoph Hellwig,
linux-arm-kernel, Robin Murphy
In-Reply-To: <20190816173118.4rbbzuogfamfa554@willie-the-truck>
On Fri, Aug 16, 2019 at 06:31:18PM +0100, Will Deacon wrote:
> Mind if I tweak the second sentence to be:
>
> This is different from "Device-nGnR[nE]" memory which is intended for MMIO
> and thus forbids speculation, preserves access size, requires strict
> alignment and can also force write responses to come from the endpoint.
>
> ? It's a small change, but it better fits with the arm64 terminology
> ("strongly ordered" is no longer used in the architecture).
>
> If you're happy with that, I can make the change and queue this patch
> for 5.4.
I'm fine with the change, but you really need this series as base,
as there is no pgprot_dmacoherent before the series. So I think I'll
have to queue it up if we want it for 5.4, and I'll need a few more
reviews for the other patches in this series first.
^ permalink raw reply
* [Bug 204371] BUG kmalloc-4k (Tainted: G W ): Object padding overwritten
From: bugzilla-daemon @ 2019-08-16 18:02 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-204371-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #36 from Erhard F. (erhard_f@mailbox.org) ---
On Fri, 16 Aug 2019 15:20:47 +0000
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=204371
>
> --- Comment #35 from Christophe Leroy (christophe.leroy@c-s.fr) ---
> That's good news. Will you handle submitting the patch to BTRFS file
> system ?
Thats nice of you. But as my part in this process was only searching &
replacing some code without deeper knowledge of what it's doing, I guess the
patch is yours. ;) Also if any questions or follow-up patches arise I am not
the right person to ask.
And probably I should test it on the G5 first, the 'BUG kmalloc-4k (Tainted: G
W ): Object padding overwritten' happened here too.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* Re: [PATCH 6/6] arm64: document the choice of page attributes for pgprot_dmacoherent
From: Will Deacon @ 2019-08-16 18:05 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Shawn Anastasio, linux-m68k, Guan Xuetao, linuxppc-dev,
linux-kernel, Russell King, linux-mips, iommu, Geert Uytterhoeven,
Paul Burton, Catalin Marinas, James Hogan, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190816175942.GA4879@lst.de>
On Fri, Aug 16, 2019 at 07:59:42PM +0200, Christoph Hellwig wrote:
> On Fri, Aug 16, 2019 at 06:31:18PM +0100, Will Deacon wrote:
> > Mind if I tweak the second sentence to be:
> >
> > This is different from "Device-nGnR[nE]" memory which is intended for MMIO
> > and thus forbids speculation, preserves access size, requires strict
> > alignment and can also force write responses to come from the endpoint.
> >
> > ? It's a small change, but it better fits with the arm64 terminology
> > ("strongly ordered" is no longer used in the architecture).
> >
> > If you're happy with that, I can make the change and queue this patch
> > for 5.4.
>
> I'm fine with the change, but you really need this series as base,
> as there is no pgprot_dmacoherent before the series. So I think I'll
> have to queue it up if we want it for 5.4, and I'll need a few more
> reviews for the other patches in this series first.
Ah, I didn't think about the contextual stuff. In which case, with my
change in wording:
Acked-by: Will Deacon <will@kernel.org>
and feel free to route it with the rest.
Thanks,
Will
^ permalink raw reply
* [Bug 204371] BUG kmalloc-4k (Tainted: G W ): Object padding overwritten
From: bugzilla-daemon @ 2019-08-16 20:51 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-204371-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #37 from Erhard F. (erhard_f@mailbox.org) ---
On Fri, 16 Aug 2019 15:20:47 +0000
bugzilla-daemon@bugzilla.kernel.org wrote:
Ok, tested the G5 + patch now. It boots from a btrfs partition with SLUB
debugging + btrfs debug & selftests enabled. So at least on the PowerPC side
everything is back to working condition again.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* Re: [PATCH v2 09/44] powerpc/64s/pseries: machine check convert to use common event code
From: Michael Ellerman @ 2019-08-16 22:25 UTC (permalink / raw)
To: kbuild test robot, Nicholas Piggin
Cc: linuxppc-dev, kbuild-all, Nicholas Piggin
In-Reply-To: <201908081219.GBBn7JtE%lkp@intel.com>
kbuild test robot <lkp@intel.com> writes:
> Hi Nicholas,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3-rc3 next-20190807]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/powerpc-64s-exception-cleanup-and-macrofiy/20190802-222211
> config: powerpc-defconfig (attached as .config)
> compiler: powerpc64-linux-gcc (GCC) 7.4.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=powerpc
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> arch/powerpc/platforms/pseries/ras.c: In function 'mce_handle_error':
>>> arch/powerpc/platforms/pseries/ras.c:563:28: error: this statement may fall through [-Werror=implicit-fallthrough=]
> mce_err.u.ue_error_type = MCE_UE_ERROR_IFETCH;
> ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
> arch/powerpc/platforms/pseries/ras.c:564:3: note: here
> case MC_ERROR_UE_PAGE_TABLE_WALK_IFETCH:
> ^~~~
> arch/powerpc/platforms/pseries/ras.c:565:28: error: this statement may fall through [-Werror=implicit-fallthrough=]
> mce_err.u.ue_error_type = MCE_UE_ERROR_PAGE_TABLE_WALK_IFETCH;
> ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> arch/powerpc/platforms/pseries/ras.c:566:3: note: here
> case MC_ERROR_UE_LOAD_STORE:
> ^~~~
> arch/powerpc/platforms/pseries/ras.c:567:28: error: this statement may fall through [-Werror=implicit-fallthrough=]
> mce_err.u.ue_error_type = MCE_UE_ERROR_LOAD_STORE;
> ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
> arch/powerpc/platforms/pseries/ras.c:568:3: note: here
> case MC_ERROR_UE_PAGE_TABLE_WALK_LOAD_STORE:
> ^~~~
> arch/powerpc/platforms/pseries/ras.c:569:28: error: this statement may fall through [-Werror=implicit-fallthrough=]
> mce_err.u.ue_error_type = MCE_UE_ERROR_PAGE_TABLE_WALK_LOAD_STORE;
> ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> arch/powerpc/platforms/pseries/ras.c:570:3: note: here
> case MC_ERROR_UE_INDETERMINATE:
> ^~~~
> cc1: all warnings being treated as errors
I think you meant to break in all these cases?
cheers
^ permalink raw reply
* Re: [PATCH 0/6] drm+dma: cache support for arm, etc
From: Rob Clark @ 2019-08-16 21:04 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Kate Stewart, Masayoshi Mizuma, Maciej W. Rozycki, Eric Biggers,
Catalin Marinas, Imre Deak, dri-devel, Chris Wilson,
Masahiro Yamada, Benjamin Gaignard, Mauro Carvalho Chehab,
Will Deacon, Emil Velikov, Deepak Sharma, Paul Burton,
Mike Rapoport, Geert Uytterhoeven,
moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), Daniel Vetter,
open list:MIPS, Linus Walleij, Robin Murphy,
open list:DRM DRIVER FOR MSM ADRENO GPU, Joerg Roedel,
Arnd Bergmann, Anshuman Khandual, Hauke Mehrtens,
Jesper Dangaard Brouer, Wolfram Sang (Renesas),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), Alexios Zavras,
Russell King, Doug Anderson, Thomas Gleixner, Sean Paul,
Allison Randal, Enrico Weigelt, Ard Biesheuvel,
Greg Kroah-Hartman, open list, Rob Clark, Souptick Joarder,
Andrew Morton, open list:DRM DRIVER FOR MSM ADRENO GPU,
christian.koenig
In-Reply-To: <20190815175346.GA19839@lst.de>
On Thu, Aug 15, 2019 at 10:53 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On Thu, Aug 15, 2019 at 06:54:39AM -0700, Rob Clark wrote:
> > On Wed, Aug 14, 2019 at 11:51 PM Christoph Hellwig <hch@lst.de> wrote:
> > >
> > > As said before I don't think these low-level helpers are the
> > > right API to export, but even if they did you'd just cover a tiny
> > > subset of the architectures.
> >
> > Are you thinking instead something like:
> >
> > void dma_sync_sg_for_{cpu,device}(struct device *dev, struct scatterlist *sgl,
> > int nents, enum dma_data_direction dir)
> > {
> > for_each_sg(sgl, sg, nents, i) {
> > arch_sync_dma_for_..(dev, sg_phys(sg), sg->length, dir);
> > }
> > }
> > EXPORT_SYMBOL_GPL(dma_sync_sg_for_..)
> >
> > or did you have something else in mind?
>
> No. We really need an interface thay says please give me uncached
> memory (for some definition of uncached that includes that grapics
> drivers call write combine), and then let the architecture do the right
> thing. Basically dma_alloc_coherent with DMA_ATTR_NO_KERNEL_MAPPING
> is superficially close to what you want, except that the way the drm
> drivers work you can't actually use it.
I don't disagree about needing an API to get uncached memory (or
ideally just something outside of the linear map). But I think this
is a separate problem.
What I was hoping for, for v5.4, is a way to stop abusing dma_map/sync
for cache ops to get rid of the hack I had to make for v5.3. And also
to fix vgem on non-x86. (Unfortunately changing vgem to used cached
mappings breaks x86 CI, but fixes CI on arm/arm64..) We can do that
without any changes in allocation. There is still the possibility for
problems due to cached alias, but that has been a problem this whole
time, it isn't something new.
BR,
-R
> The reason for that is if we can we really need to not create another
> uncachable alias, but instead change the page attributes in place.
> On x86 we can and must do that for example, and based on the
> conversation with Will arm64 could do that fairly easily. arm32 can
> right now only do that for CMA, though.
>
> The big question is what API do we want. I had a pretty similar
> discussion with Christian on doing such an allocation for amdgpu,
> where the device normally is cache coherent, but they actually want
> to turn it into non-coherent by using PCIe unsnooped transactions.
>
> Here is my high level plan, which still has a few lose end:
>
> (1) provide a new API:
>
> struct page *dma_alloc_pages(struct device *dev, unsigned nr_pages,
> gfp_t gfp, unsigned long flags);
> void dma_free_pages(struct device *dev, unsigned nr_pages,
> unsigned long flags);
>
> These give you back page backed memory that is guaranteed to be
> addressable by the device (no swiotlb or similar). The memory can
> then be mapped using dma_map*, including unmap and dma_sync to
> bounce ownership around. This is the replacement for the current
> dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT API, that is rather
> badly defined.
>
> (2) Add support for DMA_ATTR_NO_KERNEL_MAPPING to this new API instead
> of dma_alloc_attrs. The initial difference with that flag is just
> that we allow highmem, but in the future we could also unmap this
> memory from the kernel linear mapping entirely on architectures
> where we can easily do that.
>
> (3) Add a dma_pages_map/dma_pages_unmap or similar API that allows you
> to get a kernel mapping for parts or all of a
> DMA_ATTR_NO_KERNEL_MAPPING allocation. This is to replace things
> like your open-coded vmap in msm (or similarly elsewhere in dma-buf
> providers).
>
> (4) Add support for a DMA_ATTR_UNCACHABLE flags (or similar) to the new
> API, that maps the pages as uncachable iff they have a kernel
> mapping, including invalidating the caches at time of this page
> attribute change (or creation of a new mapping). This API will fail
> if the architecture does not allow in-place remapping. Note that for
> arm32 we could always dip into the CMA pool if one is present to not
> fail. We'll also need some helper to map from the DMA_ATTR_* flags
> to a pgprot for mapping the page to userspace. There is also a few
> other weird bits here, e.g. on architectures like mips that use an
> uncached segment we'll have to fail use with the plain
> DMA_ATTR_UNCACHABLE flag, but it could be supported with
> DMA_ATTR_UNCACHABLE | DMA_ATTR_NO_KERNEL_MAPPING.
>
> I was hoping to get most of this done for this merge window, but I'm
> probably lucky if I get at least parts done. Too much distraction.
>
> > Hmm, not entirely sure why.. you should be on the cc list for each
> > individual patch.
>
> They finally made it, although even with the delay they only ended up
> in the spam mailbox. I still can't see them on the various mailing
> lists.
^ permalink raw reply
* Re: [PATCH] ASoC: imx-audmux: Add driver suspend and resume to support MEGA Fast
From: S.j. Wang @ 2019-08-17 2:20 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arm-kernel@lists.infradead.org, alsa-devel@alsa-project.org,
linuxppc-dev@lists.ozlabs.org, timur@kernel.org,
Xiubo.Lee@gmail.com, shawnguo@kernel.org, s.hauer@pengutronix.de,
tiwai@suse.com, lgirdwood@gmail.com, perex@perex.cz,
nicoleotsuka@gmail.com, dl-linux-imx, kernel@pengutronix.de,
festevam@gmail.com, linux-kernel@vger.kernel.org
Hi Mark
>
> On Fri, Aug 16, 2019 at 01:03:14AM -0400, Shengjiu Wang wrote:
>
> > + for (i = 0; i < reg_max; i++)
> > + regcache[i] = readl(audmux_base + i * 4);
>
> If only there were some framework which provided a register cache! 😝
Yes, next step I can refine this driver to use the regmap.
Best regards
Wang shengjiu
^ permalink raw reply
* [PATCH] btrfs: fix allocation of bitmap pages.
From: Christophe Leroy @ 2019-08-17 7:44 UTC (permalink / raw)
To: erhard_f, Chris Mason, Josef Bacik, David Sterba, Andrew Morton
Cc: linux-mm, stable, linuxppc-dev, linux-kernel, linux-btrfs
Various notifications of type "BUG kmalloc-4096 () : Redzone
overwritten" have been observed recently in various parts of
the kernel. After some time, it has been made a relation with
the use of BTRFS filesystem.
[ 22.809700] BUG kmalloc-4096 (Tainted: G W ): Redzone overwritten
[ 22.809971] -----------------------------------------------------------------------------
[ 22.810286] INFO: 0xbe1a5921-0xfbfc06cd. First byte 0x0 instead of 0xcc
[ 22.810866] INFO: Allocated in __load_free_space_cache+0x588/0x780 [btrfs] age=22 cpu=0 pid=224
[ 22.811193] __slab_alloc.constprop.26+0x44/0x70
[ 22.811345] kmem_cache_alloc_trace+0xf0/0x2ec
[ 22.811588] __load_free_space_cache+0x588/0x780 [btrfs]
[ 22.811848] load_free_space_cache+0xf4/0x1b0 [btrfs]
[ 22.812090] cache_block_group+0x1d0/0x3d0 [btrfs]
[ 22.812321] find_free_extent+0x680/0x12a4 [btrfs]
[ 22.812549] btrfs_reserve_extent+0xec/0x220 [btrfs]
[ 22.812785] btrfs_alloc_tree_block+0x178/0x5f4 [btrfs]
[ 22.813032] __btrfs_cow_block+0x150/0x5d4 [btrfs]
[ 22.813262] btrfs_cow_block+0x194/0x298 [btrfs]
[ 22.813484] commit_cowonly_roots+0x44/0x294 [btrfs]
[ 22.813718] btrfs_commit_transaction+0x63c/0xc0c [btrfs]
[ 22.813973] close_ctree+0xf8/0x2a4 [btrfs]
[ 22.814107] generic_shutdown_super+0x80/0x110
[ 22.814250] kill_anon_super+0x18/0x30
[ 22.814437] btrfs_kill_super+0x18/0x90 [btrfs]
[ 22.814590] INFO: Freed in proc_cgroup_show+0xc0/0x248 age=41 cpu=0 pid=83
[ 22.814841] proc_cgroup_show+0xc0/0x248
[ 22.814967] proc_single_show+0x54/0x98
[ 22.815086] seq_read+0x278/0x45c
[ 22.815190] __vfs_read+0x28/0x17c
[ 22.815289] vfs_read+0xa8/0x14c
[ 22.815381] ksys_read+0x50/0x94
[ 22.815475] ret_from_syscall+0x0/0x38
Commit 69d2480456d1 ("btrfs: use copy_page for copying pages instead
of memcpy") changed the way bitmap blocks are copied. But allthough
bitmaps have the size of a page, they were allocated with kzalloc().
Most of the time, kzalloc() allocates aligned blocks of memory, so
copy_page() can be used. But when some debug options like SLAB_DEBUG
are activated, kzalloc() may return unaligned pointer.
On powerpc, memcpy(), copy_page() and other copying functions use
'dcbz' instruction which provides an entire zeroed cacheline to avoid
memory read when the intention is to overwrite a full line. Functions
like memcpy() are writen to care about partial cachelines at the start
and end of the destination, but copy_page() assumes it gets pages. As
pages are naturally cache aligned, copy_page() doesn't care about
partial lines. This means that when copy_page() is called with a
misaligned pointer, a few leading bytes are zeroed.
To fix it, allocate bitmaps with get_zeroed_page() instead of kzalloc()
Reported-by: Erhard F. <erhard_f@mailbox.org>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=204371
Fixes: 69d2480456d1 ("btrfs: use copy_page for copying pages instead of memcpy")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Tested-by: Erhard F. <erhard_f@mailbox.org>
---
fs/btrfs/free-space-cache.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 062be9dde4c6..3229a058e025 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -764,7 +764,7 @@ static int __load_free_space_cache(struct btrfs_root *root, struct inode *inode,
} else {
ASSERT(num_bitmaps);
num_bitmaps--;
- e->bitmap = kzalloc(PAGE_SIZE, GFP_NOFS);
+ e->bitmap = (void *)get_zeroed_page(GFP_NOFS);
if (!e->bitmap) {
kmem_cache_free(
btrfs_free_space_cachep, e);
@@ -1881,7 +1881,7 @@ static void free_bitmap(struct btrfs_free_space_ctl *ctl,
struct btrfs_free_space *bitmap_info)
{
unlink_free_space(ctl, bitmap_info);
- kfree(bitmap_info->bitmap);
+ free_page((unsigned long)bitmap_info->bitmap);
kmem_cache_free(btrfs_free_space_cachep, bitmap_info);
ctl->total_bitmaps--;
ctl->op->recalc_thresholds(ctl);
@@ -2135,7 +2135,7 @@ static int insert_into_bitmap(struct btrfs_free_space_ctl *ctl,
}
/* allocate the bitmap */
- info->bitmap = kzalloc(PAGE_SIZE, GFP_NOFS);
+ info->bitmap = (void *)get_zeroed_page(GFP_NOFS);
spin_lock(&ctl->tree_lock);
if (!info->bitmap) {
ret = -ENOMEM;
@@ -2146,7 +2146,7 @@ static int insert_into_bitmap(struct btrfs_free_space_ctl *ctl,
out:
if (info) {
- kfree(info->bitmap);
+ free_page((unsigned long)info->bitmap);
kmem_cache_free(btrfs_free_space_cachep, info);
}
@@ -2802,7 +2802,7 @@ u64 btrfs_alloc_from_cluster(struct btrfs_block_group_cache *block_group,
if (entry->bytes == 0) {
ctl->free_extents--;
if (entry->bitmap) {
- kfree(entry->bitmap);
+ free_page((unsigned long)entry->bitmap);
ctl->total_bitmaps--;
ctl->op->recalc_thresholds(ctl);
}
@@ -3606,7 +3606,7 @@ int test_add_free_space_entry(struct btrfs_block_group_cache *cache,
}
if (!map) {
- map = kzalloc(PAGE_SIZE, GFP_NOFS);
+ map = (void *)get_zeroed_page(GFP_NOFS);
if (!map) {
kmem_cache_free(btrfs_free_space_cachep, info);
return -ENOMEM;
@@ -3635,7 +3635,7 @@ int test_add_free_space_entry(struct btrfs_block_group_cache *cache,
if (info)
kmem_cache_free(btrfs_free_space_cachep, info);
- kfree(map);
+ free_page((unsigned long)map);
return 0;
}
--
2.17.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