* [PATCH 6/9] selftests/powerpc: Skip security tests on older CPUs
From: Michael Ellerman @ 2020-08-19 1:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20200819015727.1977134-1-mpe@ellerman.id.au>
Both these tests use PMU events that only work on newer CPUs, so skip
them on older CPUs.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
tools/testing/selftests/powerpc/security/rfi_flush.c | 3 +++
tools/testing/selftests/powerpc/security/spectre_v2.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/tools/testing/selftests/powerpc/security/rfi_flush.c b/tools/testing/selftests/powerpc/security/rfi_flush.c
index fd37ff9b1c45..93a65bd1f231 100644
--- a/tools/testing/selftests/powerpc/security/rfi_flush.c
+++ b/tools/testing/selftests/powerpc/security/rfi_flush.c
@@ -89,6 +89,9 @@ int rfi_flush_test(void)
SKIP_IF(geteuid() != 0);
+ // The PMU event we use only works on Power7 or later
+ SKIP_IF(!have_hwcap(PPC_FEATURE_ARCH_2_06));
+
if (read_debugfs_file("powerpc/rfi_flush", &rfi_flush_org)) {
perror("Unable to read powerpc/rfi_flush debugfs file");
SKIP_IF(1);
diff --git a/tools/testing/selftests/powerpc/security/spectre_v2.c b/tools/testing/selftests/powerpc/security/spectre_v2.c
index c8d82b784102..adc2b7294e5f 100644
--- a/tools/testing/selftests/powerpc/security/spectre_v2.c
+++ b/tools/testing/selftests/powerpc/security/spectre_v2.c
@@ -134,6 +134,9 @@ int spectre_v2_test(void)
s64 miss_percent;
bool is_p9;
+ // The PMU events we use only work on Power8 or later
+ SKIP_IF(!have_hwcap2(PPC_FEATURE2_ARCH_2_07));
+
state = get_sysfs_state();
if (state == UNKNOWN) {
printf("Error: couldn't determine spectre_v2 mitigation state?\n");
--
2.25.1
^ permalink raw reply related
* [PATCH 7/9] selftests/powerpc: Skip L3 bank test on older CPUs
From: Michael Ellerman @ 2020-08-19 1:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20200819015727.1977134-1-mpe@ellerman.id.au>
This is a test of specific piece of logic in isa207-common.c, which is
only used on Power8 or later. So skip it on older CPUs.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
tools/testing/selftests/powerpc/pmu/l3_bank_test.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/testing/selftests/powerpc/pmu/l3_bank_test.c b/tools/testing/selftests/powerpc/pmu/l3_bank_test.c
index a96d512a18c4..a5dfa9bf3b9f 100644
--- a/tools/testing/selftests/powerpc/pmu/l3_bank_test.c
+++ b/tools/testing/selftests/powerpc/pmu/l3_bank_test.c
@@ -20,6 +20,9 @@ static int l3_bank_test(void)
char *p;
int i;
+ // The L3 bank logic is only used on Power8 or later
+ SKIP_IF(!have_hwcap2(PPC_FEATURE2_ARCH_2_07));
+
p = malloc(MALLOC_SIZE);
FAIL_IF(!p);
--
2.25.1
^ permalink raw reply related
* [PATCH 8/9] selftests/powerpc: Don't touch VMX/VSX on older CPUs
From: Michael Ellerman @ 2020-08-19 1:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20200819015727.1977134-1-mpe@ellerman.id.au>
If we're running on a CPU without VMX/VSX then don't touch them. This
is fragile, the compiler could spill a VMX/VSX register and break the
test anyway. But in practice it seems to work, ie. the test runs to
completion on a system without VSX with this change.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
tools/testing/selftests/powerpc/benchmarks/context_switch.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/tools/testing/selftests/powerpc/benchmarks/context_switch.c b/tools/testing/selftests/powerpc/benchmarks/context_switch.c
index d50cc05df495..96554e2794d1 100644
--- a/tools/testing/selftests/powerpc/benchmarks/context_switch.c
+++ b/tools/testing/selftests/powerpc/benchmarks/context_switch.c
@@ -481,6 +481,12 @@ int main(int argc, char *argv[])
else
printf("futex");
+ if (!have_hwcap(PPC_FEATURE_HAS_ALTIVEC))
+ touch_altivec = 0;
+
+ if (!have_hwcap(PPC_FEATURE_HAS_VSX))
+ touch_vector = 0;
+
printf(" on cpus %d/%d touching FP:%s altivec:%s vector:%s vdso:%s\n",
cpu1, cpu2, touch_fp ? "yes" : "no", touch_altivec ? "yes" : "no",
touch_vector ? "yes" : "no", touch_vdso ? "yes" : "no");
--
2.25.1
^ permalink raw reply related
* [PATCH 9/9] selftests/powerpc: Properly handle failure in switch_endian_test
From: Michael Ellerman @ 2020-08-19 1:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20200819015727.1977134-1-mpe@ellerman.id.au>
On older CPUs the switch_endian() syscall doesn't work. Currently that
causes the switch_endian_test to just crash. Instead detect the
failure and properly exit with a failure message.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
.../switch_endian/switch_endian_test.S | 23 +++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/powerpc/switch_endian/switch_endian_test.S b/tools/testing/selftests/powerpc/switch_endian/switch_endian_test.S
index cc4930467235..7887f78cf072 100644
--- a/tools/testing/selftests/powerpc/switch_endian/switch_endian_test.S
+++ b/tools/testing/selftests/powerpc/switch_endian/switch_endian_test.S
@@ -3,9 +3,13 @@
.data
.balign 8
-message:
+success_message:
.ascii "success: switch_endian_test\n\0"
+ .balign 8
+failure_message:
+ .ascii "failure: switch_endian_test\n\0"
+
.section ".toc"
.balign 8
pattern:
@@ -64,6 +68,9 @@ FUNC_START(_start)
li r0, __NR_switch_endian
sc
+ tdi 0, 0, 0x48 // b +8 if the endian was switched
+ b .Lfail // exit if endian didn't switch
+
#include "check-reversed.S"
/* Flip back, r0 already has the switch syscall number */
@@ -71,12 +78,20 @@ FUNC_START(_start)
#include "check.S"
+ ld r4, success_message@got(%r2)
+ li r5, 28 // strlen(success_message)
+ li r14, 0 // exit status
+.Lout:
li r0, __NR_write
li r3, 1 /* stdout */
- ld r4, message@got(%r2)
- li r5, 28 /* strlen(message3) */
sc
li r0, __NR_exit
- li r3, 0
+ mr r3, r14
sc
b .
+
+.Lfail:
+ ld r4, failure_message@got(%r2)
+ li r5, 28 // strlen(failure_message)
+ li r14, 1
+ b .Lout
--
2.25.1
^ permalink raw reply related
* [PATCH v3] soc: fsl: enable acpi support
From: Ran Wang @ 2020-08-19 4:00 UTC (permalink / raw)
To: Li Yang; +Cc: Peng Ma, Ran Wang, linuxppc-dev, linux-kernel, linux-arm-kernel
From: Peng Ma <peng.ma@nxp.com>
This patch enables ACPI support in RCPM driver.
Signed-off-by: Peng Ma <peng.ma@nxp.com>
Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
---
Change in v3:
- Add #ifdef CONFIG_ACPI for acpi_device_id
- Rename rcpm_acpi_imx_ids to rcpm_acpi_ids
Change in v2:
- Update acpi_device_id to fix conflict with other driver
drivers/soc/fsl/rcpm.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
index a093dbe..55d1d73 100644
--- a/drivers/soc/fsl/rcpm.c
+++ b/drivers/soc/fsl/rcpm.c
@@ -2,7 +2,7 @@
//
// rcpm.c - Freescale QorIQ RCPM driver
//
-// Copyright 2019 NXP
+// Copyright 2019-2020 NXP
//
// Author: Ran Wang <ran.wang_1@nxp.com>
@@ -13,6 +13,7 @@
#include <linux/slab.h>
#include <linux/suspend.h>
#include <linux/kernel.h>
+#include <linux/acpi.h>
#define RCPM_WAKEUP_CELL_MAX_SIZE 7
@@ -125,6 +126,7 @@ static int rcpm_probe(struct platform_device *pdev)
ret = device_property_read_u32(&pdev->dev,
"#fsl,rcpm-wakeup-cells", &rcpm->wakeup_cells);
+
if (ret)
return ret;
@@ -139,10 +141,19 @@ static const struct of_device_id rcpm_of_match[] = {
};
MODULE_DEVICE_TABLE(of, rcpm_of_match);
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id rcpm_acpi_ids[] = {
+ {"NXP0015",},
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, rcpm_acpi_ids);
+#endif
+
static struct platform_driver rcpm_driver = {
.driver = {
.name = "rcpm",
.of_match_table = rcpm_of_match,
+ .acpi_match_table = ACPI_PTR(rcpm_acpi_ids),
.pm = &rcpm_pm_ops,
},
.probe = rcpm_probe,
--
2.7.4
^ permalink raw reply related
* Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full
From: Gerd Hoffmann @ 2020-08-19 4:35 UTC (permalink / raw)
To: Christian Zigotzky
Cc: Darren Stevens, R.T.Dickinson, daniel.vetter, Michel Dänzer,
kvm-ppc@vger.kernel.org, gurchetansingh,
Maling list - DRI developers, mad skateman, linuxppc-dev
In-Reply-To: <0f2434a5-edcf-e7d1-f6ae-7c912dc8d859@xenosoft.de>
On Tue, Aug 18, 2020 at 04:41:38PM +0200, Christian Zigotzky wrote:
> Hello Gerd,
>
> I compiled a new kernel with the latest DRM misc updates today. The patch is
> included in these updates.
>
> This kernel works with the VirtIO-GPU in a virtual e5500 QEMU/KVM HV machine
> on my X5000.
>
> Unfortunately I can only use the VirtIO-GPU (Monitor: Red Hat, Inc. 8") with
> a resolution of 640x480. If I set a higher resolution then the guest
> disables the monitor.
> I can use higher resolutions with the stable kernel 5.8 and the VirtIO-GPU.
>
> Please check the latest DRM updates.
https://patchwork.freedesktop.org/patch/385980/
(tests & reviews & acks are welcome)
HTH,
Gerd
^ permalink raw reply
* Re: [PATCH v3] powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in memory
From: Christoph Hellwig @ 2020-08-19 4:43 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: Konrad Rzeszutek Wilk, Robin Murphy, Ram Pai, linux-kernel, iommu,
Satheesh Rajendran, linuxppc-dev, Christoph Hellwig,
Marek Szyprowski
In-Reply-To: <20200818221126.391073-1-bauerman@linux.ibm.com>
On Tue, Aug 18, 2020 at 07:11:26PM -0300, Thiago Jung Bauermann wrote:
> POWER secure guests (i.e., guests which use the Protection Execution
> Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but
> they don't need the SWIOTLB memory to be in low addresses since the
> hypervisor doesn't have any addressing limitation.
>
> This solves a SWIOTLB initialization problem we are seeing in secure guests
> with 128 GB of RAM: they are configured with 4 GB of crashkernel reserved
> memory, which leaves no space for SWIOTLB in low addresses.
>
> To do this, we use mostly the same code as swiotlb_init(), but allocate the
> buffer using memblock_alloc() instead of memblock_alloc_low().
>
> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Looks fine to me (except for the pointlessly long comment lines, but I've
been told that's the powerpc way).
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: Do not initiate shutdown when system is running on UPS
From: Vasant Hegde @ 2020-08-19 5:25 UTC (permalink / raw)
To: Tyrel Datwyler, linuxppc-dev; +Cc: stable
In-Reply-To: <1e80a259-fc81-e7f9-8cd9-165e4bb9069a@linux.ibm.com>
On 8/19/20 1:05 AM, Tyrel Datwyler wrote:
> On 8/18/20 3:54 AM, Vasant Hegde wrote:
>> As per PAPR specification whenever system is running on UPS we have to
>> wait for predefined time (default 10mins) before initiating shutdown.
>
> The wording in PAPR seems a little unclear. It states for an
> EPOW_SYSTEM_SHUTDOWN action code that an EPOW error should be logged followed by
> scheduling a shutdown to begin after an OS defined delay interval (with 10
> minutes the suggested default).
>
> However, the modifier code descriptions seems to imply that a normal shutdown is
> the only one that should happen with no additional delay.
>
> For EPOW sensor value = 3 (EPOW_SYSTEM_SHUTDOWN)
> 0x01 = Normal system shutdown with no additional delay
> 0x02 = Loss of utility power, system is running on UPS/Battery
> 0x03 = Loss of system critical functions, system should be shutdown
> 0x04 = Ambient temperature too high
>
> For 0x03-0x04 we also do an orderly_poweroff().
>
> Not sure if it really matters, but I was curious and this is just what I gleaned
> from glancing at PAPR.
Correct. PAPR is bit confusing. But we know for sure that when running on UPS we
don't need to shutdown immediately.
For values 0x03 and 0x04 I think its ok to initiate shutdown (that's the same
behaviour exists for long time). I can double check with firmware folks.
-Vasant
>
> -Tyrel
>
>>
>> We have user space tool (rtas_errd) to monitor for EPOW events and
>> initiate shutdown after predefined time. Hence do not initiate shutdown
>> whenever we get EPOW_SHUTDOWN_ON_UPS event.
>>
>> Fixes: 79872e35 (powerpc/pseries: All events of EPOW_SYSTEM_SHUTDOWN must initiate shutdown)
>> Cc: stable@vger.kernel.org # v4.0+
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/platforms/pseries/ras.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
>> index f3736fcd98fc..13c86a292c6d 100644
>> --- a/arch/powerpc/platforms/pseries/ras.c
>> +++ b/arch/powerpc/platforms/pseries/ras.c
>> @@ -184,7 +184,6 @@ static void handle_system_shutdown(char event_modifier)
>> case EPOW_SHUTDOWN_ON_UPS:
>> pr_emerg("Loss of system power detected. System is running on"
>> " UPS/battery. Check RTAS error log for details\n");
>> - orderly_poweroff(true);
>> break;
>>
>> case EPOW_SHUTDOWN_LOSS_OF_CRITICAL_FUNCTIONS:
>>
>
^ permalink raw reply
* [PATCH net-next 0/5] refactoring of ibmvnic code
From: Lijun Pan @ 2020-08-19 5:35 UTC (permalink / raw)
To: netdev; +Cc: Lijun Pan, linuxppc-dev
This patch series refactor reset_init and init functions,
improve the debugging messages, and make some other cosmetic changes
to make the code easier to read and debug.
Lijun Pan (5):
ibmvnic: print caller in several error messages
ibmvnic: compare adapter->init_done_rc with more readable
ibmvnic_rc_codes
ibmvnic: improve ibmvnic_init and ibmvnic_reset_init
ibmvnic: remove never executed if statement
ibmvnic: merge ibmvnic_reset_init and ibmvnic_init
drivers/net/ethernet/ibm/ibmvnic.c | 98 +++++++++---------------------
1 file changed, 28 insertions(+), 70 deletions(-)
--
2.23.0
^ permalink raw reply
* [PATCH net-next 2/5] ibmvnic: compare adapter->init_done_rc with more readable ibmvnic_rc_codes
From: Lijun Pan @ 2020-08-19 5:35 UTC (permalink / raw)
To: netdev; +Cc: Lijun Pan, linuxppc-dev
In-Reply-To: <20200819053512.3619-1-ljp@linux.ibm.com>
Instead of comparing (adapter->init_done_rc == 1), let it
be (adapter->init_done_rc == PARTIALSUCCESS).
Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index aba1cd9862ac..50e86e65961e 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -974,7 +974,7 @@ static int set_link_state(struct ibmvnic_adapter *adapter, u8 link_state)
return -1;
}
- if (adapter->init_done_rc == 1) {
+ if (adapter->init_done_rc == PARTIALSUCCESS) {
/* Partuial success, delay and re-send */
mdelay(1000);
resend = true;
--
2.23.0
^ permalink raw reply related
* [PATCH net-next 1/5] ibmvnic: print caller in several error messages
From: Lijun Pan @ 2020-08-19 5:35 UTC (permalink / raw)
To: netdev; +Cc: Lijun Pan, linuxppc-dev
In-Reply-To: <20200819053512.3619-1-ljp@linux.ibm.com>
The error messages in the changed functions are exactly the same.
In order to differentiate them and make debugging easier,
we print the function names in the error messages.
Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 5afb3c9c52d2..aba1cd9862ac 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1864,7 +1864,7 @@ static int do_change_param_reset(struct ibmvnic_adapter *adapter,
if (rc) {
netdev_err(adapter->netdev,
- "Couldn't initialize crq. rc=%d\n", rc);
+ "%s: Couldn't initialize crq. rc=%d\n", __func__, rc);
return rc;
}
@@ -2089,7 +2089,7 @@ static int do_hard_reset(struct ibmvnic_adapter *adapter,
rc = init_crq_queue(adapter);
if (rc) {
netdev_err(adapter->netdev,
- "Couldn't initialize crq. rc=%d\n", rc);
+ "%s: Couldn't initialize crq. rc=%d\n", __func__, rc);
return rc;
}
@@ -2912,7 +2912,7 @@ static struct ibmvnic_sub_crq_queue *init_sub_crq_queue(struct ibmvnic_adapter
rc = ibmvnic_reset_crq(adapter);
if (rc == H_CLOSED) {
- dev_warn(dev, "Partner adapter not ready, waiting.\n");
+ dev_warn(dev, "%s: Partner adapter not ready, waiting.\n", __func__);
} else if (rc) {
dev_warn(dev, "Error %d registering sub-crq\n", rc);
goto reg_failed;
@@ -4865,7 +4865,7 @@ static int ibmvnic_reset_crq(struct ibmvnic_adapter *adapter)
if (rc == H_CLOSED)
/* Adapter is good, but other end is not ready */
- dev_warn(dev, "Partner adapter not ready\n");
+ dev_warn(dev, "%s: Partner adapter not ready\n", __func__);
else if (rc != 0)
dev_warn(dev, "Couldn't register crq (rc=%d)\n", rc);
@@ -4926,7 +4926,7 @@ static int init_crq_queue(struct ibmvnic_adapter *adapter)
retrc = rc;
if (rc == H_CLOSED) {
- dev_warn(dev, "Partner adapter not ready\n");
+ dev_warn(dev, "%s: Partner adapter not ready\n", __func__);
} else if (rc) {
dev_warn(dev, "Error %d opening adapter\n", rc);
goto reg_crq_failed;
@@ -5129,8 +5129,8 @@ static int ibmvnic_probe(struct vio_dev *dev, const struct vio_device_id *id)
do {
rc = init_crq_queue(adapter);
if (rc) {
- dev_err(&dev->dev, "Couldn't initialize crq. rc=%d\n",
- rc);
+ dev_err(&dev->dev, "%s: Couldn't initialize crq. rc=%d\n",
+ __func__, rc);
goto ibmvnic_init_fail;
}
--
2.23.0
^ permalink raw reply related
* [PATCH net-next 3/5] ibmvnic: improve ibmvnic_init and ibmvnic_reset_init
From: Lijun Pan @ 2020-08-19 5:35 UTC (permalink / raw)
To: netdev; +Cc: Lijun Pan, linuxppc-dev
In-Reply-To: <20200819053512.3619-1-ljp@linux.ibm.com>
When H_SEND_CRQ command returns with H_CLOSED, it means the
server's CRQ is not ready yet. Instead of resetting immediately,
we wait for the server to launch passive init.
ibmvnic_init() and ibmvnic_reset_init() should also return the
error code from ibmvnic_send_crq_init() call.
Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 50e86e65961e..e366fd42a8c4 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -3568,8 +3568,7 @@ static int ibmvnic_send_crq(struct ibmvnic_adapter *adapter,
if (rc) {
if (rc == H_CLOSED) {
dev_warn(dev, "CRQ Queue closed\n");
- if (test_bit(0, &adapter->resetting))
- ibmvnic_reset(adapter, VNIC_RESET_FATAL);
+ /* do not reset, report the fail, wait for passive init from server */
}
dev_warn(dev, "Send error (rc=%d)\n", rc);
@@ -4985,7 +4984,12 @@ static int ibmvnic_reset_init(struct ibmvnic_adapter *adapter)
reinit_completion(&adapter->init_done);
adapter->init_done_rc = 0;
- ibmvnic_send_crq_init(adapter);
+ rc = ibmvnic_send_crq_init(adapter);
+ if (rc) {
+ dev_err(dev, "%s: Send crq init failed with error %d\n", __func__, rc);
+ return rc;
+ }
+
if (!wait_for_completion_timeout(&adapter->init_done, timeout)) {
dev_err(dev, "Initialization sequence timed out\n");
return -1;
@@ -5039,7 +5043,12 @@ static int ibmvnic_init(struct ibmvnic_adapter *adapter)
adapter->from_passive_init = false;
adapter->init_done_rc = 0;
- ibmvnic_send_crq_init(adapter);
+ rc = ibmvnic_send_crq_init(adapter);
+ if (rc) {
+ dev_err(dev, "%s: Send crq init failed with error %d\n", __func__, rc);
+ return rc;
+ }
+
if (!wait_for_completion_timeout(&adapter->init_done, timeout)) {
dev_err(dev, "Initialization sequence timed out\n");
return -1;
--
2.23.0
^ permalink raw reply related
* [PATCH net-next 4/5] ibmvnic: remove never executed if statement
From: Lijun Pan @ 2020-08-19 5:35 UTC (permalink / raw)
To: netdev; +Cc: Lijun Pan, linuxppc-dev
In-Reply-To: <20200819053512.3619-1-ljp@linux.ibm.com>
At the beginning of the function, from_passive_init is set false by
"adapter->from_passive_init = false;",
hence the if statement will never run.
Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index e366fd42a8c4..280358dce8ba 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -5000,12 +5000,6 @@ static int ibmvnic_reset_init(struct ibmvnic_adapter *adapter)
return adapter->init_done_rc;
}
- if (adapter->from_passive_init) {
- adapter->state = VNIC_OPEN;
- adapter->from_passive_init = false;
- return -1;
- }
-
if (test_bit(0, &adapter->resetting) && !adapter->wait_for_reset &&
adapter->reset_reason != VNIC_RESET_MOBILITY) {
if (adapter->req_rx_queues != old_num_rx_queues ||
@@ -5059,12 +5053,6 @@ static int ibmvnic_init(struct ibmvnic_adapter *adapter)
return adapter->init_done_rc;
}
- if (adapter->from_passive_init) {
- adapter->state = VNIC_OPEN;
- adapter->from_passive_init = false;
- return -1;
- }
-
rc = init_sub_crqs(adapter);
if (rc) {
dev_err(dev, "Initialization of sub crqs failed\n");
--
2.23.0
^ permalink raw reply related
* [PATCH net-next 5/5] ibmvnic: merge ibmvnic_reset_init and ibmvnic_init
From: Lijun Pan @ 2020-08-19 5:35 UTC (permalink / raw)
To: netdev; +Cc: Lijun Pan, linuxppc-dev
In-Reply-To: <20200819053512.3619-1-ljp@linux.ibm.com>
These two functions share the majority of the code, hence merge
them together. In the meanwhile, add a reset pass-in parameter
to differentiate them. Thus, the code is easier to read and to tell
the difference between reset_init and regular init.
Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 65 ++++++------------------------
1 file changed, 13 insertions(+), 52 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 280358dce8ba..c92615b74833 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -104,8 +104,7 @@ static int send_login(struct ibmvnic_adapter *adapter);
static void send_cap_queries(struct ibmvnic_adapter *adapter);
static int init_sub_crqs(struct ibmvnic_adapter *);
static int init_sub_crq_irqs(struct ibmvnic_adapter *adapter);
-static int ibmvnic_init(struct ibmvnic_adapter *);
-static int ibmvnic_reset_init(struct ibmvnic_adapter *);
+static int ibmvnic_reset_init(struct ibmvnic_adapter *, bool reset);
static void release_crq_queue(struct ibmvnic_adapter *);
static int __ibmvnic_set_mac(struct net_device *, u8 *);
static int init_crq_queue(struct ibmvnic_adapter *adapter);
@@ -1868,7 +1867,7 @@ static int do_change_param_reset(struct ibmvnic_adapter *adapter,
return rc;
}
- rc = ibmvnic_reset_init(adapter);
+ rc = ibmvnic_reset_init(adapter, true);
if (rc)
return IBMVNIC_INIT_FAILED;
@@ -1986,7 +1985,7 @@ static int do_reset(struct ibmvnic_adapter *adapter,
goto out;
}
- rc = ibmvnic_reset_init(adapter);
+ rc = ibmvnic_reset_init(adapter, true);
if (rc) {
rc = IBMVNIC_INIT_FAILED;
goto out;
@@ -2093,7 +2092,7 @@ static int do_hard_reset(struct ibmvnic_adapter *adapter,
return rc;
}
- rc = ibmvnic_init(adapter);
+ rc = ibmvnic_reset_init(adapter, false);
if (rc)
return rc;
@@ -4970,7 +4969,7 @@ static int init_crq_queue(struct ibmvnic_adapter *adapter)
return retrc;
}
-static int ibmvnic_reset_init(struct ibmvnic_adapter *adapter)
+static int ibmvnic_reset_init(struct ibmvnic_adapter *adapter, bool reset)
{
struct device *dev = &adapter->vdev->dev;
unsigned long timeout = msecs_to_jiffies(30000);
@@ -4979,10 +4978,12 @@ static int ibmvnic_reset_init(struct ibmvnic_adapter *adapter)
adapter->from_passive_init = false;
- old_num_rx_queues = adapter->req_rx_queues;
- old_num_tx_queues = adapter->req_tx_queues;
+ if (reset) {
+ old_num_rx_queues = adapter->req_rx_queues;
+ old_num_tx_queues = adapter->req_tx_queues;
+ reinit_completion(&adapter->init_done);
+ }
- reinit_completion(&adapter->init_done);
adapter->init_done_rc = 0;
rc = ibmvnic_send_crq_init(adapter);
if (rc) {
@@ -5000,7 +5001,8 @@ static int ibmvnic_reset_init(struct ibmvnic_adapter *adapter)
return adapter->init_done_rc;
}
- if (test_bit(0, &adapter->resetting) && !adapter->wait_for_reset &&
+ if (reset &&
+ test_bit(0, &adapter->resetting) && !adapter->wait_for_reset &&
adapter->reset_reason != VNIC_RESET_MOBILITY) {
if (adapter->req_rx_queues != old_num_rx_queues ||
adapter->req_tx_queues != old_num_tx_queues) {
@@ -5028,47 +5030,6 @@ static int ibmvnic_reset_init(struct ibmvnic_adapter *adapter)
return rc;
}
-static int ibmvnic_init(struct ibmvnic_adapter *adapter)
-{
- struct device *dev = &adapter->vdev->dev;
- unsigned long timeout = msecs_to_jiffies(30000);
- int rc;
-
- adapter->from_passive_init = false;
-
- adapter->init_done_rc = 0;
- rc = ibmvnic_send_crq_init(adapter);
- if (rc) {
- dev_err(dev, "%s: Send crq init failed with error %d\n", __func__, rc);
- return rc;
- }
-
- if (!wait_for_completion_timeout(&adapter->init_done, timeout)) {
- dev_err(dev, "Initialization sequence timed out\n");
- return -1;
- }
-
- if (adapter->init_done_rc) {
- release_crq_queue(adapter);
- return adapter->init_done_rc;
- }
-
- rc = init_sub_crqs(adapter);
- if (rc) {
- dev_err(dev, "Initialization of sub crqs failed\n");
- release_crq_queue(adapter);
- return rc;
- }
-
- rc = init_sub_crq_irqs(adapter);
- if (rc) {
- dev_err(dev, "Failed to initialize sub crq irqs\n");
- release_crq_queue(adapter);
- }
-
- return rc;
-}
-
static struct device_attribute dev_attr_failover;
static int ibmvnic_probe(struct vio_dev *dev, const struct vio_device_id *id)
@@ -5131,7 +5092,7 @@ static int ibmvnic_probe(struct vio_dev *dev, const struct vio_device_id *id)
goto ibmvnic_init_fail;
}
- rc = ibmvnic_init(adapter);
+ rc = ibmvnic_reset_init(adapter, false);
if (rc && rc != EAGAIN)
goto ibmvnic_init_fail;
} while (rc == EAGAIN);
--
2.23.0
^ permalink raw reply related
* Re: fsl_espi errors on v5.7.15
From: Heiner Kallweit @ 2020-08-19 6:15 UTC (permalink / raw)
To: Chris Packham, broonie@kernel.org, mpe@ellerman.id.au,
benh@kernel.crashing.org, paulus@samba.org,
tiago.brusamarello@datacom.ind.br
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org
In-Reply-To: <1bbb3726-b0a4-6eb9-9076-706b06dfb90f@alliedtelesis.co.nz>
On 19.08.2020 00:44, Chris Packham wrote:
> Hi Again,
>
> On 17/08/20 9:09 am, Chris Packham wrote:
>
>>
>> On 14/08/20 6:19 pm, Heiner Kallweit wrote:
>>> On 14.08.2020 04:48, Chris Packham wrote:
>>>> Hi,
>>>>
>>>> I'm seeing a problem with accessing spi-nor after upgrading a T2081
>>>> based system to linux v5.7.15
>>>>
>>>> For this board u-boot and the u-boot environment live on spi-nor.
>>>>
>>>> When I use fw_setenv from userspace I get the following kernel logs
>>>>
>>>> # fw_setenv foo=1
>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>>>> fsl_espi ffe110000.spi: Transfer done but rx/tx fifo's aren't empty!
>>>> fsl_espi ffe110000.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>>>> fsl_espi ffe110000.spi: Transfer done but rx/tx fifo's aren't empty!
>>>> fsl_espi ffe110000.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>>>> fsl_espi ffe110000.spi: Transfer done but rx/tx fifo's aren't empty!
>>>> fsl_espi ffe110000.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
>>>> ...
>>>>
>>> This error reporting doesn't exist yet in 4.4. So you may have an issue
>>> under 4.4 too, it's just not reported.
>>> Did you verify that under 4.4 fw_setenv actually has an effect?
>> Just double checked and yes under 4.4 the setting does get saved.
>>>> If I run fw_printenv (before getting it into a bad state) it is able to
>>>> display the content of the boards u-boot environment.
>>>>
>>> This might indicate an issue with spi being locked. I've seen related
>>> questions, just use the search engine of your choice and check for
>>> fw_setenv and locked.
>> I'm running a version of fw_setenv which includes
>> https://gitlab.denx.de/u-boot/u-boot/-/commit/db820159 so it shouldn't
>> be locking things unnecessarily.
>>>> If been unsuccessful in producing a setup for bisecting the issue. I do
>>>> know the issue doesn't occur on the old 4.4.x based kernel but that's
>>>> probably not much help.
>>>>
>>>> Any pointers on what the issue (and/or solution) might be.
>
> I finally managed to get our board running with a vanilla kernel. With
> corenet64_smp_defconfig I occasionally see
>
> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
>
> other than the message things seem to be working.
>
> With a custom defconfig I see
>
> fsl_espi ffe110000.spi: Transfer done but SPIE_DON isn't set!
> fsl_espi ffe110000.spi: Transfer done but rx/tx fifo's aren't empty!
> fsl_espi ffe110000.spi: SPIE_RXCNT = 1, SPIE_TXCNT = 32
> ...
>
> and access to the spi-nor does not work until the board is reset.
>
> I'll try and pick apart the differences between the two defconfigs.
>
Also relevant may be:
- Which dts are you using?
- What's the spi-nor type, and at which frequency are you operating it?
- Does the issue still happen if you lower the frequency?
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/smp: Move ppc_md.cpu_die() to smp_ops.cpu_offline_self()
From: Christophe Leroy @ 2020-08-19 6:44 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20200819015634.1974478-3-mpe@ellerman.id.au>
Le 19/08/2020 à 03:56, Michael Ellerman a écrit :
> We have smp_ops->cpu_die() and ppc_md.cpu_die(). One of them offlines
> the current CPU and one offlines another CPU, can you guess which is
> which? Also one is in smp_ops and one is in ppc_md?
>
> So rename ppc_md.cpu_die(), to cpu_offline_self(), because that's what
> it does. And move it into smp_ops where it belongs.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> arch/powerpc/include/asm/machdep.h | 1 -
> arch/powerpc/include/asm/smp.h | 3 +++
> arch/powerpc/kernel/smp.c | 4 ++--
> arch/powerpc/kernel/sysfs.c | 4 +++-
> arch/powerpc/platforms/85xx/smp.c | 4 ++--
> arch/powerpc/platforms/powermac/pmac.h | 2 +-
> arch/powerpc/platforms/powermac/sleep.S | 6 +++---
> arch/powerpc/platforms/powermac/smp.c | 8 ++++----
> arch/powerpc/platforms/powernv/smp.c | 4 ++--
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 6 +++---
> 10 files changed, 23 insertions(+), 19 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
> index a90b892f0bfe..cc2ec7101520 100644
> --- a/arch/powerpc/include/asm/machdep.h
> +++ b/arch/powerpc/include/asm/machdep.h
> @@ -65,7 +65,6 @@ struct machdep_calls {
> void __noreturn (*restart)(char *cmd);
> void __noreturn (*halt)(void);
> void (*panic)(char *str);
> - void (*cpu_die)(void);
>
> long (*time_init)(void); /* Optional, may be NULL */
>
> diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
> index a314d2d2d2be..0d00faf8f119 100644
> --- a/arch/powerpc/include/asm/smp.h
> +++ b/arch/powerpc/include/asm/smp.h
> @@ -49,6 +49,9 @@ struct smp_ops_t {
> int (*cpu_disable)(void);
> void (*cpu_die)(unsigned int nr);
> int (*cpu_bootable)(unsigned int nr);
> +#ifdef CONFIG_HOTPLUG_CPU
Is that a performance issue to have that member all the time in smp_ops_t ?
Otherwise we could avoid the #ifdef here and in arch/powerpc/kernel/sysfs.c
Christophe
> + void (*cpu_offline_self)(void);
> +#endif
> };
>
> extern int smp_send_nmi_ipi(int cpu, void (*fn)(struct pt_regs *), u64 delay_us);
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index c616d975bf95..faba0fdee500 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -1439,8 +1439,8 @@ void arch_cpu_idle_dead(void)
> */
> this_cpu_disable_ftrace();
>
> - if (ppc_md.cpu_die)
> - ppc_md.cpu_die();
> + if (smp_ops->cpu_offline_self)
> + smp_ops->cpu_offline_self();
>
> /* If we return, we re-enter start_secondary */
> start_secondary_resume();
> diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
> index 6bebc9a52444..7c4ccc03c2de 100644
> --- a/arch/powerpc/kernel/sysfs.c
> +++ b/arch/powerpc/kernel/sysfs.c
> @@ -1161,6 +1161,7 @@ static int __init topology_init(void)
> for_each_possible_cpu(cpu) {
> struct cpu *c = &per_cpu(cpu_devices, cpu);
>
> +#ifdef CONFIG_HOTPLUG_CPU
> /*
> * For now, we just see if the system supports making
> * the RTAS calls for CPU hotplug. But, there may be a
> @@ -1168,8 +1169,9 @@ static int __init topology_init(void)
> * CPU. For instance, the boot cpu might never be valid
> * for hotplugging.
> */
> - if (ppc_md.cpu_die)
> + if (smp_ops->cpu_offline_self)
> c->hotpluggable = 1;
> +#endif
>
> if (cpu_online(cpu) || c->hotpluggable) {
> register_cpu(c, cpu);
> diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
> index fda108bae95f..c6df294054fe 100644
> --- a/arch/powerpc/platforms/85xx/smp.c
> +++ b/arch/powerpc/platforms/85xx/smp.c
> @@ -112,7 +112,7 @@ static void mpc85xx_take_timebase(void)
> local_irq_restore(flags);
> }
>
> -static void smp_85xx_mach_cpu_die(void)
> +static void smp_85xx_cpu_offline_self(void)
> {
> unsigned int cpu = smp_processor_id();
>
> @@ -506,7 +506,7 @@ void __init mpc85xx_smp_init(void)
> if (qoriq_pm_ops) {
> smp_85xx_ops.give_timebase = mpc85xx_give_timebase;
> smp_85xx_ops.take_timebase = mpc85xx_take_timebase;
> - ppc_md.cpu_die = smp_85xx_mach_cpu_die;
> + smp_85xx_ops.cpu_offline_self = smp_85xx_cpu_offline_self;
> smp_85xx_ops.cpu_die = qoriq_cpu_kill;
> }
> #endif
> diff --git a/arch/powerpc/platforms/powermac/pmac.h b/arch/powerpc/platforms/powermac/pmac.h
> index 16a52afdb76e..0d715db434dc 100644
> --- a/arch/powerpc/platforms/powermac/pmac.h
> +++ b/arch/powerpc/platforms/powermac/pmac.h
> @@ -34,7 +34,7 @@ extern void pmac_check_ht_link(void);
>
> extern void pmac_setup_smp(void);
> extern int psurge_secondary_virq;
> -extern void low_cpu_die(void) __attribute__((noreturn));
> +extern void low_cpu_offline_self(void) __attribute__((noreturn));
>
> extern int pmac_nvram_init(void);
> extern void pmac_pic_init(void);
> diff --git a/arch/powerpc/platforms/powermac/sleep.S b/arch/powerpc/platforms/powermac/sleep.S
> index f9a680fdd9c4..c51bb63c9417 100644
> --- a/arch/powerpc/platforms/powermac/sleep.S
> +++ b/arch/powerpc/platforms/powermac/sleep.S
> @@ -201,8 +201,8 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_USE_HIGH_BATS)
> addi r3,r3,sleep_storage@l
> stw r5,0(r3)
>
> - .globl low_cpu_die
> -low_cpu_die:
> + .globl low_cpu_offline_self
> +low_cpu_offline_self:
> /* Flush & disable all caches */
> bl flush_disable_caches
>
> @@ -244,7 +244,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_SPEC7450)
> mtmsr r2
> isync
> b 1b
> -_ASM_NOKPROBE_SYMBOL(low_cpu_die)
> +_ASM_NOKPROBE_SYMBOL(low_cpu_offline_self)
> /*
> * Here is the resume code.
> */
> diff --git a/arch/powerpc/platforms/powermac/smp.c b/arch/powerpc/platforms/powermac/smp.c
> index eb23264910e1..a6fedcfb714f 100644
> --- a/arch/powerpc/platforms/powermac/smp.c
> +++ b/arch/powerpc/platforms/powermac/smp.c
> @@ -920,7 +920,7 @@ static int smp_core99_cpu_disable(void)
>
> #ifdef CONFIG_PPC32
>
> -static void pmac_cpu_die(void)
> +static void pmac_cpu_offline_self(void)
> {
> int cpu = smp_processor_id();
>
> @@ -930,12 +930,12 @@ static void pmac_cpu_die(void)
> generic_set_cpu_dead(cpu);
> smp_wmb();
> mb();
> - low_cpu_die();
> + low_cpu_offline_self();
> }
>
> #else /* CONFIG_PPC32 */
>
> -static void pmac_cpu_die(void)
> +static void pmac_cpu_offline_self(void)
> {
> int cpu = smp_processor_id();
>
> @@ -1020,7 +1020,7 @@ void __init pmac_setup_smp(void)
> #endif /* CONFIG_PPC_PMAC32_PSURGE */
>
> #ifdef CONFIG_HOTPLUG_CPU
> - ppc_md.cpu_die = pmac_cpu_die;
> + smp_ops->cpu_offline_self = pmac_cpu_offline_self;
> #endif
> }
>
> diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c
> index bbf361f23ae8..54c4ba45c7ce 100644
> --- a/arch/powerpc/platforms/powernv/smp.c
> +++ b/arch/powerpc/platforms/powernv/smp.c
> @@ -158,7 +158,7 @@ static void pnv_flush_interrupts(void)
> }
> }
>
> -static void pnv_smp_cpu_kill_self(void)
> +static void pnv_cpu_offline_self(void)
> {
> unsigned long srr1, unexpected_mask, wmask;
> unsigned int cpu;
> @@ -417,6 +417,7 @@ static struct smp_ops_t pnv_smp_ops = {
> #ifdef CONFIG_HOTPLUG_CPU
> .cpu_disable = pnv_smp_cpu_disable,
> .cpu_die = generic_cpu_die,
> + .cpu_offline_self = pnv_cpu_offline_self,
> #endif /* CONFIG_HOTPLUG_CPU */
> };
>
> @@ -430,7 +431,6 @@ void __init pnv_smp_init(void)
> smp_ops = &pnv_smp_ops;
>
> #ifdef CONFIG_HOTPLUG_CPU
> - ppc_md.cpu_die = pnv_smp_cpu_kill_self;
> #ifdef CONFIG_KEXEC_CORE
> crash_wake_offline = 1;
> #endif
> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> index c6e0d8abf75e..43b020a30072 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> @@ -55,7 +55,7 @@ static void rtas_stop_self(void)
> panic("Alas, I survived.\n");
> }
>
> -static void pseries_mach_cpu_die(void)
> +static void pseries_cpu_offline_self(void)
> {
> unsigned int hwcpu = hard_smp_processor_id();
>
> @@ -102,7 +102,7 @@ static int pseries_cpu_disable(void)
> * to self-destroy so that the cpu-offline thread can send the CPU_DEAD
> * notifications.
> *
> - * OTOH, pseries_mach_cpu_die() is called by the @cpu when it wants to
> + * OTOH, pseries_cpu_offline_self() is called by the @cpu when it wants to
> * self-destruct.
> */
> static void pseries_cpu_die(unsigned int cpu)
> @@ -895,7 +895,7 @@ static int __init pseries_cpu_hotplug_init(void)
> return 0;
> }
>
> - ppc_md.cpu_die = pseries_mach_cpu_die;
> + smp_ops->cpu_offline_self = pseries_cpu_offline_self;
> smp_ops->cpu_disable = pseries_cpu_disable;
> smp_ops->cpu_die = pseries_cpu_die;
>
>
^ permalink raw reply
* Re: [PATCH v3] soc: fsl: enable acpi support
From: Christophe Leroy @ 2020-08-19 6:48 UTC (permalink / raw)
To: Ran Wang, Li Yang; +Cc: linuxppc-dev, Peng Ma, linux-kernel, linux-arm-kernel
In-Reply-To: <20200819040031.40204-1-ran.wang_1@nxp.com>
Le 19/08/2020 à 06:00, Ran Wang a écrit :
> From: Peng Ma <peng.ma@nxp.com>
>
> This patch enables ACPI support in RCPM driver.
Can you change the subject to "soc: fsl: enable acpi support in RCPM
driver" ?
>
> Signed-off-by: Peng Ma <peng.ma@nxp.com>
> Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> ---
> Change in v3:
> - Add #ifdef CONFIG_ACPI for acpi_device_id
> - Rename rcpm_acpi_imx_ids to rcpm_acpi_ids
>
> Change in v2:
> - Update acpi_device_id to fix conflict with other driver
>
> drivers/soc/fsl/rcpm.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
> index a093dbe..55d1d73 100644
> --- a/drivers/soc/fsl/rcpm.c
> +++ b/drivers/soc/fsl/rcpm.c
> @@ -2,7 +2,7 @@
> //
> // rcpm.c - Freescale QorIQ RCPM driver
> //
> -// Copyright 2019 NXP
> +// Copyright 2019-2020 NXP
> //
> // Author: Ran Wang <ran.wang_1@nxp.com>
>
> @@ -13,6 +13,7 @@
> #include <linux/slab.h>
> #include <linux/suspend.h>
> #include <linux/kernel.h>
> +#include <linux/acpi.h>
>
> #define RCPM_WAKEUP_CELL_MAX_SIZE 7
>
> @@ -125,6 +126,7 @@ static int rcpm_probe(struct platform_device *pdev)
>
> ret = device_property_read_u32(&pdev->dev,
> "#fsl,rcpm-wakeup-cells", &rcpm->wakeup_cells);
> +
This blank line addition is unrelated to the patch and shouldn't be there.
Christophe
> if (ret)
> return ret;
>
> @@ -139,10 +141,19 @@ static const struct of_device_id rcpm_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, rcpm_of_match);
>
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id rcpm_acpi_ids[] = {
> + {"NXP0015",},
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, rcpm_acpi_ids);
> +#endif
> +
> static struct platform_driver rcpm_driver = {
> .driver = {
> .name = "rcpm",
> .of_match_table = rcpm_of_match,
> + .acpi_match_table = ACPI_PTR(rcpm_acpi_ids),
> .pm = &rcpm_pm_ops,
> },
> .probe = rcpm_probe,
>
^ permalink raw reply
* RE: [PATCH v3] soc: fsl: enable acpi support
From: Ran Wang @ 2020-08-19 6:52 UTC (permalink / raw)
To: Christophe Leroy, Leo Li
Cc: linuxppc-dev@lists.ozlabs.org, Peng Ma,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <02fa05ad-6d39-e16d-ad02-7472d28b6627@csgroup.eu>
Hi Christophe
On Wednesday, August 19, 2020 2:48 PM, Christophe Leroy wrote:
>
>
>
> Le 19/08/2020 à 06:00, Ran Wang a écrit :
> > From: Peng Ma <peng.ma@nxp.com>
> >
> > This patch enables ACPI support in RCPM driver.
>
> Can you change the subject to "soc: fsl: enable acpi support in RCPM driver" ?
Sure.
> >
> > Signed-off-by: Peng Ma <peng.ma@nxp.com>
> > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > ---
> > Change in v3:
> > - Add #ifdef CONFIG_ACPI for acpi_device_id
> > - Rename rcpm_acpi_imx_ids to rcpm_acpi_ids
> >
> > Change in v2:
> > - Update acpi_device_id to fix conflict with other driver
> >
> > drivers/soc/fsl/rcpm.c | 13 ++++++++++++-
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c index
> > a093dbe..55d1d73 100644
> > --- a/drivers/soc/fsl/rcpm.c
> > +++ b/drivers/soc/fsl/rcpm.c
> > @@ -2,7 +2,7 @@
> > //
> > // rcpm.c - Freescale QorIQ RCPM driver
> > //
> > -// Copyright 2019 NXP
> > +// Copyright 2019-2020 NXP
> > //
> > // Author: Ran Wang <ran.wang_1@nxp.com>
> >
> > @@ -13,6 +13,7 @@
> > #include <linux/slab.h>
> > #include <linux/suspend.h>
> > #include <linux/kernel.h>
> > +#include <linux/acpi.h>
> >
> > #define RCPM_WAKEUP_CELL_MAX_SIZE 7
> >
> > @@ -125,6 +126,7 @@ static int rcpm_probe(struct platform_device
> > *pdev)
> >
> > ret = device_property_read_u32(&pdev->dev,
> > "#fsl,rcpm-wakeup-cells", &rcpm->wakeup_cells);
> > +
>
> This blank line addition is unrelated to the patch and shouldn't be there.
Got it, will remove this in v4, thanks.
Regards,
Ran
> Christophe
>
> > if (ret)
> > return ret;
> >
> > @@ -139,10 +141,19 @@ static const struct of_device_id rcpm_of_match[]
> = {
> > };
> > MODULE_DEVICE_TABLE(of, rcpm_of_match);
> >
> > +#ifdef CONFIG_ACPI
> > +static const struct acpi_device_id rcpm_acpi_ids[] = {
> > + {"NXP0015",},
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(acpi, rcpm_acpi_ids); #endif
> > +
> > static struct platform_driver rcpm_driver = {
> > .driver = {
> > .name = "rcpm",
> > .of_match_table = rcpm_of_match,
> > + .acpi_match_table = ACPI_PTR(rcpm_acpi_ids),
> > .pm = &rcpm_pm_ops,
> > },
> > .probe = rcpm_probe,
> >
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS dc76919c80d7128cd46cfa0f1f356e4c12e50229
From: kernel test robot @ 2020-08-19 6:53 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: dc76919c80d7128cd46cfa0f1f356e4c12e50229 powerpc/pseries/eeh: Fix dumb linebreaks
elapsed time: 1040m
configs tested: 66
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a005-20200818
i386 randconfig-a002-20200818
i386 randconfig-a001-20200818
i386 randconfig-a006-20200818
i386 randconfig-a003-20200818
i386 randconfig-a004-20200818
x86_64 randconfig-a013-20200818
x86_64 randconfig-a016-20200818
x86_64 randconfig-a012-20200818
x86_64 randconfig-a011-20200818
x86_64 randconfig-a014-20200818
x86_64 randconfig-a015-20200818
i386 randconfig-a016-20200818
i386 randconfig-a011-20200818
i386 randconfig-a015-20200818
i386 randconfig-a013-20200818
i386 randconfig-a012-20200818
i386 randconfig-a014-20200818
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS d4ecce4dcc8f8820286cf4e0859850c555e89854
From: kernel test robot @ 2020-08-19 6:53 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: d4ecce4dcc8f8820286cf4e0859850c555e89854 Automatic merge of 'master', 'next' and 'fixes' (2020-08-18 23:23)
elapsed time: 1041m
configs tested: 66
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a005-20200818
i386 randconfig-a002-20200818
i386 randconfig-a001-20200818
i386 randconfig-a006-20200818
i386 randconfig-a003-20200818
i386 randconfig-a004-20200818
x86_64 randconfig-a013-20200818
x86_64 randconfig-a016-20200818
x86_64 randconfig-a012-20200818
x86_64 randconfig-a011-20200818
x86_64 randconfig-a014-20200818
x86_64 randconfig-a015-20200818
i386 randconfig-a016-20200818
i386 randconfig-a011-20200818
i386 randconfig-a015-20200818
i386 randconfig-a013-20200818
i386 randconfig-a012-20200818
i386 randconfig-a014-20200818
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS 801980f6497946048709b9b09771a1729551d705
From: kernel test robot @ 2020-08-19 6:52 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 801980f6497946048709b9b09771a1729551d705 powerpc/pseries/hotplug-cpu: wait indefinitely for vCPU death
elapsed time: 1042m
configs tested: 72
configs skipped: 68
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a005-20200818
i386 randconfig-a002-20200818
i386 randconfig-a001-20200818
i386 randconfig-a006-20200818
i386 randconfig-a003-20200818
i386 randconfig-a004-20200818
x86_64 randconfig-a013-20200818
x86_64 randconfig-a016-20200818
x86_64 randconfig-a012-20200818
x86_64 randconfig-a011-20200818
x86_64 randconfig-a014-20200818
x86_64 randconfig-a015-20200818
i386 randconfig-a016-20200818
i386 randconfig-a011-20200818
i386 randconfig-a015-20200818
i386 randconfig-a013-20200818
i386 randconfig-a012-20200818
i386 randconfig-a014-20200818
x86_64 randconfig-a006-20200819
x86_64 randconfig-a001-20200819
x86_64 randconfig-a003-20200819
x86_64 randconfig-a005-20200819
x86_64 randconfig-a004-20200819
x86_64 randconfig-a002-20200819
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH 14/16] debug_vm_pgtable/hugetlb: Disable hugetlb test on ppc64
From: Aneesh Kumar K.V @ 2020-08-19 6:54 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm, akpm; +Cc: linuxppc-dev
In-Reply-To: <08c63a65-cd3f-73f3-1698-5e60f398fbad@arm.com>
Anshuman Khandual <anshuman.khandual@arm.com> writes:
> On 08/12/2020 07:22 PM, Aneesh Kumar K.V wrote:
>> On 8/12/20 7:04 PM, Anshuman Khandual wrote:
>>>
>>>
>>> On 08/12/2020 06:46 PM, Aneesh Kumar K.V wrote:
>>>> On 8/12/20 6:33 PM, Anshuman Khandual wrote:
>>>>>
>>>>>
>>>>> On 08/12/2020 12:03 PM, Aneesh Kumar K.V wrote:
>>>>>> The seems to be missing quite a lot of details w.r.t allocating
>>>>>> the correct pgtable_t page (huge_pte_alloc()), holding the right
>>>>>> lock (huge_pte_lock()) etc. The vma used is also not a hugetlb VMA.
>>>>>>
>>>>>> ppc64 do have runtime checks within CONFIG_DEBUG_VM for most of these.
>>>>>> Hence disable the test on ppc64.
>>>>>
>>>>> This test is free from any platform specific #ifdefs which should
>>>>> never be broken. If hugetlb_advanced_tests() does not work or is
>>>>> not detailed enough for ppc64, then it would be great if you could
>>>>> suggest some improvements so that it works for all enabled platforms.
>>>>>
>>>>>
>>>>
>>>> As mentioned the test is broken. For hugetlb, the pgtable_t pages should be allocated by huge_pte_alloc(). We need to hold huget_pte_lock() before updating huge tlb pte. That takes hugepage size, which is mostly derived out of vma. Hence vma need to be a hugetlb vma. Some of the functions also depend on hstate. Also we should use set_huge_pte_at() when setting up hugetlb pte entries. I was tempted to remove that test completely marking it broken. But avoided that by marking it broken on only PPC64.
>>>
>>> The test is not broken, hugetlb helpers on multiple platforms dont complain about
>>> this at all. The tests here emulate 'enough' MM objects required for the helpers
>>> on enabled platforms, to perform the primary task i.e page table transformation it
>>> is expected to do. The test does not claim to emulate a perfect MM environment for
>>> a given subsystem's (like HugeTLB) arch helpers. Now in this case, the MM objects
>>> being emulated for the HugeTLB advanced tests does not seem to be sufficient for
>>> ppc64 but it can be improved. But that does not mean it is broken in it's current
>>> form for other platforms.
>>>
>>
>> There is nothing ppc64 specific here. It is just that we have CONFIG_DEBUG_VM based checks for different possibly wrong usages of these functions. This was done because we have different page sizes, two different translations to support and we want to avoid any wrong usage. IMHO expecting hugetlb page table helpers to work with a non hugetlb VMA and without holding hugeTLB pte lock is a clear violation of hugetlb interface.
>
> Do you have a modified version of the test with HugeTLB marked VMA and with pte lock
> held, which works on ppc664 ?
Nope. That is one of the reason I commented that out. We can sort that
out slowly.
-aneesh
^ permalink raw reply
* [PATCH v4] soc: fsl: enable acpi support in RCPM driver
From: Ran Wang @ 2020-08-19 6:52 UTC (permalink / raw)
To: Li Yang, Christophe Leroy
Cc: Peng Ma, Ran Wang, linuxppc-dev, linux-kernel, linux-arm-kernel
From: Peng Ma <peng.ma@nxp.com>
This patch enables ACPI support in RCPM driver.
Signed-off-by: Peng Ma <peng.ma@nxp.com>
Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
---
Change in v4:
- Make commit subject more accurate
- Remove unrelated new blank line
Change in v3:
- Add #ifdef CONFIG_ACPI for acpi_device_id
- Rename rcpm_acpi_imx_ids to rcpm_acpi_ids
Change in v2:
- Update acpi_device_id to fix conflict with other driver
drivers/soc/fsl/rcpm.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
index a093dbe..b5aa6db 100644
--- a/drivers/soc/fsl/rcpm.c
+++ b/drivers/soc/fsl/rcpm.c
@@ -2,7 +2,7 @@
//
// rcpm.c - Freescale QorIQ RCPM driver
//
-// Copyright 2019 NXP
+// Copyright 2019-2020 NXP
//
// Author: Ran Wang <ran.wang_1@nxp.com>
@@ -13,6 +13,7 @@
#include <linux/slab.h>
#include <linux/suspend.h>
#include <linux/kernel.h>
+#include <linux/acpi.h>
#define RCPM_WAKEUP_CELL_MAX_SIZE 7
@@ -139,10 +140,19 @@ static const struct of_device_id rcpm_of_match[] = {
};
MODULE_DEVICE_TABLE(of, rcpm_of_match);
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id rcpm_acpi_ids[] = {
+ {"NXP0015",},
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, rcpm_acpi_ids);
+#endif
+
static struct platform_driver rcpm_driver = {
.driver = {
.name = "rcpm",
.of_match_table = rcpm_of_match,
+ .acpi_match_table = ACPI_PTR(rcpm_acpi_ids),
.pm = &rcpm_pm_ops,
},
.probe = rcpm_probe,
--
2.7.4
^ permalink raw reply related
* Re: remove the last set_fs() in common code, and remove it for x86 and powerpc
From: Christophe Leroy @ 2020-08-19 7:16 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, Kees Cook, x86, linux-kernel, Al Viro, linux-fsdevel,
linuxppc-dev
In-Reply-To: <e3781661-2e13-4f46-d892-181907a2e768@csgroup.eu>
Le 18/08/2020 à 20:23, Christophe Leroy a écrit :
>
>
> Le 18/08/2020 à 20:05, Christoph Hellwig a écrit :
>> On Tue, Aug 18, 2020 at 07:46:22PM +0200, Christophe Leroy wrote:
>>> I gave it a go on my powerpc mpc832x. I tested it on top of my newest
>>> series that reworks the 32 bits signal handlers (see
>>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=196278) with
>>>
>>> the microbenchmark test used is that series.
>>>
>>> With KUAP activated, on top of signal32 rework, performance is
>>> boosted as
>>> system time for the microbenchmark goes from 1.73s down to 1.56s,
>>> that is
>>> 10% quicker
>>>
>>> Surprisingly, with the kernel as is today without my signal's series,
>>> your
>>> series degrades performance slightly (from 2.55s to 2.64s ie 3.5%
>>> slower).
>>>
>>>
>>> I also observe, in both cases, a degradation on
>>>
>>> dd if=/dev/zero of=/dev/null count=1M
>>>
>>> Without your series, it runs in 5.29 seconds.
>>> With your series, it runs in 5.82 seconds, that is 10% more time.
>>
>> That's pretty strage, I wonder if some kernel text cache line
>> effects come into play here?
>>
>> The kernel access side is only used in slow path code, so it should
>> not make a difference, and the uaccess code is simplified and should be
>> (marginally) faster.
>>
>> Btw, was this with the __{get,put}_user_allowed cockup that you noticed
>> fixed?
>>
>
> Yes it is with the __get_user_size() replaced by __get_user_size_allowed().
I made a test with only the first patch of your series: That's
definitely the culprit. With only that patch applies, the duration is
6.64 seconds, that's a 25% degradation.
A perf record provides the following without the patch:
41.91% dd [kernel.kallsyms] [k] __arch_clear_user
7.02% dd [kernel.kallsyms] [k] vfs_read
6.86% dd [kernel.kallsyms] [k] new_sync_read
6.68% dd [kernel.kallsyms] [k] iov_iter_zero
6.03% dd [kernel.kallsyms] [k] transfer_to_syscall
3.39% dd [kernel.kallsyms] [k] memset
3.07% dd [kernel.kallsyms] [k] __fsnotify_parent
2.68% dd [kernel.kallsyms] [k] ksys_read
2.09% dd [kernel.kallsyms] [k] read_iter_zero
2.01% dd [kernel.kallsyms] [k] __fget_light
1.84% dd [kernel.kallsyms] [k] __fdget_pos
1.35% dd [kernel.kallsyms] [k] rw_verify_area
1.32% dd libc-2.23.so [.] __GI___libc_write
1.21% dd [kernel.kallsyms] [k] vfs_write
...
0.03% dd [kernel.kallsyms] [k] write_null
And the following with the patch:
15.54% dd [kernel.kallsyms] [k] __arch_clear_user
9.17% dd [kernel.kallsyms] [k] vfs_read
6.54% dd [kernel.kallsyms] [k] new_sync_write
6.31% dd [kernel.kallsyms] [k] transfer_to_syscall
6.29% dd [kernel.kallsyms] [k] __fsnotify_parent
6.20% dd [kernel.kallsyms] [k] new_sync_read
5.47% dd [kernel.kallsyms] [k] memset
5.13% dd [kernel.kallsyms] [k] vfs_write
4.44% dd [kernel.kallsyms] [k] iov_iter_zero
2.95% dd [kernel.kallsyms] [k] write_iter_null
2.82% dd [kernel.kallsyms] [k] ksys_read
2.46% dd [kernel.kallsyms] [k] __fget_light
2.34% dd libc-2.23.so [.] __GI___libc_read
1.89% dd [kernel.kallsyms] [k] iov_iter_advance
1.76% dd [kernel.kallsyms] [k] __fdget_pos
1.65% dd [kernel.kallsyms] [k] rw_verify_area
1.63% dd [kernel.kallsyms] [k] read_iter_zero
1.60% dd [kernel.kallsyms] [k] iov_iter_init
1.22% dd [kernel.kallsyms] [k] ksys_write
1.14% dd libc-2.23.so [.] __GI___libc_write
Christophe
>
> Christophe
^ permalink raw reply
* iter and normal ops on /dev/zero & co, was Re: remove the last set_fs() in common code, and remove it for x86 and powerpc
From: Christoph Hellwig @ 2020-08-19 7:22 UTC (permalink / raw)
To: Christophe Leroy, Al Viro
Cc: linux-arch, Kees Cook, x86, linux-kernel, linux-fsdevel,
linuxppc-dev, Christoph Hellwig
In-Reply-To: <f2e31c89-dd9e-f0f8-ef5c-e930d01a3b65@csgroup.eu>
On Wed, Aug 19, 2020 at 09:16:59AM +0200, Christophe Leroy wrote:
> I made a test with only the first patch of your series: That's definitely
> the culprit. With only that patch applies, the duration is 6.64 seconds,
> that's a 25% degradation.
For the record: the first patch is:
mem: remove duplicate ops for /dev/zero and /dev/null
So these micro-optimizations matter at least for some popular
benchmarks. It would be easy to drop, but that means we either:
- can't support kernel_read/write on these files, which should not
matter
or
- have to drop the check for both ops being present
Al, what do you think?
^ 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