* Re: [RFC PATCH v3 1/8] mm: page_alloc: avoid merging non-fallbackable pageblocks with others.
From: Zi Yan @ 2022-01-13 14:49 UTC (permalink / raw)
To: David Hildenbrand
Cc: Mel Gorman, linuxppc-dev, linux-kernel, virtualization, linux-mm,
iommu, Eric Ren, Robin Murphy, Christoph Hellwig, Vlastimil Babka,
Marek Szyprowski
In-Reply-To: <7dc078ef-70f4-159e-b928-34f0fb0ffaea@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 6230 bytes --]
On 12 Jan 2022, at 5:54, David Hildenbrand wrote:
> On 05.01.22 22:47, Zi Yan wrote:
>> From: Zi Yan <ziy@nvidia.com>
>>
>> This is done in addition to MIGRATE_ISOLATE pageblock merge avoidance.
>> It prepares for the upcoming removal of the MAX_ORDER-1 alignment
>> requirement for CMA and alloc_contig_range().
>>
>> MIGRARTE_HIGHATOMIC should not merge with other migratetypes like
>> MIGRATE_ISOLATE and MIGRARTE_CMA[1], so this commit prevents that too.
>> Also add MIGRARTE_HIGHATOMIC to fallbacks array for completeness.
>>
>> [1] https://lore.kernel.org/linux-mm/20211130100853.GP3366@techsingularity.net/
>>
>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>> ---
>> include/linux/mmzone.h | 6 ++++++
>> mm/page_alloc.c | 28 ++++++++++++++++++----------
>> 2 files changed, 24 insertions(+), 10 deletions(-)
>>
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index aed44e9b5d89..0aa549653e4e 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -83,6 +83,12 @@ static inline bool is_migrate_movable(int mt)
>> return is_migrate_cma(mt) || mt == MIGRATE_MOVABLE;
>> }
>>
>> +/* See fallbacks[MIGRATE_TYPES][3] in page_alloc.c */
>> +static inline bool migratetype_has_fallback(int mt)
>> +{
>> + return mt < MIGRATE_PCPTYPES;
>> +}
>> +
>> #define for_each_migratetype_order(order, type) \
>> for (order = 0; order < MAX_ORDER; order++) \
>> for (type = 0; type < MIGRATE_TYPES; type++)
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 8dd6399bafb5..5193c953dbf8 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -1042,6 +1042,12 @@ buddy_merge_likely(unsigned long pfn, unsigned long buddy_pfn,
>> return page_is_buddy(higher_page, higher_buddy, order + 1);
>> }
>>
>> +static inline bool has_non_fallback_pageblock(struct zone *zone)
>> +{
>> + return has_isolate_pageblock(zone) || zone_cma_pages(zone) != 0 ||
>> + zone->nr_reserved_highatomic != 0;
>> +}
>
> Due to zone_cma_pages(), the unlikely() below will be very wrong on many
> setups. Previously, isolation really was a corner case. CMA and
> highatomic are less of a corner case ...
Got it.
>
> I'm not even sure if this check is worth having around anymore at all,
> or if it would be easier and cheaper to just always check the both
> migration types unconditionally. Would certainly simplify the code.
I will remove the if check below, since, like you said, the check is
no longer a corner case with added highatomic and CMA check.
>
> Side node: we actually care about has_free_non_fallback_pageblock(), we
> can only merge with free pageblocks. But that might not necessarily be
> cheaper to test/track/check.
>
I agree that what we are actually looking for is free pageblocks of these
migratetypes. But tracking them is nontrivial.
>> +
>> /*
>> * Freeing function for a buddy system allocator.
>> *
>> @@ -1117,14 +1123,15 @@ static inline void __free_one_page(struct page *page,
>> }
>> if (order < MAX_ORDER - 1) {
>> /* If we are here, it means order is >= pageblock_order.
>> - * We want to prevent merge between freepages on isolate
>> - * pageblock and normal pageblock. Without this, pageblock
>> - * isolation could cause incorrect freepage or CMA accounting.
>> + * We want to prevent merge between freepages on pageblock
>> + * without fallbacks and normal pageblock. Without this,
>> + * pageblock isolation could cause incorrect freepage or CMA
>> + * accounting or HIGHATOMIC accounting.
>> *
>> * We don't want to hit this code for the more frequent
>> * low-order merging.
>> */
>> - if (unlikely(has_isolate_pageblock(zone))) {
>> + if (unlikely(has_non_fallback_pageblock(zone))) {
>> int buddy_mt;
>>
>> buddy_pfn = __find_buddy_pfn(pfn, order);
>> @@ -1132,8 +1139,8 @@ static inline void __free_one_page(struct page *page,
>> buddy_mt = get_pageblock_migratetype(buddy);
>>
>> if (migratetype != buddy_mt
>> - && (is_migrate_isolate(migratetype) ||
>> - is_migrate_isolate(buddy_mt)))
>> + && (!migratetype_has_fallback(migratetype) ||
>> + !migratetype_has_fallback(buddy_mt)))
>> goto done_merging;
>> }
>> max_order = order + 1;
>> @@ -2484,6 +2491,7 @@ static int fallbacks[MIGRATE_TYPES][3] = {
>> [MIGRATE_UNMOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE, MIGRATE_TYPES },
>> [MIGRATE_MOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE, MIGRATE_TYPES },
>> [MIGRATE_RECLAIMABLE] = { MIGRATE_UNMOVABLE, MIGRATE_MOVABLE, MIGRATE_TYPES },
>> + [MIGRATE_HIGHATOMIC] = { MIGRATE_TYPES }, /* Never used */
>> #ifdef CONFIG_CMA
>> [MIGRATE_CMA] = { MIGRATE_TYPES }, /* Never used */
>> #endif
>> @@ -2795,8 +2803,8 @@ static void reserve_highatomic_pageblock(struct page *page, struct zone *zone,
>>
>> /* Yoink! */
>> mt = get_pageblock_migratetype(page);
>> - if (!is_migrate_highatomic(mt) && !is_migrate_isolate(mt)
>> - && !is_migrate_cma(mt)) {
>> + /* Only reserve normal pageblock */
>> + if (migratetype_has_fallback(mt)) {
>> zone->nr_reserved_highatomic += pageblock_nr_pages;
>> set_pageblock_migratetype(page, MIGRATE_HIGHATOMIC);
>> move_freepages_block(zone, page, MIGRATE_HIGHATOMIC, NULL);
>> @@ -3545,8 +3553,8 @@ int __isolate_free_page(struct page *page, unsigned int order)
>> struct page *endpage = page + (1 << order) - 1;
>> for (; page < endpage; page += pageblock_nr_pages) {
>> int mt = get_pageblock_migratetype(page);
>> - if (!is_migrate_isolate(mt) && !is_migrate_cma(mt)
>> - && !is_migrate_highatomic(mt))
>> + /* Only change normal pageblock */
>> + if (migratetype_has_fallback(mt))
>> set_pageblock_migratetype(page,
>> MIGRATE_MOVABLE);
>> }
>
> That part is a nice cleanup IMHO. Although the "has fallback" part is a
> bit imprecise. "migratetype_is_mergable()" might be a bit clearer.
> ideally "migratetype_is_mergable_with_other_types()". Can we come up
> with a nice name for that?
Sure. Will change the name.
Thank you for the comments.
--
Best Regards,
Yan, Zi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: dts: t104xrdb: fix phy type for FMAN 4/5
From: Vladimir Oltean @ 2022-01-13 12:35 UTC (permalink / raw)
To: Maxim Kiselev
Cc: devicetree, linux-kernel, fido_max, Rob Herring, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20211230151123.1258321-1-bigunclemax@gmail.com>
On Thu, Dec 30, 2021 at 06:11:21PM +0300, Maxim Kiselev wrote:
> T1040RDB has two RTL8211E-VB phys which requires setting
> of internal delays for correct work.
>
> Changing the phy-connection-type property to `rgmii-id`
> will fix this issue.
>
> Signed-off-by: Maxim Kiselev <bigunclemax@gmail.com>
> Reviewed-by: Maxim Kochetkov <fido_max@inbox.ru>
> ---
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> arch/powerpc/boot/dts/fsl/t104xrdb.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/t104xrdb.dtsi b/arch/powerpc/boot/dts/fsl/t104xrdb.dtsi
> index 099a598c74c00..bfe1ed5be3374 100644
> --- a/arch/powerpc/boot/dts/fsl/t104xrdb.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/t104xrdb.dtsi
> @@ -139,12 +139,12 @@ pca9546@77 {
> fman@400000 {
> ethernet@e6000 {
> phy-handle = <&phy_rgmii_0>;
> - phy-connection-type = "rgmii";
> + phy-connection-type = "rgmii-id";
> };
>
> ethernet@e8000 {
> phy-handle = <&phy_rgmii_1>;
> - phy-connection-type = "rgmii";
> + phy-connection-type = "rgmii-id";
> };
>
> mdio0: mdio@fc000 {
> --
> 2.32.0
>
^ permalink raw reply
* Re: [RFC PATCH v3 1/8] mm: page_alloc: avoid merging non-fallbackable pageblocks with others.
From: David Hildenbrand @ 2022-01-13 12:28 UTC (permalink / raw)
To: Mike Rapoport
Cc: Mel Gorman, Eric Ren, linuxppc-dev, linux-kernel, virtualization,
linux-mm, iommu, Zi Yan, Robin Murphy, Christoph Hellwig,
Vlastimil Babka, Marek Szyprowski
In-Reply-To: <YeAO0vtyjWWMRliF@kernel.org>
On 13.01.22 12:36, Mike Rapoport wrote:
> On Wed, Jan 12, 2022 at 11:54:49AM +0100, David Hildenbrand wrote:
>> On 05.01.22 22:47, Zi Yan wrote:
>>> From: Zi Yan <ziy@nvidia.com>
>>>
>>> This is done in addition to MIGRATE_ISOLATE pageblock merge avoidance.
>>> It prepares for the upcoming removal of the MAX_ORDER-1 alignment
>>> requirement for CMA and alloc_contig_range().
>>>
>>> MIGRARTE_HIGHATOMIC should not merge with other migratetypes like
>>> MIGRATE_ISOLATE and MIGRARTE_CMA[1], so this commit prevents that too.
>>> Also add MIGRARTE_HIGHATOMIC to fallbacks array for completeness.
>>>
>>> [1] https://lore.kernel.org/linux-mm/20211130100853.GP3366@techsingularity.net/
>>>
>>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>>> ---
>>> include/linux/mmzone.h | 6 ++++++
>>> mm/page_alloc.c | 28 ++++++++++++++++++----------
>>> 2 files changed, 24 insertions(+), 10 deletions(-)
>>>
>
> ...
>
>>> @@ -3545,8 +3553,8 @@ int __isolate_free_page(struct page *page, unsigned int order)
>>> struct page *endpage = page + (1 << order) - 1;
>>> for (; page < endpage; page += pageblock_nr_pages) {
>>> int mt = get_pageblock_migratetype(page);
>>> - if (!is_migrate_isolate(mt) && !is_migrate_cma(mt)
>>> - && !is_migrate_highatomic(mt))
>>> + /* Only change normal pageblock */
>>> + if (migratetype_has_fallback(mt))
>>> set_pageblock_migratetype(page,
>>> MIGRATE_MOVABLE);
>>> }
>>
>> That part is a nice cleanup IMHO. Although the "has fallback" part is a
>> bit imprecise. "migratetype_is_mergable()" might be a bit clearer.
>> ideally "migratetype_is_mergable_with_other_types()". Can we come up
>> with a nice name for that?
>
> migratetype_is_mergable() kinda implies "_with_other_types", no?
>
> I like migratetype_is_mergable() more than _has_fallback().
>
> My $0.02 to bikeshedding :)
:)
Yeah, for me migratetype_is_mergable() would also be good enough. I
think I was at first thinking one could mistake it with a dedicated
migratetype. But such functions are historically called
is_migrate_cma/is_migrate_cma/....
--
Thanks,
David / dhildenb
^ permalink raw reply
* [PATCH v3] powerpc/papr_scm: Implement initial support for injecting smart errors
From: Vaibhav Jain @ 2022-01-13 12:02 UTC (permalink / raw)
To: nvdimm, linuxppc-dev
Cc: Shivaprasad G Bhat, Aneesh Kumar K . V, Vaibhav Jain,
Dan Williams, Ira Weiny
Presently PAPR doesn't support injecting smart errors on an
NVDIMM. This makes testing the NVDIMM health reporting functionality
difficult as simulating NVDIMM health related events need a hacked up
qemu version.
To solve this problem this patch proposes simulating certain set of
NVDIMM health related events in papr_scm. Specifically 'fatal' health
state and 'dirty' shutdown state. These error can be injected via the
user-space 'ndctl-inject-smart(1)' command. With the proposed patch and
corresponding ndctl patches following command flow is expected:
$ sudo ndctl list -DH -d nmem0
...
"health_state":"ok",
"shutdown_state":"clean",
...
# inject unsafe shutdown and fatal health error
$ sudo ndctl inject-smart nmem0 -Uf
...
"health_state":"fatal",
"shutdown_state":"dirty",
...
# uninject all errors
$ sudo ndctl inject-smart nmem0 -N
...
"health_state":"ok",
"shutdown_state":"clean",
...
The patch adds two members 'health_bitmap_mask' and
'health_bitmap_override' inside struct papr_scm_priv which are then
bit blt'ed to the health bitmaps fetched from the hypervisor. In case
we are not able to fetch health information from the hypervisor we
service the health bitmap from these two members. These members are
accessible from sysfs at nmemX/papr/health_bitmap_override
A new PDSM named 'SMART_INJECT' is proposed that accepts newly
introduced 'struct nd_papr_pdsm_smart_inject' as payload thats
exchanged between libndctl and papr_scm to indicate the requested
smart-error states.
When the processing the PDSM 'SMART_INJECT', papr_pdsm_smart_inject()
constructs a pair or 'mask' and 'override' bitmaps from the payload
and bit-blt it to the 'health_bitmap_{mask, override}' members. This
ensures the after being fetched from the hypervisor, the health_bitmap
reflects requested smart-error states.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
---
Changelog:
Since v2:
* Rebased the patch to ppc-next
* Added documentation for newly introduced sysfs attribute 'health_bitmap_override'
Since v1:
* Updated the patch description.
* Removed dependency of a header movement patch.
* Removed '__packed' attribute for 'struct nd_papr_pdsm_smart_inject' [Aneesh]
---
Documentation/ABI/testing/sysfs-bus-papr-pmem | 13 +++
arch/powerpc/include/uapi/asm/papr_pdsm.h | 18 ++++
arch/powerpc/platforms/pseries/papr_scm.c | 94 ++++++++++++++++++-
3 files changed, 122 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem
index 95254cec92bf..8a0b2a7f7671 100644
--- a/Documentation/ABI/testing/sysfs-bus-papr-pmem
+++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem
@@ -61,3 +61,16 @@ Description:
* "CchRHCnt" : Cache Read Hit Count
* "CchWHCnt" : Cache Write Hit Count
* "FastWCnt" : Fast Write Count
+
+What: /sys/bus/nd/devices/nmemX/papr/health_bitmap_override
+Date: Jan, 2022
+KernelVersion: v5.17
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
+Description:
+ (RO) Reports the health bitmap override/mask bitmaps that are
+ applied to top bitmap received from PowerVM via the H_SCM_HEALTH
+ Hcall. Together these can be used to forcibly set/reset specific
+ bits returned from Hcall. These bitmaps are presently used to
+ simulate various health or shutdown states for an nvdimm and are
+ set by user-space tools like ndctl by issuing a PAPR DSM.
+
diff --git a/arch/powerpc/include/uapi/asm/papr_pdsm.h b/arch/powerpc/include/uapi/asm/papr_pdsm.h
index 82488b1e7276..17439925045c 100644
--- a/arch/powerpc/include/uapi/asm/papr_pdsm.h
+++ b/arch/powerpc/include/uapi/asm/papr_pdsm.h
@@ -116,6 +116,22 @@ struct nd_papr_pdsm_health {
};
};
+/* Flags for injecting specific smart errors */
+#define PDSM_SMART_INJECT_HEALTH_FATAL (1 << 0)
+#define PDSM_SMART_INJECT_BAD_SHUTDOWN (1 << 1)
+
+struct nd_papr_pdsm_smart_inject {
+ union {
+ struct {
+ /* One or more of PDSM_SMART_INJECT_ */
+ __u32 flags;
+ __u8 fatal_enable;
+ __u8 unsafe_shutdown_enable;
+ };
+ __u8 buf[ND_PDSM_PAYLOAD_MAX_SIZE];
+ };
+};
+
/*
* Methods to be embedded in ND_CMD_CALL request. These are sent to the kernel
* via 'nd_cmd_pkg.nd_command' member of the ioctl struct
@@ -123,12 +139,14 @@ struct nd_papr_pdsm_health {
enum papr_pdsm {
PAPR_PDSM_MIN = 0x0,
PAPR_PDSM_HEALTH,
+ PAPR_PDSM_SMART_INJECT,
PAPR_PDSM_MAX,
};
/* Maximal union that can hold all possible payload types */
union nd_pdsm_payload {
struct nd_papr_pdsm_health health;
+ struct nd_papr_pdsm_smart_inject smart_inject;
__u8 buf[ND_PDSM_PAYLOAD_MAX_SIZE];
} __packed;
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index f48e87ac89c9..de4cf329cfb3 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -68,6 +68,10 @@
#define PAPR_SCM_PERF_STATS_EYECATCHER __stringify(SCMSTATS)
#define PAPR_SCM_PERF_STATS_VERSION 0x1
+/* Use bitblt method to override specific bits in the '_bitmap_' */
+#define BITBLT_BITMAP(_bitmap_, _mask_, _override_) \
+ (((_bitmap_) & ~(_mask_)) | ((_mask_) & (_override_)))
+
/* Struct holding a single performance metric */
struct papr_scm_perf_stat {
u8 stat_id[8];
@@ -120,6 +124,12 @@ struct papr_scm_priv {
/* length of the stat buffer as expected by phyp */
size_t stat_buffer_len;
+
+ /* The bits which needs to be overridden */
+ u64 health_bitmap_mask;
+
+ /* The overridden values for the bits having the masks set */
+ u64 health_bitmap_override;
};
static int papr_scm_pmem_flush(struct nd_region *nd_region,
@@ -347,19 +357,28 @@ static ssize_t drc_pmem_query_stats(struct papr_scm_priv *p,
static int __drc_pmem_query_health(struct papr_scm_priv *p)
{
unsigned long ret[PLPAR_HCALL_BUFSIZE];
+ u64 bitmap = 0;
long rc;
/* issue the hcall */
rc = plpar_hcall(H_SCM_HEALTH, ret, p->drc_index);
- if (rc != H_SUCCESS) {
+ if (rc == H_SUCCESS)
+ bitmap = ret[0] & ret[1];
+ else if (rc == H_FUNCTION)
+ dev_info_once(&p->pdev->dev,
+ "Hcall H_SCM_HEALTH not implemented, assuming empty health bitmap");
+ else {
+
dev_err(&p->pdev->dev,
"Failed to query health information, Err:%ld\n", rc);
return -ENXIO;
}
p->lasthealth_jiffies = jiffies;
- p->health_bitmap = ret[0] & ret[1];
-
+ /* Allow overriding specific health bits via bit blt. */
+ bitmap = BITBLT_BITMAP(bitmap, p->health_bitmap_mask,
+ p->health_bitmap_override);
+ WRITE_ONCE(p->health_bitmap, bitmap);
dev_dbg(&p->pdev->dev,
"Queried dimm health info. Bitmap:0x%016lx Mask:0x%016lx\n",
ret[0], ret[1]);
@@ -669,6 +688,54 @@ static int papr_pdsm_health(struct papr_scm_priv *p,
return rc;
}
+/* Inject a smart error Add the dirty-shutdown-counter value to the pdsm */
+static int papr_pdsm_smart_inject(struct papr_scm_priv *p,
+ union nd_pdsm_payload *payload)
+{
+ int rc;
+ u32 supported_flags = 0;
+ u64 mask = 0, override = 0;
+
+ /* Check for individual smart error flags and update mask and override */
+ if (payload->smart_inject.flags & PDSM_SMART_INJECT_HEALTH_FATAL) {
+ supported_flags |= PDSM_SMART_INJECT_HEALTH_FATAL;
+ mask |= PAPR_PMEM_HEALTH_FATAL;
+ override |= payload->smart_inject.fatal_enable ?
+ PAPR_PMEM_HEALTH_FATAL : 0;
+ }
+
+ if (payload->smart_inject.flags & PDSM_SMART_INJECT_BAD_SHUTDOWN) {
+ supported_flags |= PDSM_SMART_INJECT_BAD_SHUTDOWN;
+ mask |= PAPR_PMEM_SHUTDOWN_DIRTY;
+ override |= payload->smart_inject.unsafe_shutdown_enable ?
+ PAPR_PMEM_SHUTDOWN_DIRTY : 0;
+ }
+
+ dev_dbg(&p->pdev->dev, "[Smart-inject] Mask=%#llx override=%#llx\n",
+ mask, override);
+
+ /* Prevent concurrent access to dimm health bitmap related members */
+ rc = mutex_lock_interruptible(&p->health_mutex);
+ if (rc)
+ return rc;
+
+ /* Bitblt mask/override to corrosponding health_bitmap couterparts */
+ p->health_bitmap_mask = BITBLT_BITMAP(p->health_bitmap_mask,
+ mask, override);
+ p->health_bitmap_override = BITBLT_BITMAP(p->health_bitmap_override,
+ mask, override);
+
+ /* Invalidate cached health bitmap */
+ p->lasthealth_jiffies = 0;
+
+ mutex_unlock(&p->health_mutex);
+
+ /* Return the supported flags back to userspace */
+ payload->smart_inject.flags = supported_flags;
+
+ return sizeof(struct nd_papr_pdsm_health);
+}
+
/*
* 'struct pdsm_cmd_desc'
* Identifies supported PDSMs' expected length of in/out payloads
@@ -702,6 +769,12 @@ static const struct pdsm_cmd_desc __pdsm_cmd_descriptors[] = {
.size_out = sizeof(struct nd_papr_pdsm_health),
.service = papr_pdsm_health,
},
+
+ [PAPR_PDSM_SMART_INJECT] = {
+ .size_in = sizeof(struct nd_papr_pdsm_smart_inject),
+ .size_out = sizeof(struct nd_papr_pdsm_smart_inject),
+ .service = papr_pdsm_smart_inject,
+ },
/* Empty */
[PAPR_PDSM_MAX] = {
.size_in = 0,
@@ -838,6 +911,20 @@ static int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc,
return 0;
}
+static ssize_t health_bitmap_override_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct nvdimm *dimm = to_nvdimm(dev);
+ struct papr_scm_priv *p = nvdimm_provider_data(dimm);
+
+ return sprintf(buf, "mask=%#llx override=%#llx\n",
+ READ_ONCE(p->health_bitmap_mask),
+ READ_ONCE(p->health_bitmap_override));
+}
+
+static DEVICE_ATTR_ADMIN_RO(health_bitmap_override);
+
static ssize_t perf_stats_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -952,6 +1039,7 @@ static struct attribute *papr_nd_attributes[] = {
&dev_attr_flags.attr,
&dev_attr_perf_stats.attr,
&dev_attr_dirty_shutdown.attr,
+ &dev_attr_health_bitmap_override.attr,
NULL,
};
--
2.34.1
^ permalink raw reply related
* Re: [RFC PATCH v3 1/8] mm: page_alloc: avoid merging non-fallbackable pageblocks with others.
From: Mike Rapoport @ 2022-01-13 11:36 UTC (permalink / raw)
To: David Hildenbrand
Cc: Mel Gorman, Eric Ren, linuxppc-dev, linux-kernel, virtualization,
linux-mm, iommu, Zi Yan, Robin Murphy, Christoph Hellwig,
Vlastimil Babka, Marek Szyprowski
In-Reply-To: <7dc078ef-70f4-159e-b928-34f0fb0ffaea@redhat.com>
On Wed, Jan 12, 2022 at 11:54:49AM +0100, David Hildenbrand wrote:
> On 05.01.22 22:47, Zi Yan wrote:
> > From: Zi Yan <ziy@nvidia.com>
> >
> > This is done in addition to MIGRATE_ISOLATE pageblock merge avoidance.
> > It prepares for the upcoming removal of the MAX_ORDER-1 alignment
> > requirement for CMA and alloc_contig_range().
> >
> > MIGRARTE_HIGHATOMIC should not merge with other migratetypes like
> > MIGRATE_ISOLATE and MIGRARTE_CMA[1], so this commit prevents that too.
> > Also add MIGRARTE_HIGHATOMIC to fallbacks array for completeness.
> >
> > [1] https://lore.kernel.org/linux-mm/20211130100853.GP3366@techsingularity.net/
> >
> > Signed-off-by: Zi Yan <ziy@nvidia.com>
> > ---
> > include/linux/mmzone.h | 6 ++++++
> > mm/page_alloc.c | 28 ++++++++++++++++++----------
> > 2 files changed, 24 insertions(+), 10 deletions(-)
> >
...
> > @@ -3545,8 +3553,8 @@ int __isolate_free_page(struct page *page, unsigned int order)
> > struct page *endpage = page + (1 << order) - 1;
> > for (; page < endpage; page += pageblock_nr_pages) {
> > int mt = get_pageblock_migratetype(page);
> > - if (!is_migrate_isolate(mt) && !is_migrate_cma(mt)
> > - && !is_migrate_highatomic(mt))
> > + /* Only change normal pageblock */
> > + if (migratetype_has_fallback(mt))
> > set_pageblock_migratetype(page,
> > MIGRATE_MOVABLE);
> > }
>
> That part is a nice cleanup IMHO. Although the "has fallback" part is a
> bit imprecise. "migratetype_is_mergable()" might be a bit clearer.
> ideally "migratetype_is_mergable_with_other_types()". Can we come up
> with a nice name for that?
migratetype_is_mergable() kinda implies "_with_other_types", no?
I like migratetype_is_mergable() more than _has_fallback().
My $0.02 to bikeshedding :)
> --
> Thanks,
>
> David / dhildenb
>
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v2 2/2] powerpc/fadump: opt out from freeing pages on cma activation failure
From: David Hildenbrand @ 2022-01-13 8:31 UTC (permalink / raw)
To: Hari Bathini, akpm, linux-mm, mpe, linuxppc-dev
Cc: mike.kravetz, mahesh, sourabhjain, osalvador
In-Reply-To: <20220112193340.149020-3-hbathini@linux.ibm.com>
On 12.01.22 20:33, Hari Bathini wrote:
> With commit a4e92ce8e4c8 ("powerpc/fadump: Reservationless firmware
> assisted dump"), Linux kernel's Contiguous Memory Allocator (CMA)
> based reservation was introduced in fadump. That change was aimed at
> using CMA to let applications utilize the memory reserved for fadump
> while blocking it from being used for kernel pages. The assumption
> was, even if CMA activation fails for whatever reason, the memory
> still remains reserved to avoid it from being used for kernel pages.
> But commit 072355c1cf2d ("mm/cma: expose all pages to the buddy if
> activation of an area fails") breaks this assumption as it started
> exposing all pages to buddy allocator on CMA activation failure.
> It led to warning messages like below while running crash-utility
> on vmcore of a kernel having above two commits:
>
> crash: seek error: kernel virtual address: <from reserved region>
>
> To fix this problem, opt out from exposing pages to buddy allocator
> on CMA activation failure for fadump reserved memory.
>
> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
> ---
> arch/powerpc/kernel/fadump.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index b7ceb041743c..82058b52e34a 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -112,6 +112,12 @@ static int __init fadump_cma_init(void)
> return 1;
> }
>
> + /*
> + * If CMA activation fails, keep the pages reserved, instead of
> + * exposing them to buddy allocator. Same as 'fadump=nocma' case.
> + */
> + cma_reserve_pages_on_error(fadump_cma);
> +
> /*
> * So we now have successfully initialized cma area for fadump.
> */
Acked-by: David Hildenbrand <david@redhat.com>
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 1/2] mm/cma: provide option to opt out from exposing pages on activation failure
From: David Hildenbrand @ 2022-01-13 8:30 UTC (permalink / raw)
To: Hari Bathini, akpm, linux-mm, mpe, linuxppc-dev
Cc: mike.kravetz, mahesh, sourabhjain, osalvador
In-Reply-To: <20220112193340.149020-2-hbathini@linux.ibm.com>
> +{
> + if (!cma)
> + return;
Do we really need that check for NULL?
> +
> + cma->reserve_pages_on_error = true;
> +}
> +
> /**
> * cma_init_reserved_mem() - create custom contiguous area from reserved memory
> * @base: Base address of the reserved area
> @@ -204,6 +214,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
> cma->base_pfn = PFN_DOWN(base);
> cma->count = size >> PAGE_SHIFT;
> cma->order_per_bit = order_per_bit;
> + cma->reserve_pages_on_error = false;
I think you can drop that; should already be initialized to 0.
Apart from that
Reviewed-by: David Hildenbrand <david@redhat.com>
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [5.16.0] build error on unrecognized opcode: ptesync
From: Mike @ 2022-01-13 3:12 UTC (permalink / raw)
To: Christophe Leroy; +Cc: open list:LINUX FOR POWERPC...
In-Reply-To: <3b039cad-be82-3376-144c-bdee09c7adbf@csgroup.eu>
[-- Attachment #1: Type: text/plain, Size: 3777 bytes --]
Hmm, why on earth did it historically compile though, from what I gathered
before my hand fell off, -maltivec was removed from arch/powerpc/mm, I ran
out of hard drive compiling ofc. but it seems happy,
>Also please prefer CONFIG_PPC64 to __powerpc64__
Copy pasted the style in of the file... I usually consider the kernel a
place of sane code, as long as it's not a hurried vendor or so.
-mr pink hand
On Tue, Jan 11, 2022, 10:51 Christophe Leroy <christophe.leroy@csgroup.eu>
wrote:
>
>
> Le 11/01/2022 à 10:32, Mike a écrit :
> > I managed to fix it in the end, patch attached, though i should have
> > done a $(call cc-option-, -maltivec, -mabi=altivec) in the
> > arch/powerpc/mm/Makefile
> > I wrongly assumed that the manual i had downloaded at 4.44am was for
> > 32bit ppc only and found ptesync to be ppc64 only.
> >
> > binutils-2.37.50 - GNU assembler version 2.37.50 (powerpc-linux-gnu)
> > using BFD version (GNU Binutils for Debian) 2.37.50.20220106
> > gcc version 11.2.0 (Debian 11.2.0-13)
> > ld.lld is missing but with LLVM/CLANG and LD=ld.bfd
> > arch/powerpc/kernel/vdso32/gettimeofday.S:72:8:
> > error: unsupported directive '.stabs' .stabs
> > "_restgpr_31_x:F-1",36,0,0,_restgpr_31_x; .globl _restgpr_31_x;
> > _restgpr_31_x:
> >
> > Attached the config i'm using, and the debian config 5.15.0-2. It's
> > still building.
>
> Ok, I tried with your config on my Fedora Core 35 where I have:
>
> powerpc64-linux-gnu-gcc (GCC) 11.2.1 20210728 (Red Hat Cross 11.2.1-1)
> GNU ld version 2.37-3.fc35
>
> From packages:
> - binutils-powerpc64-linux-gnu-2.37-3.fc35.x86_64
> - gcc-powerpc64-linux-gnu-11.2.1-1.fc35.x86_64
>
> And I don't have the problems you mention, so it must be something
> special with Debian GCC.
>
>
> Your change regarding ptesync is probably OK but is fragile I think,
> because for instance there is also a 'ptesync' in
> arch/powerpc/mm/pageattr.c and probably many other places.
>
> Also please prefer CONFIG_PPC64 to __powerpc64__
>
> Regarding the DSSALL issue, the following commit will probably help:
>
> d51f86cfd8e3 ("powerpc/mm: Switch obsolete dssall to .long")
>
> Regarding the .stabs with LLVM there is a patch at
>
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/68932ec2ba6b868d35006b96e90f0890f3da3c05.1638273868.git.christophe.leroy@csgroup.eu/
>
> Thanks
> Christophe
>
>
>
> >
> > Cheers
> > Michael
> >
> > On Tue, 11 Jan 2022 at 07:20, Christophe Leroy
> > <christophe.leroy@csgroup.eu> wrote:
> >>
> >>
> >>
> >> Le 10/01/2022 à 13:32, Mike a écrit :
> >>> Hey, so I originally sat down to compile the fast headers V2 patch, but
> >>> quickly discovered other things at play, and grabbed 5.16.0 a few hours
> >>> after it lifted off, arch/powerpc/mm/mmu_context.c I had to
> >>> specifically say had to include -maltivec or it barfed on a 'dssall',
> >>> I'm fine with that, I've spent years in kernel land, I can deal with
> >>> that, then came arch/powerpc/lib/step.c with the ptesync. This seems
> >>> like a totally normal instruction that shouldn't need any extra flags
> or
> >>> anything, yet the assembler throws up, and no flag I can think of fixes
> >>> it. This is a G4 7447. I reverted back to the Debian 5.15. defconfig
> >>> before dropping this mail as I had tweaked my config to be more G4.
> >>>
> >>
> >> Hi Mike,
> >>
> >> Can you provide a bit more details about your setup and config ?
> >>
> >> Are you using GCC or LLVM ?
> >> What version of GCC and BINUTILS or what version of LLVM ?
> >>
> >> What is DEBIAN defconfig ? Does it correspond to one of the standard
> >> mainline kernel defconfigs ? If not can you provide it ?
> >>
> >> Thanks
> >> Christophe
[-- Attachment #2: Type: text/html, Size: 5000 bytes --]
^ permalink raw reply
* Re: Linux kernel: powerpc: KVM guest can trigger host crash on Power8
From: John Paul Adrian Glaubitz @ 2022-01-13 0:17 UTC (permalink / raw)
To: Michael Ellerman; +Cc: debian-powerpc@lists.debian.org, linuxppc-dev
In-Reply-To: <8aa4e710-df2d-8cb7-ba16-f6043c929a14@physik.fu-berlin.de>
Hi Michael!
On 1/9/22 23:17, John Paul Adrian Glaubitz wrote:
> On 1/7/22 12:20, John Paul Adrian Glaubitz wrote:
>>> Can you separately test with (on the host):
>>>
>>> # echo 0 > /sys/module/kvm_hv/parameters/dynamic_mt_modes
>>
>> I'm trying to turn off "dynamic_mt_modes" first and see if that makes any difference.
>>
>> I will report back.
>
> So far the machine is running stable now and the VM built gcc-9 without
> crashing the host. I will continue to monitor the machine and report back
> if it crashes, but it looks like this could be it.
So, it seems that setting "dynamic_mt_modes" actually did the trick, the host is no longer
crashing. However, I have observed on two occasions now that the build VM is just suddenly
off as if someone has shut it down using the "force-off" option in the virt-manager user
interface.
Not sure why that happens.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* [PATCH v2 2/2] powerpc/fadump: opt out from freeing pages on cma activation failure
From: Hari Bathini @ 2022-01-12 19:33 UTC (permalink / raw)
To: akpm, david, linux-mm, mpe, linuxppc-dev
Cc: Hari Bathini, mike.kravetz, mahesh, sourabhjain, osalvador
In-Reply-To: <20220112193340.149020-1-hbathini@linux.ibm.com>
With commit a4e92ce8e4c8 ("powerpc/fadump: Reservationless firmware
assisted dump"), Linux kernel's Contiguous Memory Allocator (CMA)
based reservation was introduced in fadump. That change was aimed at
using CMA to let applications utilize the memory reserved for fadump
while blocking it from being used for kernel pages. The assumption
was, even if CMA activation fails for whatever reason, the memory
still remains reserved to avoid it from being used for kernel pages.
But commit 072355c1cf2d ("mm/cma: expose all pages to the buddy if
activation of an area fails") breaks this assumption as it started
exposing all pages to buddy allocator on CMA activation failure.
It led to warning messages like below while running crash-utility
on vmcore of a kernel having above two commits:
crash: seek error: kernel virtual address: <from reserved region>
To fix this problem, opt out from exposing pages to buddy allocator
on CMA activation failure for fadump reserved memory.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
---
arch/powerpc/kernel/fadump.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index b7ceb041743c..82058b52e34a 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -112,6 +112,12 @@ static int __init fadump_cma_init(void)
return 1;
}
+ /*
+ * If CMA activation fails, keep the pages reserved, instead of
+ * exposing them to buddy allocator. Same as 'fadump=nocma' case.
+ */
+ cma_reserve_pages_on_error(fadump_cma);
+
/*
* So we now have successfully initialized cma area for fadump.
*/
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/2] mm/cma: provide option to opt out from exposing pages on activation failure
From: Hari Bathini @ 2022-01-12 19:33 UTC (permalink / raw)
To: akpm, david, linux-mm, mpe, linuxppc-dev
Cc: Hari Bathini, mike.kravetz, mahesh, sourabhjain, osalvador
In-Reply-To: <20220112193340.149020-1-hbathini@linux.ibm.com>
Commit 072355c1cf2d ("mm/cma: expose all pages to the buddy if
activation of an area fails") started exposing all pages to buddy
allocator on CMA activation failure. But there can be CMA users that
want to handle the reserved memory differently on CMA allocation
failure. Provide an option to opt out from exposing pages to buddy
for such cases.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
---
Changes in v2:
* Changed cma->free_pages_on_error to cma->reserve_pages_on_error and
cma_dont_free_pages_on_error() to cma_reserve_pages_on_error() to
avoid cofusion.
include/linux/cma.h | 2 ++
mm/cma.c | 15 +++++++++++++--
mm/cma.h | 1 +
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/include/linux/cma.h b/include/linux/cma.h
index bd801023504b..51d540eee18a 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -50,4 +50,6 @@ extern bool cma_pages_valid(struct cma *cma, const struct page *pages, unsigned
extern bool cma_release(struct cma *cma, const struct page *pages, unsigned long count);
extern int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data);
+
+extern void cma_reserve_pages_on_error(struct cma *cma);
#endif
diff --git a/mm/cma.c b/mm/cma.c
index bc9ca8f3c487..20626321f87f 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -131,8 +131,10 @@ static void __init cma_activate_area(struct cma *cma)
bitmap_free(cma->bitmap);
out_error:
/* Expose all pages to the buddy, they are useless for CMA. */
- for (pfn = base_pfn; pfn < base_pfn + cma->count; pfn++)
- free_reserved_page(pfn_to_page(pfn));
+ if (!cma->reserve_pages_on_error) {
+ for (pfn = base_pfn; pfn < base_pfn + cma->count; pfn++)
+ free_reserved_page(pfn_to_page(pfn));
+ }
totalcma_pages -= cma->count;
cma->count = 0;
pr_err("CMA area %s could not be activated\n", cma->name);
@@ -150,6 +152,14 @@ static int __init cma_init_reserved_areas(void)
}
core_initcall(cma_init_reserved_areas);
+void __init cma_reserve_pages_on_error(struct cma *cma)
+{
+ if (!cma)
+ return;
+
+ cma->reserve_pages_on_error = true;
+}
+
/**
* cma_init_reserved_mem() - create custom contiguous area from reserved memory
* @base: Base address of the reserved area
@@ -204,6 +214,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
cma->base_pfn = PFN_DOWN(base);
cma->count = size >> PAGE_SHIFT;
cma->order_per_bit = order_per_bit;
+ cma->reserve_pages_on_error = false;
*res_cma = cma;
cma_area_count++;
totalcma_pages += (size / PAGE_SIZE);
diff --git a/mm/cma.h b/mm/cma.h
index 2c775877eae2..88a0595670b7 100644
--- a/mm/cma.h
+++ b/mm/cma.h
@@ -30,6 +30,7 @@ struct cma {
/* kobject requires dynamic object */
struct cma_kobject *cma_kobj;
#endif
+ bool reserve_pages_on_error;
};
extern struct cma cma_areas[MAX_CMA_AREAS];
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/2] powerpc/fadump: handle CMA activation failure appropriately
From: Hari Bathini @ 2022-01-12 19:33 UTC (permalink / raw)
To: akpm, david, linux-mm, mpe, linuxppc-dev
Cc: Hari Bathini, mike.kravetz, mahesh, sourabhjain, osalvador
While commit a4e92ce8e4c8 ("powerpc/fadump: Reservationless firmware
assisted dump"), introduced Linux kernel's Contiguous Memory Allocator
(CMA) based reservation for fadump, it came with the assumption that
the memory remains reserved even if CMA activation fails. It ensures
no kernel pages reside in the reserved memory region, which can't be
mapped into the /proc/vmcore.
But commit 072355c1cf2d ("mm/cma: expose all pages to the buddy if
activation of an area fails") started returning all pages to buddy
allocator if CMA activation fails. This led to warning messages like
below while running crash-utility on vmcore of a kernel having above
two commits:
crash: seek error: kernel virtual address: <from reserved region>
as reserved memory region ended up having kernel pages crash-utility
was looking for. Fix this by introducing an option in CMA, to opt out
from exposing pages to buddy allocator, on CMA activation failure.
Changes in v2:
* Replaced cma->free_pages_on_error with cma->reserve_pages_on_error
& cma_dont_free_pages_on_error() with cma_reserve_pages_on_error()
to avoid confusion and make the expectation on failure clearer.
Hari Bathini (2):
mm/cma: provide option to opt out from exposing pages on activation
failure
powerpc/fadump: opt out from freeing pages on cma activation failure
arch/powerpc/kernel/fadump.c | 6 ++++++
include/linux/cma.h | 2 ++
mm/cma.c | 15 +++++++++++++--
mm/cma.h | 1 +
4 files changed, 22 insertions(+), 2 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v2] powerpc: dts: t1040rdb: fix ports names for Seville Ethernet switch
From: Vladimir Oltean @ 2022-01-12 18:50 UTC (permalink / raw)
To: Maxim
Cc: andrew@lunn.ch, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, fido_max@inbox.ru,
robh+dt@kernel.org, paulus@samba.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20220111173723.26212-1-bigunclemax@gmail.com>
On Tue, Jan 11, 2022 at 08:37:23PM +0300, Maxim wrote:
> From: Maxim Kiselev <bigunclemax@gmail.com>
>
> On board rev A, the network interface labels for the switch ports
> written on the front panel are different than on rev B and later.
>
> This patch fixes network interface names for the switch ports according
> to labels that are written on the front panel of the board rev B.
> They start from ETH3 and end at ETH10.
>
> This patch also introduces a separate device tree for rev A.
> The main device tree is supposed to cover rev B and later.
>
> Signed-off-by: Maxim Kiselev <bigunclemax@gmail.com>
> Reviewed-by: Maxim Kochetkov <fido_max@inbox.ru>
> ---
Fixes: e69eb0824d8c ("powerpc: dts: t1040rdb: add ports for Seville Ethernet switch")
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
^ permalink raw reply
* Re: [PATCH 3/6] KVM: Remove opaque from kvm_arch_check_processor_compat
From: Sean Christopherson @ 2022-01-12 17:21 UTC (permalink / raw)
To: Chao Gao
Cc: x86, Wanpeng Li, kvm, David Hildenbrand, Dave Hansen, linux-mips,
Atish Patra, Paul Mackerras, H. Peter Anvin, Alexander Gordeev,
Claudio Imbrenda, Will Deacon, Maciej S. Szmigiero, linux-s390,
Janosch Frank, Marc Zyngier, Joerg Roedel, Huacai Chen,
linux-riscv, kvmarm, Aleksandar Markovic, Ingo Molnar,
Catalin Marinas, Palmer Dabbelt, Christian Borntraeger,
Ravi Bangoria, kevin.tian, Albert Ou, Vasily Gorbik,
Suzuki K Poulose, Heiko Carstens, Nicholas Piggin,
Borislav Petkov, Cédric Le Goater, Paul Walmsley, tglx,
Alexandru Elisei, linux-arm-kernel, Jim Mattson,
Thomas Bogendoerfer, Fabiano Rosas, Anup Patel, linux-kernel,
Bharata B Rao, James Morse, kvm-riscv, pbonzini, Vitaly Kuznetsov,
linuxppc-dev
In-Reply-To: <Yd8N7PFqZbACzh2r@google.com>
On Wed, Jan 12, 2022, Sean Christopherson wrote:
> On Tue, Jan 11, 2022, Chao Gao wrote:
> > On Mon, Jan 10, 2022 at 11:06:44PM +0000, Sean Christopherson wrote:
> > >On Mon, Dec 27, 2021, Chao Gao wrote:
> > >> No arch implementation uses this opaque now.
> > >
> > >Except for the RISC-V part, this can be a pure revert of commit b99040853738 ("KVM:
> > >Pass kvm_init()'s opaque param to additional arch funcs"). I think it makes sense
> > >to process it as a revert, with a short blurb in the changelog to note that RISC-V
> > >is manually modified as RISC-V support came along in the interim.
> >
> > commit b99040853738 adds opaque param to kvm_arch_hardware_setup(), which isn't
> > reverted in this patch. I.e., this patch is a partial revert of b99040853738
> > plus manual changes to RISC-V. Given that, "process it as a revert" means
> > clearly say in changelog that this commit contains a partial revert of commit
> > b99040853738 ("KVM: Pass kvm_init()'s opaque param to additional arch funcs").
> >
> > Right?
>
> What I meant is literally do
>
> git revert -s b99040853738
>
> and then manually handle RISC-V.
Doh, to be clear, "manually handle RISC-V _in the same commit_".
^ permalink raw reply
* Re: [PATCH 3/6] KVM: Remove opaque from kvm_arch_check_processor_compat
From: Sean Christopherson @ 2022-01-12 17:20 UTC (permalink / raw)
To: Chao Gao
Cc: x86, Wanpeng Li, kvm, David Hildenbrand, Dave Hansen, linux-mips,
Atish Patra, Paul Mackerras, H. Peter Anvin, Alexander Gordeev,
Claudio Imbrenda, Will Deacon, Maciej S. Szmigiero, linux-s390,
Janosch Frank, Marc Zyngier, Joerg Roedel, Huacai Chen,
linux-riscv, kvmarm, Aleksandar Markovic, Ingo Molnar,
Catalin Marinas, Palmer Dabbelt, Christian Borntraeger,
Ravi Bangoria, kevin.tian, Albert Ou, Vasily Gorbik,
Suzuki K Poulose, Heiko Carstens, Nicholas Piggin,
Borislav Petkov, Cédric Le Goater, Paul Walmsley, tglx,
Alexandru Elisei, linux-arm-kernel, Jim Mattson,
Thomas Bogendoerfer, Fabiano Rosas, Anup Patel, linux-kernel,
Bharata B Rao, James Morse, kvm-riscv, pbonzini, Vitaly Kuznetsov,
linuxppc-dev
In-Reply-To: <20220111031933.GB2175@gao-cwp>
On Tue, Jan 11, 2022, Chao Gao wrote:
> On Mon, Jan 10, 2022 at 11:06:44PM +0000, Sean Christopherson wrote:
> >On Mon, Dec 27, 2021, Chao Gao wrote:
> >> No arch implementation uses this opaque now.
> >
> >Except for the RISC-V part, this can be a pure revert of commit b99040853738 ("KVM:
> >Pass kvm_init()'s opaque param to additional arch funcs"). I think it makes sense
> >to process it as a revert, with a short blurb in the changelog to note that RISC-V
> >is manually modified as RISC-V support came along in the interim.
>
> commit b99040853738 adds opaque param to kvm_arch_hardware_setup(), which isn't
> reverted in this patch. I.e., this patch is a partial revert of b99040853738
> plus manual changes to RISC-V. Given that, "process it as a revert" means
> clearly say in changelog that this commit contains a partial revert of commit
> b99040853738 ("KVM: Pass kvm_init()'s opaque param to additional arch funcs").
>
> Right?
What I meant is literally do
git revert -s b99040853738
and then manually handle RISC-V.
^ permalink raw reply
* Re: linux-next: manual merge of the audit tree with the powerpc tree
From: Paul Moore @ 2022-01-12 17:19 UTC (permalink / raw)
To: Christophe Leroy
Cc: Stephen Rothwell, Richard Guy Briggs, Linux Kernel Mailing List,
Linux Next Mailing List, Cédric Le Goater, PowerPC
In-Reply-To: <23e9c126-d167-254f-2f4b-391e9f01396c@csgroup.eu>
On Fri, Dec 17, 2021 at 9:11 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
> Le 17/12/2021 à 00:04, Paul Moore a écrit :
> > On Thu, Dec 16, 2021 at 4:08 AM Christophe Leroy
> > <christophe.leroy@csgroup.eu> wrote:
> >> Thanks Cédric, I've now been able to install debian PPC32 port of DEBIAN
> >> 11 on QEMU and run the tests.
> >>
> >> I followed instructions in file README.md provided in the test suite.
> >> I also modified tests/Makefile to force MODE := 32
> >>
> >> I've got a lot of failures, am I missing some options in the kernel or
> >> something ?
> >>
> >> Running as user root
> >> with context root:::
> >> on system
> >
> > While SELinux is not required for audit, I don't think I've ever run
> > it on system without SELinux. In theory the audit-testsuite shouldn't
> > rely on SELinux being present (other than the SELinux specific tests
> > of course), but I'm not confident enough to say that the test suite
> > will run without problem without SELinux.
> >
> > If it isn't too difficult, I would suggest enabling SELinux in your
> > kernel build and ensuring the necessary userspace, policy, etc. is
> > installed. You don't need to worry about getting it all running
> > correctly; the audit-testsuite should pass with SELinux in permissive
> > mode.
> >
> > If you're still seeing all these failures after trying that let us know.
> >
>
> Still the same it seems:
>
> Running as user root
> with context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> on system
>
> # Test 3 got: "256" (backlog_wait_time_actual_reset/test at line 151)
> # Expected: "0"
> # backlog_wait_time_actual_reset/test line 151 is: ok( $result, 0 );
> # Was an event found?
My apologies, this thread was lost in the end-of-year holidays.
At this point, and with that many failures, I think you'll need to
spend some time debugging the test failures to see what is wrong. I
don't have a PPC32 system/VM and I don't have the time right now to
build up a PPC32 test environment.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH 07/23] membarrier: Rewrite sync_core_before_usermode() and improve documentation
From: Mathieu Desnoyers @ 2022-01-12 16:11 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-arch, x86, Catalin Marinas, Will Deacon, riel,
Peter Zijlstra, Randy Dunlap, Dave Hansen, linuxppc-dev,
Nicholas Piggin, linux-mm, Paul Mackerras, stable, Andrew Morton,
Nadav Amit, linux-arm-kernel
In-Reply-To: <d2f76c148fa039d2dea404c03e5fcd2f3dbf3750.1641659630.git.luto@kernel.org>
----- On Jan 8, 2022, at 11:43 AM, Andy Lutomirski luto@kernel.org wrote:
> The old sync_core_before_usermode() comments suggested that a
> non-icache-syncing return-to-usermode instruction is x86-specific and that
> all other architectures automatically notice cross-modified code on return
> to userspace.
>
> This is misleading. The incantation needed to modify code from one
> CPU and execute it on another CPU is highly architecture dependent.
> On x86, according to the SDM, one must modify the code, issue SFENCE
> if the modification was WC or nontemporal, and then issue a "serializing
> instruction" on the CPU that will execute the code. membarrier() can do
> the latter.
>
> On arm, arm64 and powerpc, one must flush the icache and then flush the
> pipeline on the target CPU, although the CPU manuals don't necessarily use
> this language.
>
> So let's drop any pretense that we can have a generic way to define or
> implement membarrier's SYNC_CORE operation and instead require all
> architectures to define the helper and supply their own documentation as to
> how to use it. This means x86, arm64, and powerpc for now. Let's also
> rename the function from sync_core_before_usermode() to
> membarrier_sync_core_before_usermode() because the precise flushing details
> may very well be specific to membarrier, and even the concept of
> "sync_core" in the kernel is mostly an x86-ism.
>
> (It may well be the case that, on real x86 processors, synchronizing the
> icache (which requires no action at all) and "flushing the pipeline" is
> sufficient, but trying to use this language would be confusing at best.
> LFENCE does something awfully like "flushing the pipeline", but the SDM
> does not permit LFENCE as an alternative to a "serializing instruction"
> for this purpose.)
A few comments below:
[...]
> +# On powerpc, a program can use MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE
> +# similarly to arm64. It would be nice if the powerpc maintainers could
> +# add a more clear explanantion.
Any thoughts from ppc maintainers ?
[...]
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index e9da3dc71254..b47cd22b2eb1 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -17,7 +17,7 @@
> #include <linux/kprobes.h>
> #include <linux/mmu_context.h>
> #include <linux/bsearch.h>
> -#include <linux/sync_core.h>
> +#include <asm/sync_core.h>
All this churn wrt move from linux/sync_core.h to asm/sync_core.h
should probably be moved to a separate cleanup patch.
> #include <asm/text-patching.h>
> #include <asm/alternative.h>
> #include <asm/sections.h>
> diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
> index 193204aee880..a2529e09f620 100644
> --- a/arch/x86/kernel/cpu/mce/core.c
> +++ b/arch/x86/kernel/cpu/mce/core.c
> @@ -41,12 +41,12 @@
> #include <linux/irq_work.h>
> #include <linux/export.h>
> #include <linux/set_memory.h>
> -#include <linux/sync_core.h>
> #include <linux/task_work.h>
> #include <linux/hardirq.h>
>
> #include <asm/intel-family.h>
> #include <asm/processor.h>
> +#include <asm/sync_core.h>
> #include <asm/traps.h>
> #include <asm/tlbflush.h>
> #include <asm/mce.h>
[...]
> diff --git a/drivers/misc/sgi-gru/grufault.c b/drivers/misc/sgi-gru/grufault.c
> index d7ef61e602ed..462c667bd6c4 100644
> --- a/drivers/misc/sgi-gru/grufault.c
> +++ b/drivers/misc/sgi-gru/grufault.c
> @@ -20,8 +20,8 @@
> #include <linux/io.h>
> #include <linux/uaccess.h>
> #include <linux/security.h>
> -#include <linux/sync_core.h>
> #include <linux/prefetch.h>
> +#include <asm/sync_core.h>
> #include "gru.h"
> #include "grutables.h"
> #include "grulib.h"
> diff --git a/drivers/misc/sgi-gru/gruhandles.c
> b/drivers/misc/sgi-gru/gruhandles.c
> index 1d75d5e540bc..c8cba1c1b00f 100644
> --- a/drivers/misc/sgi-gru/gruhandles.c
> +++ b/drivers/misc/sgi-gru/gruhandles.c
> @@ -16,7 +16,7 @@
> #define GRU_OPERATION_TIMEOUT (((cycles_t) local_cpu_data->itc_freq)*10)
> #define CLKS2NSEC(c) ((c) *1000000000 / local_cpu_data->itc_freq)
> #else
> -#include <linux/sync_core.h>
> +#include <asm/sync_core.h>
> #include <asm/tsc.h>
> #define GRU_OPERATION_TIMEOUT ((cycles_t) tsc_khz*10*1000)
> #define CLKS2NSEC(c) ((c) * 1000000 / tsc_khz)
> diff --git a/drivers/misc/sgi-gru/grukservices.c
> b/drivers/misc/sgi-gru/grukservices.c
> index 0ea923fe6371..ce03ff3f7c3a 100644
> --- a/drivers/misc/sgi-gru/grukservices.c
> +++ b/drivers/misc/sgi-gru/grukservices.c
> @@ -16,10 +16,10 @@
> #include <linux/miscdevice.h>
> #include <linux/proc_fs.h>
> #include <linux/interrupt.h>
> -#include <linux/sync_core.h>
> #include <linux/uaccess.h>
> #include <linux/delay.h>
> #include <linux/export.h>
> +#include <asm/sync_core.h>
> #include <asm/io_apic.h>
> #include "gru.h"
> #include "grulib.h"
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index e8919995d8dd..e107f292fc42 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -7,7 +7,6 @@
> #include <linux/sched.h>
> #include <linux/mm_types.h>
> #include <linux/gfp.h>
> -#include <linux/sync_core.h>
>
> /*
> * Routines for handling mm_structs
> diff --git a/include/linux/sync_core.h b/include/linux/sync_core.h
> deleted file mode 100644
> index 013da4b8b327..000000000000
> --- a/include/linux/sync_core.h
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -#ifndef _LINUX_SYNC_CORE_H
> -#define _LINUX_SYNC_CORE_H
> -
> -#ifdef CONFIG_ARCH_HAS_SYNC_CORE_BEFORE_USERMODE
> -#include <asm/sync_core.h>
> -#else
> -/*
> - * This is a dummy sync_core_before_usermode() implementation that can be used
> - * on all architectures which return to user-space through core serializing
> - * instructions.
> - * If your architecture returns to user-space through non-core-serializing
> - * instructions, you need to write your own functions.
> - */
> -static inline void sync_core_before_usermode(void)
> -{
> -}
> -#endif
> -
> -#endif /* _LINUX_SYNC_CORE_H */
> -
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h
From: Christoph Hellwig @ 2022-01-12 16:09 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, linux-s390, Parisc List, the arch/x86 maintainers,
Jeff Layton, Linux Kernel Mailing List,
open list:BROADCOM NVRAM DRIVER, J. Bruce Fields, Guo Ren,
sparclinux, linuxppc-dev, Christoph Hellwig, Linux ARM
In-Reply-To: <CAK8P3a3FgHQ+w+Sj00yOERRLWfVhx7NYsGJ1NBAXQ0=is3G=Kg@mail.gmail.com>
On Wed, Jan 12, 2022 at 01:08:24PM +0100, Arnd Bergmann wrote:
> > I don't have a strong opinion here. If we were taking symbols away that
> > were previously visible to userland it would be one thing, but since
> > we're just adding symbols that may not have been there before, this
> > seems less likely to break anything.
>
> Changing
>
> #ifndef CONFIG_64BIT
>
> to
>
> #if __BITS_PER_LONG==32 || defined(__KERNEL__),
>
> would take symbols away, since the CONFIG_64BIT macro is never
> set in user space.
Yes.
> > I probably lean toward Christoph's original solution instead of keeping
> > the conditional definitions. It's hard to imagine there are many
> > programs that care whether these other symbols are defined or not.
> >
> > You can add this to the original patch:
> >
> > Acked-by: Jeff Layton <jlayton@kernel.org>
>
> Sounds good, thanks
So should we go ahead with the series as-is? Or respin it? Or add
the above change ontop?
^ permalink raw reply
* Re: [PATCH 06/23] powerpc/membarrier: Remove special barrier on mm switch
From: Mathieu Desnoyers @ 2022-01-12 15:57 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-arch, x86, riel, Peter Zijlstra, Randy Dunlap, Dave Hansen,
linuxppc-dev, Nicholas Piggin, linux-mm, Paul Mackerras,
Andrew Morton, Nadav Amit
In-Reply-To: <e1664cf686034204b8dd5dc1d2bf18e4058b00fd.1641659630.git.luto@kernel.org>
----- On Jan 8, 2022, at 11:43 AM, Andy Lutomirski luto@kernel.org wrote:
> powerpc did the following on some, but not all, paths through
> switch_mm_irqs_off():
>
> /*
> * Only need the full barrier when switching between processes.
> * Barrier when switching from kernel to userspace is not
> * required here, given that it is implied by mmdrop(). Barrier
> * when switching from userspace to kernel is not needed after
> * store to rq->curr.
> */
> if (likely(!(atomic_read(&next->membarrier_state) &
> (MEMBARRIER_STATE_PRIVATE_EXPEDITED |
> MEMBARRIER_STATE_GLOBAL_EXPEDITED)) || !prev))
> return;
>
> This is puzzling: if !prev, then one might expect that we are switching
> from kernel to user, not user to kernel, which is inconsistent with the
> comment. But this is all nonsense, because the one and only caller would
> never have prev == NULL and would, in fact, OOPS if prev == NULL.
>
> In any event, this code is unnecessary, since the new generic
> membarrier_finish_switch_mm() provides the same barrier without arch help.
>
> arch/powerpc/include/asm/membarrier.h remains as an empty header,
> because a later patch in this series will add code to it.
My disagreement with "membarrier: Make the post-switch-mm barrier explicit"
may affect this patch significantly, or even make it irrelevant.
Thanks,
Mathieu
>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
> arch/powerpc/include/asm/membarrier.h | 24 ------------------------
> arch/powerpc/mm/mmu_context.c | 1 -
> 2 files changed, 25 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/membarrier.h
> b/arch/powerpc/include/asm/membarrier.h
> index de7f79157918..b90766e95bd1 100644
> --- a/arch/powerpc/include/asm/membarrier.h
> +++ b/arch/powerpc/include/asm/membarrier.h
> @@ -1,28 +1,4 @@
> #ifndef _ASM_POWERPC_MEMBARRIER_H
> #define _ASM_POWERPC_MEMBARRIER_H
>
> -static inline void membarrier_arch_switch_mm(struct mm_struct *prev,
> - struct mm_struct *next,
> - struct task_struct *tsk)
> -{
> - /*
> - * Only need the full barrier when switching between processes.
> - * Barrier when switching from kernel to userspace is not
> - * required here, given that it is implied by mmdrop(). Barrier
> - * when switching from userspace to kernel is not needed after
> - * store to rq->curr.
> - */
> - if (IS_ENABLED(CONFIG_SMP) &&
> - likely(!(atomic_read(&next->membarrier_state) &
> - (MEMBARRIER_STATE_PRIVATE_EXPEDITED |
> - MEMBARRIER_STATE_GLOBAL_EXPEDITED)) || !prev))
> - return;
> -
> - /*
> - * The membarrier system call requires a full memory barrier
> - * after storing to rq->curr, before going back to user-space.
> - */
> - smp_mb();
> -}
> -
> #endif /* _ASM_POWERPC_MEMBARRIER_H */
> diff --git a/arch/powerpc/mm/mmu_context.c b/arch/powerpc/mm/mmu_context.c
> index 74246536b832..5f2daa6b0497 100644
> --- a/arch/powerpc/mm/mmu_context.c
> +++ b/arch/powerpc/mm/mmu_context.c
> @@ -84,7 +84,6 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct
> mm_struct *next,
> asm volatile ("dssall");
>
> if (!new_on_cpu)
> - membarrier_arch_switch_mm(prev, next, tsk);
>
> /*
> * The actual HW switching method differs between the various
> --
> 2.33.1
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [PATCH 1/1] powerpc/e500/qemu-e500: allow core to idle without waiting
From: Scott Wood @ 2022-01-12 12:36 UTC (permalink / raw)
To: Joachim Wiberg, linuxppc-dev, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras
Cc: Tobias Waldekranz
In-Reply-To: <20220112112459.1033754-1-troglobit@gmail.com>
On Wed, 2022-01-12 at 12:24 +0100, Joachim Wiberg wrote:
> From: Tobias Waldekranz <tobias@waldekranz.com>
>
> This means an idle guest won't needlessly consume an entire core on
> the host, waiting for work to show up.
>
> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
> Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
> ---
> arch/powerpc/platforms/85xx/qemu_e500.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/powerpc/platforms/85xx/qemu_e500.c
> b/arch/powerpc/platforms/85xx/qemu_e500.c
> index a4127b0b161f..4c4d577effd9 100644
> --- a/arch/powerpc/platforms/85xx/qemu_e500.c
> +++ b/arch/powerpc/platforms/85xx/qemu_e500.c
> @@ -67,4 +67,9 @@ define_machine(qemu_e500) {
> .get_irq = mpic_get_coreint_irq,
> .calibrate_decr = generic_calibrate_decr,
> .progress = udbg_progress,
> +#ifdef CONFIG_PPC64
> + .power_save = book3e_idle,
> +#else
> + .power_save = e500_idle,
> +#endif
> };
In the 32-bit case shouldn't this already be getting added by
setup_power_save()? Though I see corenet_generic.c doing the same thing...
-Scott
^ permalink raw reply
* Re: [PATCH v5] powerpc/pseries: read the lpar name from the firmware
From: Laurent Dufour @ 2022-01-12 13:10 UTC (permalink / raw)
To: Michael Ellerman, Tyrel Datwyler, linuxppc-dev, linux-kernel; +Cc: Nathan Lynch
In-Reply-To: <87zgo128x0.fsf@mpe.ellerman.id.au>
On 11/01/2022, 23:40:27, Michael Ellerman wrote:
> Tyrel Datwyler <tyreld@linux.ibm.com> writes:
>> On 1/6/22 8:13 AM, Laurent Dufour wrote:
>>> The LPAR name may be changed after the LPAR has been started in the HMC.
>>> In that case lparstat command is not reporting the updated value because it
>>> reads it from the device tree which is read at boot time.
>>>
>>> However this value could be read from RTAS.
>>>
>>> Adding this value in the /proc/powerpc/lparcfg output allows to read the
>>> updated value.
>>>
>>> However the hypervisor, like Qemu/KVM, may not support this RTAS
>>> parameter. In that case the value reported in lparcfg is read from the
>>> device tree and so is not updated accordingly.
>>>
>>> Cc: Nathan Lynch <nathanl@linux.ibm.com>
>>> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
>>
>> My only nit would be that in general for consistency with other function names
>> _RTAS_ and _DT_ should be lowercase. Seeing as they are statically scoped within
>> lparcfg.c maybe its ok. Otherwise,
>
> Yeah I agree, I changed them to lower case when applying.
Thanks Michael and Tyrel.
^ permalink raw reply
* Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h
From: Arnd Bergmann @ 2022-01-12 12:08 UTC (permalink / raw)
To: Jeff Layton
Cc: linux-arch, linux-s390, Parisc List, Arnd Bergmann,
the arch/x86 maintainers, Linux Kernel Mailing List,
open list:BROADCOM NVRAM DRIVER, J. Bruce Fields, Guo Ren,
sparclinux, linuxppc-dev, Christoph Hellwig, Linux ARM
In-Reply-To: <f86483fca8b0dc68ce243ba47998ff3296a3b6f8.camel@kernel.org>
On Wed, Jan 12, 2022 at 12:15 PM Jeff Layton <jlayton@kernel.org> wrote:
> On Wed, 2022-01-12 at 09:28 +0100, Arnd Bergmann wrote:
> > On Wed, Jan 12, 2022 at 8:56 AM Christoph Hellwig <hch@lst.de> wrote:
> >
> > Exactly, that is the tradeoff, which is why I'd like the flock maintainers
> > to say which way they prefer. We can either do it more correctly (hiding
> > the constants from user space when they are not usable), or with less
> > change (removing the incorrect #ifdef). Either way sounds reasonable
> > to me, I mainly care that this is explained in the changelog and that the
> > maintainers are aware of the two options.
> >
>
> I don't have a strong opinion here. If we were taking symbols away that
> were previously visible to userland it would be one thing, but since
> we're just adding symbols that may not have been there before, this
> seems less likely to break anything.
Changing
#ifndef CONFIG_64BIT
to
#if __BITS_PER_LONG==32 || defined(__KERNEL__),
would take symbols away, since the CONFIG_64BIT macro is never
set in user space.
> I probably lean toward Christoph's original solution instead of keeping
> the conditional definitions. It's hard to imagine there are many
> programs that care whether these other symbols are defined or not.
>
> You can add this to the original patch:
>
> Acked-by: Jeff Layton <jlayton@kernel.org>
Sounds good, thanks
Arnd
^ permalink raw reply
* [PATCH 1/1] powerpc/e500/qemu-e500: allow core to idle without waiting
From: Joachim Wiberg @ 2022-01-12 11:24 UTC (permalink / raw)
To: linuxppc-dev, Scott Wood, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras
Cc: Joachim Wiberg, Tobias Waldekranz
From: Tobias Waldekranz <tobias@waldekranz.com>
This means an idle guest won't needlessly consume an entire core on
the host, waiting for work to show up.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
---
arch/powerpc/platforms/85xx/qemu_e500.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/platforms/85xx/qemu_e500.c b/arch/powerpc/platforms/85xx/qemu_e500.c
index a4127b0b161f..4c4d577effd9 100644
--- a/arch/powerpc/platforms/85xx/qemu_e500.c
+++ b/arch/powerpc/platforms/85xx/qemu_e500.c
@@ -67,4 +67,9 @@ define_machine(qemu_e500) {
.get_irq = mpic_get_coreint_irq,
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
+#ifdef CONFIG_PPC64
+ .power_save = book3e_idle,
+#else
+ .power_save = e500_idle,
+#endif
};
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h
From: Jeff Layton @ 2022-01-12 11:15 UTC (permalink / raw)
To: Arnd Bergmann, Christoph Hellwig
Cc: linux-arch, linux-s390, Parisc List, the arch/x86 maintainers,
Linux Kernel Mailing List, open list:BROADCOM NVRAM DRIVER,
J. Bruce Fields, Guo Ren, sparclinux, linuxppc-dev, Linux ARM
In-Reply-To: <CAK8P3a1ONn=FiPU3669MjBMntS-1K5bgX4pHforUsYJ7yhwZ-g@mail.gmail.com>
On Wed, 2022-01-12 at 09:28 +0100, Arnd Bergmann wrote:
> On Wed, Jan 12, 2022 at 8:56 AM Christoph Hellwig <hch@lst.de> wrote:
> >
> > On Tue, Jan 11, 2022 at 04:33:30PM +0100, Arnd Bergmann wrote:
> > > This is a very subtle change to the exported UAPI header contents:
> > > On 64-bit architectures, the three unusable numbers are now always
> > > shown, rather than depending on a user-controlled symbol.
> >
> > Well, the change is bigger and less subtle. Before this change the
> > constants were never visible to userspace at all (except on mips),
> > because the #ifdef CONFIG_64BIT it never set for userspace builds.
>
> I suppose you mean /always/ visible here, with that ifndef.
>
> > > This is probably what we want here for compatibility reasons, but I think
> > > it should be explained in the changelog text, and I'd like Jeff or Bruce
> > > to comment on it as well: the alternative here would be to make the
> > > uapi definition depend on __BITS_PER_LONG==32, which is
> > > technically the right thing to do but more a of a change.
> >
> > I can change this to #if __BITS_PER_LONG==32 || defined(__KERNEL__),
> > but it will still be change in what userspace sees.
>
> Exactly, that is the tradeoff, which is why I'd like the flock maintainers
> to say which way they prefer. We can either do it more correctly (hiding
> the constants from user space when they are not usable), or with less
> change (removing the incorrect #ifdef). Either way sounds reasonable
> to me, I mainly care that this is explained in the changelog and that the
> maintainers are aware of the two options.
>
I don't have a strong opinion here. If we were taking symbols away that
were previously visible to userland it would be one thing, but since
we're just adding symbols that may not have been there before, this
seems less likely to break anything.
I probably lean toward Christoph's original solution instead of keeping
the conditional definitions. It's hard to imagine there are many
programs that care whether these other symbols are defined or not.
You can add this to the original patch:
Acked-by: Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [RFC PATCH v3 3/8] mm: migrate: allocate the right size of non hugetlb or THP compound pages.
From: David Hildenbrand @ 2022-01-12 11:04 UTC (permalink / raw)
To: Zi Yan, linux-mm
Cc: Mel Gorman, Robin Murphy, linux-kernel, iommu, Eric Ren,
virtualization, linuxppc-dev, Christoph Hellwig, Vlastimil Babka,
Marek Szyprowski
In-Reply-To: <20220105214756.91065-4-zi.yan@sent.com>
On 05.01.22 22:47, Zi Yan wrote:
> From: Zi Yan <ziy@nvidia.com>
>
> alloc_migration_target() is used by alloc_contig_range() and non-LRU
> movable compound pages can be migrated. Current code does not allocate the
> right page size for such pages. Check THP precisely using
> is_transparent_huge() and add allocation support for non-LRU compound
> pages.
IIRC, we don't have any non-lru migratable pages that are coumpound
pages. Read: not used and not supported :)
Why is this required in the context of this series?
--
Thanks,
David / dhildenb
^ permalink raw reply
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