* [PATCH v1 5/7] KVM: PPC: Book3S 64: Move interrupt early register setup to KVM
From: Nicholas Piggin @ 2021-04-12 7:51 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <20210412075103.1533302-1-npiggin@gmail.com>
Like the earlier patch for hcalls, KVM interrupt entry requires a
different calling convention than the Linux interrupt handlers
set up. Move the code that converts from one to the other into KVM.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/exceptions-64s.S | 131 +++++----------------------
arch/powerpc/kvm/book3s_64_entry.S | 50 +++++++++-
2 files changed, 71 insertions(+), 110 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 1bfd0d7af09e..cd1731642b12 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -187,7 +187,6 @@ do_define_int n
.endif
.endm
-#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
/*
* All interrupts which set HSRR registers, as well as SRESET and MCE and
* syscall when invoked with "sc 1" switch to MSR[HV]=1 (HVMODE) to be taken,
@@ -220,54 +219,25 @@ do_define_int n
* to KVM to handle.
*/
-.macro KVMTEST name
+.macro KVMTEST name handler
+#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
lbz r10,HSTATE_IN_GUEST(r13)
cmpwi r10,0
- bne \name\()_kvm
-.endm
-
-.macro GEN_KVM name
- .balign IFETCH_ALIGN_BYTES
-\name\()_kvm:
-
-BEGIN_FTR_SECTION
- ld r10,IAREA+EX_CFAR(r13)
- std r10,HSTATE_CFAR(r13)
-END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
-
- ld r10,IAREA+EX_CTR(r13)
- mtctr r10
-BEGIN_FTR_SECTION
- ld r10,IAREA+EX_PPR(r13)
- std r10,HSTATE_PPR(r13)
-END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
- ld r11,IAREA+EX_R11(r13)
- ld r12,IAREA+EX_R12(r13)
- std r12,HSTATE_SCRATCH0(r13)
- sldi r12,r9,32
- ld r9,IAREA+EX_R9(r13)
- ld r10,IAREA+EX_R10(r13)
/* HSRR variants have the 0x2 bit added to their trap number */
.if IHSRR_IF_HVMODE
BEGIN_FTR_SECTION
- ori r12,r12,(IVEC + 0x2)
+ li r10,(IVEC + 0x2)
FTR_SECTION_ELSE
- ori r12,r12,(IVEC)
+ li r10,(IVEC)
ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE | CPU_FTR_ARCH_206)
.elseif IHSRR
- ori r12,r12,(IVEC+ 0x2)
+ li r10,(IVEC + 0x2)
.else
- ori r12,r12,(IVEC)
+ li r10,(IVEC)
.endif
- b kvmppc_interrupt
-.endm
-
-#else
-.macro KVMTEST name
-.endm
-.macro GEN_KVM name
-.endm
+ bne \handler
#endif
+.endm
/*
* This is the BOOK3S interrupt entry code macro.
@@ -409,7 +379,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
DEFINE_FIXED_SYMBOL(\name\()_common_real)
\name\()_common_real:
.if IKVM_REAL
- KVMTEST \name
+ KVMTEST \name kvm_interrupt
.endif
ld r10,PACAKMSR(r13) /* get MSR value for kernel */
@@ -432,7 +402,7 @@ DEFINE_FIXED_SYMBOL(\name\()_common_real)
DEFINE_FIXED_SYMBOL(\name\()_common_virt)
\name\()_common_virt:
.if IKVM_VIRT
- KVMTEST \name
+ KVMTEST \name kvm_interrupt
1:
.endif
.endif /* IVIRT */
@@ -446,7 +416,7 @@ DEFINE_FIXED_SYMBOL(\name\()_common_virt)
DEFINE_FIXED_SYMBOL(\name\()_common_real)
\name\()_common_real:
.if IKVM_REAL
- KVMTEST \name
+ KVMTEST \name kvm_interrupt
.endif
.endm
@@ -967,8 +937,6 @@ EXC_COMMON_BEGIN(system_reset_common)
EXCEPTION_RESTORE_REGS
RFI_TO_USER_OR_KERNEL
- GEN_KVM system_reset
-
/**
* Interrupt 0x200 - Machine Check Interrupt (MCE).
@@ -1132,7 +1100,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE | CPU_FTR_ARCH_206)
/*
* Check if we are coming from guest. If yes, then run the normal
* exception handler which will take the
- * machine_check_kvm->kvmppc_interrupt branch to deliver the MC event
+ * machine_check_kvm->kvm_interrupt branch to deliver the MC event
* to guest.
*/
lbz r11,HSTATE_IN_GUEST(r13)
@@ -1203,8 +1171,6 @@ EXC_COMMON_BEGIN(machine_check_common)
bl machine_check_exception
b interrupt_return
- GEN_KVM machine_check
-
#ifdef CONFIG_PPC_P7_NAP
/*
@@ -1339,8 +1305,6 @@ ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_TYPE_RADIX)
REST_NVGPRS(r1)
b interrupt_return
- GEN_KVM data_access
-
/**
* Interrupt 0x380 - Data Segment Interrupt (DSLB).
@@ -1390,8 +1354,6 @@ ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_TYPE_RADIX)
bl do_bad_slb_fault
b interrupt_return
- GEN_KVM data_access_slb
-
/**
* Interrupt 0x400 - Instruction Storage Interrupt (ISI).
@@ -1428,8 +1390,6 @@ MMU_FTR_SECTION_ELSE
ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_TYPE_RADIX)
b interrupt_return
- GEN_KVM instruction_access
-
/**
* Interrupt 0x480 - Instruction Segment Interrupt (ISLB).
@@ -1474,8 +1434,6 @@ ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_TYPE_RADIX)
bl do_bad_slb_fault
b interrupt_return
- GEN_KVM instruction_access_slb
-
/**
* Interrupt 0x500 - External Interrupt.
@@ -1521,8 +1479,6 @@ EXC_COMMON_BEGIN(hardware_interrupt_common)
bl do_IRQ
b interrupt_return
- GEN_KVM hardware_interrupt
-
/**
* Interrupt 0x600 - Alignment Interrupt
@@ -1550,8 +1506,6 @@ EXC_COMMON_BEGIN(alignment_common)
REST_NVGPRS(r1) /* instruction emulation may change GPRs */
b interrupt_return
- GEN_KVM alignment
-
/**
* Interrupt 0x700 - Program Interrupt (program check).
@@ -1659,8 +1613,6 @@ EXC_COMMON_BEGIN(program_check_common)
REST_NVGPRS(r1) /* instruction emulation may change GPRs */
b interrupt_return
- GEN_KVM program_check
-
/*
* Interrupt 0x800 - Floating-Point Unavailable Interrupt.
@@ -1710,8 +1662,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_TM)
b interrupt_return
#endif
- GEN_KVM fp_unavailable
-
/**
* Interrupt 0x900 - Decrementer Interrupt.
@@ -1751,8 +1701,6 @@ EXC_COMMON_BEGIN(decrementer_common)
bl timer_interrupt
b interrupt_return
- GEN_KVM decrementer
-
/**
* Interrupt 0x980 - Hypervisor Decrementer Interrupt.
@@ -1798,8 +1746,6 @@ EXC_COMMON_BEGIN(hdecrementer_common)
ld r13,PACA_EXGEN+EX_R13(r13)
HRFI_TO_KERNEL
- GEN_KVM hdecrementer
-
/**
* Interrupt 0xa00 - Directed Privileged Doorbell Interrupt.
@@ -1840,8 +1786,6 @@ EXC_COMMON_BEGIN(doorbell_super_common)
#endif
b interrupt_return
- GEN_KVM doorbell_super
-
EXC_REAL_NONE(0xb00, 0x100)
EXC_VIRT_NONE(0x4b00, 0x100)
@@ -1891,7 +1835,7 @@ INT_DEFINE_END(system_call)
GET_PACA(r13)
std r10,PACA_EXGEN+EX_R10(r13)
INTERRUPT_TO_KERNEL
- KVMTEST system_call /* uses r10, branch to system_call_kvm */
+ KVMTEST system_call kvm_hcall /* uses r10, branch to kvm_hcall */
mfctr r9
#else
mr r9,r13
@@ -1947,7 +1891,7 @@ EXC_VIRT_BEGIN(system_call, 0x4c00, 0x100)
EXC_VIRT_END(system_call, 0x4c00, 0x100)
#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
-TRAMP_REAL_BEGIN(system_call_kvm)
+TRAMP_REAL_BEGIN(kvm_hcall)
mfctr r10
SET_SCRATCH0(r10) /* Save r13 in SCRATCH0 */
#ifdef CONFIG_RELOCATABLE
@@ -1987,8 +1931,6 @@ EXC_COMMON_BEGIN(single_step_common)
bl single_step_exception
b interrupt_return
- GEN_KVM single_step
-
/**
* Interrupt 0xe00 - Hypervisor Data Storage Interrupt (HDSI).
@@ -2027,8 +1969,6 @@ MMU_FTR_SECTION_ELSE
ALT_MMU_FTR_SECTION_END_IFSET(MMU_FTR_TYPE_RADIX)
b interrupt_return
- GEN_KVM h_data_storage
-
/**
* Interrupt 0xe20 - Hypervisor Instruction Storage Interrupt (HISI).
@@ -2054,8 +1994,6 @@ EXC_COMMON_BEGIN(h_instr_storage_common)
bl unknown_exception
b interrupt_return
- GEN_KVM h_instr_storage
-
/**
* Interrupt 0xe40 - Hypervisor Emulation Assistance Interrupt.
@@ -2080,8 +2018,6 @@ EXC_COMMON_BEGIN(emulation_assist_common)
REST_NVGPRS(r1) /* instruction emulation may change GPRs */
b interrupt_return
- GEN_KVM emulation_assist
-
/**
* Interrupt 0xe60 - Hypervisor Maintenance Interrupt (HMI).
@@ -2153,8 +2089,6 @@ EXC_COMMON_BEGIN(hmi_exception_early_common)
EXCEPTION_RESTORE_REGS hsrr=1
GEN_INT_ENTRY hmi_exception, virt=0
- GEN_KVM hmi_exception_early
-
EXC_COMMON_BEGIN(hmi_exception_common)
GEN_COMMON hmi_exception
FINISH_NAP
@@ -2162,8 +2096,6 @@ EXC_COMMON_BEGIN(hmi_exception_common)
bl handle_hmi_exception
b interrupt_return
- GEN_KVM hmi_exception
-
/**
* Interrupt 0xe80 - Directed Hypervisor Doorbell Interrupt.
@@ -2195,8 +2127,6 @@ EXC_COMMON_BEGIN(h_doorbell_common)
#endif
b interrupt_return
- GEN_KVM h_doorbell
-
/**
* Interrupt 0xea0 - Hypervisor Virtualization Interrupt.
@@ -2224,8 +2154,6 @@ EXC_COMMON_BEGIN(h_virt_irq_common)
bl do_IRQ
b interrupt_return
- GEN_KVM h_virt_irq
-
EXC_REAL_NONE(0xec0, 0x20)
EXC_VIRT_NONE(0x4ec0, 0x20)
@@ -2270,8 +2198,6 @@ EXC_COMMON_BEGIN(performance_monitor_common)
bl performance_monitor_exception
b interrupt_return
- GEN_KVM performance_monitor
-
/**
* Interrupt 0xf20 - Vector Unavailable Interrupt.
@@ -2321,8 +2247,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
bl altivec_unavailable_exception
b interrupt_return
- GEN_KVM altivec_unavailable
-
/**
* Interrupt 0xf40 - VSX Unavailable Interrupt.
@@ -2371,8 +2295,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
bl vsx_unavailable_exception
b interrupt_return
- GEN_KVM vsx_unavailable
-
/**
* Interrupt 0xf60 - Facility Unavailable Interrupt.
@@ -2401,8 +2323,6 @@ EXC_COMMON_BEGIN(facility_unavailable_common)
REST_NVGPRS(r1) /* instruction emulation may change GPRs */
b interrupt_return
- GEN_KVM facility_unavailable
-
/**
* Interrupt 0xf60 - Hypervisor Facility Unavailable Interrupt.
@@ -2431,8 +2351,6 @@ EXC_COMMON_BEGIN(h_facility_unavailable_common)
REST_NVGPRS(r1) /* XXX Shouldn't be necessary in practice */
b interrupt_return
- GEN_KVM h_facility_unavailable
-
EXC_REAL_NONE(0xfa0, 0x20)
EXC_VIRT_NONE(0x4fa0, 0x20)
@@ -2462,8 +2380,6 @@ EXC_COMMON_BEGIN(cbe_system_error_common)
bl cbe_system_error_exception
b interrupt_return
- GEN_KVM cbe_system_error
-
#else /* CONFIG_CBE_RAS */
EXC_REAL_NONE(0x1200, 0x100)
EXC_VIRT_NONE(0x5200, 0x100)
@@ -2495,8 +2411,6 @@ EXC_COMMON_BEGIN(instruction_breakpoint_common)
bl instruction_breakpoint_exception
b interrupt_return
- GEN_KVM instruction_breakpoint
-
EXC_REAL_NONE(0x1400, 0x100)
EXC_VIRT_NONE(0x5400, 0x100)
@@ -2617,8 +2531,6 @@ EXC_COMMON_BEGIN(denorm_exception_common)
bl unknown_exception
b interrupt_return
- GEN_KVM denorm_exception
-
#ifdef CONFIG_CBE_RAS
INT_DEFINE_BEGIN(cbe_maintenance)
@@ -2636,8 +2548,6 @@ EXC_COMMON_BEGIN(cbe_maintenance_common)
bl cbe_maintenance_exception
b interrupt_return
- GEN_KVM cbe_maintenance
-
#else /* CONFIG_CBE_RAS */
EXC_REAL_NONE(0x1600, 0x100)
EXC_VIRT_NONE(0x5600, 0x100)
@@ -2668,8 +2578,6 @@ EXC_COMMON_BEGIN(altivec_assist_common)
#endif
b interrupt_return
- GEN_KVM altivec_assist
-
#ifdef CONFIG_CBE_RAS
INT_DEFINE_BEGIN(cbe_thermal)
@@ -2687,8 +2595,6 @@ EXC_COMMON_BEGIN(cbe_thermal_common)
bl cbe_thermal_exception
b interrupt_return
- GEN_KVM cbe_thermal
-
#else /* CONFIG_CBE_RAS */
EXC_REAL_NONE(0x1800, 0x100)
EXC_VIRT_NONE(0x5800, 0x100)
@@ -2941,6 +2847,15 @@ TRAMP_REAL_BEGIN(rfscv_flush_fallback)
USE_TEXT_SECTION()
+#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
+kvm_interrupt:
+ /*
+ * The conditional branch in KVMTEST can't reach all the way,
+ * make a stub.
+ */
+ b kvmppc_interrupt
+#endif
+
_GLOBAL(do_uaccess_flush)
UACCESS_FLUSH_FIXUP_SECTION
nop
diff --git a/arch/powerpc/kvm/book3s_64_entry.S b/arch/powerpc/kvm/book3s_64_entry.S
index f527e16707db..2c9d106145e8 100644
--- a/arch/powerpc/kvm/book3s_64_entry.S
+++ b/arch/powerpc/kvm/book3s_64_entry.S
@@ -44,15 +44,61 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
sldi r12,r10,32
ori r12,r12,0xc00
ld r10,PACA_EXGEN+EX_R10(r13)
+ b do_kvm_interrupt
+/*
+ * KVM interrupt entry occurs after GEN_INT_ENTRY runs, and follows that
+ * call convention:
+ *
+ * guest R9-R13, CTR, CFAR, PPR saved in PACA EX_xxx save area
+ * guest (H)DAR, (H)DSISR are also in the save area for relevant interrupts
+ * guest R13 also saved in SCRATCH0
+ * R13 = PACA
+ * R11 = (H)SRR0
+ * R12 = (H)SRR1
+ * R9 = guest CR
+ * PPR is set to medium
+ *
+ * With the addition for KVM:
+ * R10 = trap vector
+ */
.global kvmppc_interrupt
.balign IFETCH_ALIGN_BYTES
kvmppc_interrupt:
+ li r11,PACA_EXGEN
+ cmpdi r10,0x200
+ bgt+ 1f
+ li r11,PACA_EXMC
+ beq 1f
+ li r11,PACA_EXNMI
+1: add r11,r11,r13
+
+BEGIN_FTR_SECTION
+ ld r12,EX_CFAR(r11)
+ std r12,HSTATE_CFAR(r13)
+END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
+ ld r12,EX_CTR(r11)
+ mtctr r12
+BEGIN_FTR_SECTION
+ ld r12,EX_PPR(r11)
+ std r12,HSTATE_PPR(r13)
+END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
+ ld r12,EX_R12(r11)
+ std r12,HSTATE_SCRATCH0(r13)
+ sldi r12,r9,32
+ or r12,r12,r10
+ ld r9,EX_R9(r11)
+ ld r10,EX_R10(r11)
+ ld r11,EX_R11(r11)
+
+do_kvm_interrupt:
/*
- * Register contents:
+ * Hcalls and other interrupts come here after normalising register
+ * contents and save locations:
+ *
* R12 = (guest CR << 32) | interrupt vector
* R13 = PACA
- * guest R12 saved in shadow VCPU SCRATCH0
+ * guest R12 saved in shadow HSTATE_SCRATCH0
* guest R13 saved in SPRN_SCRATCH0
*/
std r9,HSTATE_SCRATCH2(r13)
--
2.23.0
^ permalink raw reply related
* [PATCH v1 6/7] KVM: PPC: Book3S 64: move bad_host_intr check to HV handler
From: Nicholas Piggin @ 2021-04-12 7:51 UTC (permalink / raw)
To: kvm-ppc; +Cc: Alexey Kardashevskiy, linuxppc-dev, Nicholas Piggin
In-Reply-To: <20210412075103.1533302-1-npiggin@gmail.com>
The bad_host_intr check will never be true with PR KVM, move
it to HV code.
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kvm/book3s_64_entry.S | 4 ----
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 4 +++-
arch/powerpc/kvm/book3s_segment.S | 3 +++
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_entry.S b/arch/powerpc/kvm/book3s_64_entry.S
index 2c9d106145e8..66170ea85bc2 100644
--- a/arch/powerpc/kvm/book3s_64_entry.S
+++ b/arch/powerpc/kvm/book3s_64_entry.S
@@ -107,16 +107,12 @@ do_kvm_interrupt:
beq- .Lmaybe_skip
.Lno_skip:
#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
- cmpwi r9,KVM_GUEST_MODE_HOST_HV
- beq kvmppc_bad_host_intr
#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
cmpwi r9,KVM_GUEST_MODE_GUEST
- ld r9,HSTATE_SCRATCH2(r13)
beq kvmppc_interrupt_pr
#endif
b kvmppc_interrupt_hv
#else
- ld r9,HSTATE_SCRATCH2(r13)
b kvmppc_interrupt_pr
#endif
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index f976efb7e4a9..75405ef53238 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -1265,6 +1265,7 @@ hdec_soon:
kvmppc_interrupt_hv:
/*
* Register contents:
+ * R9 = HSTATE_IN_GUEST
* R12 = (guest CR << 32) | interrupt vector
* R13 = PACA
* guest R12 saved in shadow VCPU SCRATCH0
@@ -1272,6 +1273,8 @@ kvmppc_interrupt_hv:
* guest R9 saved in HSTATE_SCRATCH2
*/
/* We're now back in the host but in guest MMU context */
+ cmpwi r9,KVM_GUEST_MODE_HOST_HV
+ beq kvmppc_bad_host_intr
li r9, KVM_GUEST_MODE_HOST_HV
stb r9, HSTATE_IN_GUEST(r13)
@@ -3272,7 +3275,6 @@ END_FTR_SECTION_IFCLR(CPU_FTR_P9_TM_HV_ASSIST)
* cfar is saved in HSTATE_CFAR(r13)
* ppr is saved in HSTATE_PPR(r13)
*/
-.global kvmppc_bad_host_intr
kvmppc_bad_host_intr:
/*
* Switch to the emergency stack, but start half-way down in
diff --git a/arch/powerpc/kvm/book3s_segment.S b/arch/powerpc/kvm/book3s_segment.S
index 1f492aa4c8d6..202046a83fc1 100644
--- a/arch/powerpc/kvm/book3s_segment.S
+++ b/arch/powerpc/kvm/book3s_segment.S
@@ -164,12 +164,15 @@ kvmppc_interrupt_pr:
/* 64-bit entry. Register usage at this point:
*
* SPRG_SCRATCH0 = guest R13
+ * R9 = HSTATE_IN_GUEST
* R12 = (guest CR << 32) | exit handler id
* R13 = PACA
* HSTATE.SCRATCH0 = guest R12
+ * HSTATE.SCRATCH2 = guest R9
*/
#ifdef CONFIG_PPC64
/* Match 32-bit entry */
+ ld r9,HSTATE_SCRATCH2(r13)
rotldi r12, r12, 32 /* Flip R12 halves for stw */
stw r12, HSTATE_SCRATCH1(r13) /* CR is now in the low half */
srdi r12, r12, 32 /* shift trap into low half */
--
2.23.0
^ permalink raw reply related
* [PATCH v1 7/7] KVM: PPC: Book3S 64: Minimise hcall handler calling convention differences
From: Nicholas Piggin @ 2021-04-12 7:51 UTC (permalink / raw)
To: kvm-ppc; +Cc: Alexey Kardashevskiy, linuxppc-dev, Nicholas Piggin
In-Reply-To: <20210412075103.1533302-1-npiggin@gmail.com>
This sets up the same calling convention from interrupt entry to
KVM interrupt handler for system calls as exists for other interrupt
types.
This is a better API, it uses a save area rather than SPR, and it has
more registers free to use. Using a single common API helps maintain
it, and it becomes easier to use in C in a later patch.
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/exceptions-64s.S | 21 +++++++++-
arch/powerpc/kvm/book3s_64_entry.S | 61 ++++++++++++----------------
2 files changed, 45 insertions(+), 37 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index cd1731642b12..24c54b6fb3d7 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1892,8 +1892,27 @@ EXC_VIRT_END(system_call, 0x4c00, 0x100)
#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
TRAMP_REAL_BEGIN(kvm_hcall)
+ std r9,PACA_EXGEN+EX_R9(r13)
+ std r11,PACA_EXGEN+EX_R11(r13)
+ std r12,PACA_EXGEN+EX_R12(r13)
+ mfcr r9
mfctr r10
- SET_SCRATCH0(r10) /* Save r13 in SCRATCH0 */
+ std r10,PACA_EXGEN+EX_R13(r13)
+ li r10,0
+ std r10,PACA_EXGEN+EX_CFAR(r13)
+ std r10,PACA_EXGEN+EX_CTR(r13)
+ /*
+ * Save the PPR (on systems that support it) before changing to
+ * HMT_MEDIUM. That allows the KVM code to save that value into the
+ * guest state (it is the guest's PPR value).
+ */
+BEGIN_FTR_SECTION
+ mfspr r10,SPRN_PPR
+ std r10,PACA_EXGEN+EX_PPR(r13)
+END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
+
+ HMT_MEDIUM
+
#ifdef CONFIG_RELOCATABLE
/*
* Requires __LOAD_FAR_HANDLER beause kvmppc_hcall lives
diff --git a/arch/powerpc/kvm/book3s_64_entry.S b/arch/powerpc/kvm/book3s_64_entry.S
index 66170ea85bc2..a01046202eef 100644
--- a/arch/powerpc/kvm/book3s_64_entry.S
+++ b/arch/powerpc/kvm/book3s_64_entry.S
@@ -11,40 +11,30 @@
* These are branched to from interrupt handlers in exception-64s.S which set
* IKVM_REAL or IKVM_VIRT, if HSTATE_IN_GUEST was found to be non-zero.
*/
+
+/*
+ * This is a hcall, so register convention is as
+ * Documentation/powerpc/papr_hcalls.rst.
+ *
+ * This may also be a syscall from PR-KVM userspace that is to be
+ * reflected to the PR guest kernel, so registers may be set up for
+ * a system call rather than hcall. We don't currently clobber
+ * anything here, but the 0xc00 handler has already clobbered CTR
+ * and CR0, so PR-KVM can not support a guest kernel that preserves
+ * those registers across its system calls.
+ *
+ * The state of registers is as kvmppc_interrupt, except CFAR is not
+ * saved, R13 is not in SCRATCH0, and R10 does not contain the trap.
+ */
.global kvmppc_hcall
.balign IFETCH_ALIGN_BYTES
kvmppc_hcall:
- /*
- * This is a hcall, so register convention is as
- * Documentation/powerpc/papr_hcalls.rst, with these additions:
- * R13 = PACA
- * guest R13 saved in SPRN_SCRATCH0
- * R10 = free
- * guest r10 saved in PACA_EXGEN
- *
- * This may also be a syscall from PR-KVM userspace that is to be
- * reflected to the PR guest kernel, so registers may be set up for
- * a system call rather than hcall. We don't currently clobber
- * anything here, but the 0xc00 handler has already clobbered CTR
- * and CR0, so PR-KVM can not support a guest kernel that preserves
- * those registers across its system calls.
- */
- /*
- * Save the PPR (on systems that support it) before changing to
- * HMT_MEDIUM. That allows the KVM code to save that value into the
- * guest state (it is the guest's PPR value).
- */
-BEGIN_FTR_SECTION
- mfspr r10,SPRN_PPR
- std r10,HSTATE_PPR(r13)
-END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
- HMT_MEDIUM
- mfcr r10
- std r12,HSTATE_SCRATCH0(r13)
- sldi r12,r10,32
- ori r12,r12,0xc00
- ld r10,PACA_EXGEN+EX_R10(r13)
- b do_kvm_interrupt
+ ld r10,PACA_EXGEN+EX_R13(r13)
+ SET_SCRATCH0(r10)
+ li r10,0xc00
+ /* Now we look like kvmppc_interrupt */
+ li r11,PACA_EXGEN
+ b .Lgot_save_area
/*
* KVM interrupt entry occurs after GEN_INT_ENTRY runs, and follows that
@@ -67,12 +57,12 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
kvmppc_interrupt:
li r11,PACA_EXGEN
cmpdi r10,0x200
- bgt+ 1f
+ bgt+ .Lgot_save_area
li r11,PACA_EXMC
- beq 1f
+ beq .Lgot_save_area
li r11,PACA_EXNMI
-1: add r11,r11,r13
-
+.Lgot_save_area:
+ add r11,r11,r13
BEGIN_FTR_SECTION
ld r12,EX_CFAR(r11)
std r12,HSTATE_CFAR(r13)
@@ -91,7 +81,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
ld r10,EX_R10(r11)
ld r11,EX_R11(r11)
-do_kvm_interrupt:
/*
* Hcalls and other interrupts come here after normalising register
* contents and save locations:
--
2.23.0
^ permalink raw reply related
* [PATCH v2] powerpc/eeh: Fix EEH handling for hugepages in ioremap space.
From: Mahesh Salgaonkar @ 2021-04-12 7:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Aneesh Kumar K.V, Oliver O'Halloran, stable
During the EEH MMIO error checking, the current implementation fails to map
the (virtual) MMIO address back to the pci device on radix with hugepage
mappings for I/O. This results into failure to dispatch EEH event with no
recovery even when EEH capability has been enabled on the device.
eeh_check_failure(token) # token = virtual MMIO address
addr = eeh_token_to_phys(token);
edev = eeh_addr_cache_get_dev(addr);
if (!edev)
return 0;
eeh_dev_check_failure(edev); <= Dispatch the EEH event
In case of hugepage mappings, eeh_token_to_phys() has a bug in virt -> phys
translation that results in wrong physical address, which is then passed to
eeh_addr_cache_get_dev() to match it against cached pci I/O address ranges
to get to a PCI device. Hence, it fails to find a match and the EEH event
never gets dispatched leaving the device in failed state.
The commit 33439620680be ("powerpc/eeh: Handle hugepages in ioremap space")
introduced following logic to translate virt to phys for hugepage mappings:
eeh_token_to_phys():
+ pa = pte_pfn(*ptep);
+
+ /* On radix we can do hugepage mappings for io, so handle that */
+ if (hugepage_shift) {
+ pa <<= hugepage_shift; <= This is wrong
+ pa |= token & ((1ul << hugepage_shift) - 1);
+ }
This patch fixes the virt -> phys translation in eeh_token_to_phys()
function.
$ cat /sys/kernel/debug/powerpc/eeh_address_cache
mem addr range [0x0000040080000000-0x00000400807fffff]: 0030:01:00.1
mem addr range [0x0000040080800000-0x0000040080ffffff]: 0030:01:00.1
mem addr range [0x0000040081000000-0x00000400817fffff]: 0030:01:00.0
mem addr range [0x0000040081800000-0x0000040081ffffff]: 0030:01:00.0
mem addr range [0x0000040082000000-0x000004008207ffff]: 0030:01:00.1
mem addr range [0x0000040082080000-0x00000400820fffff]: 0030:01:00.0
mem addr range [0x0000040082100000-0x000004008210ffff]: 0030:01:00.1
mem addr range [0x0000040082110000-0x000004008211ffff]: 0030:01:00.0
Above is the list of cached io address ranges of pci 0030:01:00.<fn>.
Before this patch:
Tracing 'arg1' of function eeh_addr_cache_get_dev() during error injection
clearly shows that 'addr=' contains wrong physical address:
kworker/u16:0-7 [001] .... 108.883775: eeh_addr_cache_get_dev:
(eeh_addr_cache_get_dev+0xc/0xf0) addr=0x80103000a510
dmesg shows no EEH recovery messages:
[ 108.563768] bnx2x: [bnx2x_timer:5801(eth2)]MFW seems hanged: drv_pulse (0x9ae) != mcp_pulse (0x7fff)
[ 108.563788] bnx2x: [bnx2x_hw_stats_update:870(eth2)]NIG timer max (4294967295)
[ 108.883788] bnx2x: [bnx2x_acquire_hw_lock:2013(eth1)]lock_status 0xffffffff resource_bit 0x1
[ 108.884407] bnx2x 0030:01:00.0 eth1: MDC/MDIO access timeout
[ 108.884976] bnx2x 0030:01:00.0 eth1: MDC/MDIO access timeout
<..>
After this patch:
eeh_addr_cache_get_dev() trace shows correct physical address:
<idle>-0 [001] ..s. 1043.123828: eeh_addr_cache_get_dev:
(eeh_addr_cache_get_dev+0xc/0xf0) addr=0x40080bc7cd8
dmesg logs shows EEH recovery getting triggerred:
[ 964.323980] bnx2x: [bnx2x_timer:5801(eth2)]MFW seems hanged: drv_pulse (0x746f) != mcp_pulse (0x7fff)
[ 964.323991] EEH: Recovering PHB#30-PE#10000
[ 964.324002] EEH: PE location: N/A, PHB location: N/A
[ 964.324006] EEH: Frozen PHB#30-PE#10000 detected
<..>
Cc: stable@vger.kernel.org
Fixes: 33439620680be ("powerpc/eeh: Handle hugepages in ioremap space")
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Reported-by: Dominic DeMarco <ddemarc@us.ibm.com>
---
Change in v2:
- Fixed error reported by checkpatch.pl.
---
arch/powerpc/kernel/eeh.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index cd60bc1c87011..7040e430a1249 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -362,14 +362,11 @@ static inline unsigned long eeh_token_to_phys(unsigned long token)
pa = pte_pfn(*ptep);
/* On radix we can do hugepage mappings for io, so handle that */
- if (hugepage_shift) {
- pa <<= hugepage_shift;
- pa |= token & ((1ul << hugepage_shift) - 1);
- } else {
- pa <<= PAGE_SHIFT;
- pa |= token & (PAGE_SIZE - 1);
- }
+ if (!hugepage_shift)
+ hugepage_shift = PAGE_SHIFT;
+ pa <<= PAGE_SHIFT;
+ pa |= token & ((1ul << hugepage_shift) - 1);
return pa;
}
^ permalink raw reply related
* Re: [PATCH V2] mm/page_alloc: Ensure that HUGETLB_PAGE_ORDER is less than MAX_ORDER
From: Anshuman Khandual @ 2021-04-12 8:06 UTC (permalink / raw)
To: linux-mm, akpm
Cc: linux-ia64@vger.kernel.org, linuxppc-dev @ lists . ozlabs . org,
linux-kernel, David Hildenbrand
In-Reply-To: <1618199302-29335-1-git-send-email-anshuman.khandual@arm.com>
+ linuxppc-dev@lists.ozlabs.org
+ linux-ia64@vger.kernel.org
On 4/12/21 9:18 AM, Anshuman Khandual wrote:
> pageblock_order must always be less than MAX_ORDER, otherwise it might lead
> to an warning during boot. A similar problem got fixed on arm64 platform
> with the commit 79cc2ed5a716 ("arm64/mm: Drop THP conditionality from
> FORCE_MAX_ZONEORDER"). Assert the above condition before HUGETLB_PAGE_ORDER
> gets assigned as pageblock_order. This will help detect the problem earlier
> on platforms where HUGETLB_PAGE_SIZE_VARIABLE is enabled.
>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: linux-mm@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> Changes in V2:
>
> - Changed WARN_ON() to BUILD_BUG_ON() per David
>
> Changes in V1:
>
> https://patchwork.kernel.org/project/linux-mm/patch/1617947717-2424-1-git-send-email-anshuman.khandual@arm.com/
>
> mm/page_alloc.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index cfc72873961d..19283bff4bec 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6875,10 +6875,17 @@ void __init set_pageblock_order(void)
> if (pageblock_order)
> return;
>
> - if (HPAGE_SHIFT > PAGE_SHIFT)
> + if (HPAGE_SHIFT > PAGE_SHIFT) {
> + /*
> + * pageblock_order must always be less than
> + * MAX_ORDER. So does HUGETLB_PAGE_ORDER if
> + * that is being assigned here.
> + */
> + BUILD_BUG_ON(HUGETLB_PAGE_ORDER >= MAX_ORDER);
Unfortunately the build test fails on both the platforms (powerpc and ia64)
which subscribe HUGETLB_PAGE_SIZE_VARIABLE and where this check would make
sense. I some how overlooked the cross compile build failure that actually
detected this problem.
But wondering why this assert is not holding true ? and how these platforms
do not see the warning during boot (or do they ?) at mm/vmscan.c:1092 like
arm64 did.
static int __fragmentation_index(unsigned int order, struct contig_page_info *info)
{
unsigned long requested = 1UL << order;
if (WARN_ON_ONCE(order >= MAX_ORDER))
return 0;
....
Can pageblock_order really exceed MAX_ORDER - 1 ?
> order = HUGETLB_PAGE_ORDER;
> - else
> + } else {
> order = MAX_ORDER - 1;
> + }
>
> /*
> * Assume the largest contiguous order of interest is a huge page.
>
^ permalink raw reply
* Re: [PATCH V2] mm/page_alloc: Ensure that HUGETLB_PAGE_ORDER is less than MAX_ORDER
From: David Hildenbrand @ 2021-04-12 8:47 UTC (permalink / raw)
To: Anshuman Khandual, linux-mm, akpm
Cc: linux-ia64@vger.kernel.org, linuxppc-dev @ lists . ozlabs . org,
linux-kernel, Michal Hocko, Mel Gorman, Vlastimil Babka
In-Reply-To: <09284b9a-cfe1-fc49-e1f6-3cf0c1b74c76@arm.com>
On 12.04.21 10:06, Anshuman Khandual wrote:
> + linuxppc-dev@lists.ozlabs.org
> + linux-ia64@vger.kernel.org
>
> On 4/12/21 9:18 AM, Anshuman Khandual wrote:
>> pageblock_order must always be less than MAX_ORDER, otherwise it might lead
>> to an warning during boot. A similar problem got fixed on arm64 platform
>> with the commit 79cc2ed5a716 ("arm64/mm: Drop THP conditionality from
>> FORCE_MAX_ZONEORDER"). Assert the above condition before HUGETLB_PAGE_ORDER
>> gets assigned as pageblock_order. This will help detect the problem earlier
>> on platforms where HUGETLB_PAGE_SIZE_VARIABLE is enabled.
>>
>> Cc: David Hildenbrand <david@redhat.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> Changes in V2:
>>
>> - Changed WARN_ON() to BUILD_BUG_ON() per David
>>
>> Changes in V1:
>>
>> https://patchwork.kernel.org/project/linux-mm/patch/1617947717-2424-1-git-send-email-anshuman.khandual@arm.com/
>>
>> mm/page_alloc.c | 11 +++++++++--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index cfc72873961d..19283bff4bec 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -6875,10 +6875,17 @@ void __init set_pageblock_order(void)
>> if (pageblock_order)
>> return;
>>
>> - if (HPAGE_SHIFT > PAGE_SHIFT)
>> + if (HPAGE_SHIFT > PAGE_SHIFT) {
>> + /*
>> + * pageblock_order must always be less than
>> + * MAX_ORDER. So does HUGETLB_PAGE_ORDER if
>> + * that is being assigned here.
>> + */
>> + BUILD_BUG_ON(HUGETLB_PAGE_ORDER >= MAX_ORDER);
>
> Unfortunately the build test fails on both the platforms (powerpc and ia64)
> which subscribe HUGETLB_PAGE_SIZE_VARIABLE and where this check would make
> sense. I some how overlooked the cross compile build failure that actually
> detected this problem.
>
> But wondering why this assert is not holding true ? and how these platforms
> do not see the warning during boot (or do they ?) at mm/vmscan.c:1092 like
> arm64 did.
>
> static int __fragmentation_index(unsigned int order, struct contig_page_info *info)
> {
> unsigned long requested = 1UL << order;
>
> if (WARN_ON_ONCE(order >= MAX_ORDER))
> return 0;
> ....
>
> Can pageblock_order really exceed MAX_ORDER - 1 ?
Ehm, for now I was under the impression that such configurations
wouldn't exist.
And originally, HUGETLB_PAGE_SIZE_VARIABLE was introduced to handle
hugepage sizes that all *smaller* than MAX_ORDER - 1: See d9c234005227
("Do not depend on MAX_ORDER when grouping pages by mobility")
However, looking into init_cma_reserved_pageblock():
if (pageblock_order >= MAX_ORDER) {
i = pageblock_nr_pages;
...
}
But it's kind of weird, isn't it? Let's assume we have MAX_ORDER - 1
correspond to 4 MiB and pageblock_order correspond to 8 MiB.
Sure, we'd be grouping pages in 8 MiB chunks, however, we cannot even
allocate 8 MiB chunks via the buddy. So only alloc_contig_range() could
really grab them (IOW: gigantic pages).
Further, we have code like deferred_free_range(), where we end up
calling __free_pages_core()->...->__free_one_page() with
pageblock_order. Wouldn't we end up setting the buddy order to something
> MAX_ORDER -1 on that path?
Having pageblock_order > MAX_ORDER feels wrong and looks shaky.
--
Thanks,
David / dhildenb
^ permalink raw reply
* [PATCH 5/5] compat: consolidate the compat_flock{,64} definition
From: Christoph Hellwig @ 2021-04-12 8:55 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
James E.J. Bottomley, Helge Deller, Michael Ellerman,
Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
David S. Miller, x86, Arnd Bergmann
Cc: linux-arch, linux-s390, linux-parisc, linux-kernel, linux-mips,
sparclinux, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20210412085545.2595431-1-hch@lst.de>
Provide a single common definition for the compat_flock and
compat_flock64 structures using the same tricks as for the native
variants. An extra define is added for the packing required on x86.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm64/include/asm/compat.h | 16 ----------------
arch/mips/include/asm/compat.h | 19 ++-----------------
arch/parisc/include/asm/compat.h | 16 ----------------
arch/powerpc/include/asm/compat.h | 16 ----------------
arch/s390/include/asm/compat.h | 16 ----------------
arch/sparc/include/asm/compat.h | 18 +-----------------
arch/x86/include/asm/compat.h | 20 +++-----------------
include/linux/compat.h | 31 +++++++++++++++++++++++++++++++
8 files changed, 37 insertions(+), 115 deletions(-)
diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index a5fe4558a6ecc0..6f0908606b2b51 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -66,22 +66,6 @@ struct compat_stat {
compat_ulong_t __unused4[2];
};
-struct compat_flock {
- short l_type;
- short l_whence;
- compat_off_t l_start;
- compat_off_t l_len;
- compat_pid_t l_pid;
-};
-
-struct compat_flock64 {
- short l_type;
- short l_whence;
- compat_loff_t l_start;
- compat_loff_t l_len;
- compat_pid_t l_pid;
-};
-
struct compat_statfs {
int f_type;
int f_bsize;
diff --git a/arch/mips/include/asm/compat.h b/arch/mips/include/asm/compat.h
index a13436e91c3938..7df384e445de06 100644
--- a/arch/mips/include/asm/compat.h
+++ b/arch/mips/include/asm/compat.h
@@ -50,23 +50,8 @@ struct compat_stat {
s32 st_pad4[14];
};
-struct compat_flock {
- short l_type;
- short l_whence;
- compat_off_t l_start;
- compat_off_t l_len;
- s32 l_sysid;
- compat_pid_t l_pid;
- s32 pad[4];
-};
-
-struct compat_flock64 {
- short l_type;
- short l_whence;
- compat_loff_t l_start;
- compat_loff_t l_len;
- compat_pid_t l_pid;
-};
+#define __ARCH_COMPAT_FLOCK_EXTRA_SYSID s32 l_sysid;
+#define __ARCH_COMPAT_FLOCK_PAD s32 pad[4];
struct compat_statfs {
int f_type;
diff --git a/arch/parisc/include/asm/compat.h b/arch/parisc/include/asm/compat.h
index 1a609d38f6678e..972bf8911d1126 100644
--- a/arch/parisc/include/asm/compat.h
+++ b/arch/parisc/include/asm/compat.h
@@ -54,22 +54,6 @@ struct compat_stat {
u32 st_spare4[3];
};
-struct compat_flock {
- short l_type;
- short l_whence;
- compat_off_t l_start;
- compat_off_t l_len;
- compat_pid_t l_pid;
-};
-
-struct compat_flock64 {
- short l_type;
- short l_whence;
- compat_loff_t l_start;
- compat_loff_t l_len;
- compat_pid_t l_pid;
-};
-
struct compat_statfs {
s32 f_type;
s32 f_bsize;
diff --git a/arch/powerpc/include/asm/compat.h b/arch/powerpc/include/asm/compat.h
index b0f2c3f7fe45a5..e9d433bd561725 100644
--- a/arch/powerpc/include/asm/compat.h
+++ b/arch/powerpc/include/asm/compat.h
@@ -48,22 +48,6 @@ struct compat_stat {
u32 __unused4[2];
};
-struct compat_flock {
- short l_type;
- short l_whence;
- compat_off_t l_start;
- compat_off_t l_len;
- compat_pid_t l_pid;
-};
-
-struct compat_flock64 {
- short l_type;
- short l_whence;
- compat_loff_t l_start;
- compat_loff_t l_len;
- compat_pid_t l_pid;
-};
-
struct compat_statfs {
int f_type;
int f_bsize;
diff --git a/arch/s390/include/asm/compat.h b/arch/s390/include/asm/compat.h
index e0896758779da4..5578607913b847 100644
--- a/arch/s390/include/asm/compat.h
+++ b/arch/s390/include/asm/compat.h
@@ -103,22 +103,6 @@ struct compat_stat {
u32 __unused5;
};
-struct compat_flock {
- short l_type;
- short l_whence;
- compat_off_t l_start;
- compat_off_t l_len;
- compat_pid_t l_pid;
-};
-
-struct compat_flock64 {
- short l_type;
- short l_whence;
- compat_loff_t l_start;
- compat_loff_t l_len;
- compat_pid_t l_pid;
-};
-
struct compat_statfs {
u32 f_type;
u32 f_bsize;
diff --git a/arch/sparc/include/asm/compat.h b/arch/sparc/include/asm/compat.h
index 4524997424043f..16fa333f28c274 100644
--- a/arch/sparc/include/asm/compat.h
+++ b/arch/sparc/include/asm/compat.h
@@ -76,23 +76,7 @@ struct compat_stat64 {
unsigned int __unused5;
};
-struct compat_flock {
- short l_type;
- short l_whence;
- compat_off_t l_start;
- compat_off_t l_len;
- compat_pid_t l_pid;
- short __unused;
-};
-
-struct compat_flock64 {
- short l_type;
- short l_whence;
- compat_loff_t l_start;
- compat_loff_t l_len;
- compat_pid_t l_pid;
- short __unused;
-};
+#define __ARCH_COMPAT_FLOCK_PAD short __unused;
struct compat_statfs {
int f_type;
diff --git a/arch/x86/include/asm/compat.h b/arch/x86/include/asm/compat.h
index b1691cf148be10..d8e01bf51e7a26 100644
--- a/arch/x86/include/asm/compat.h
+++ b/arch/x86/include/asm/compat.h
@@ -51,25 +51,11 @@ struct compat_stat {
u32 __unused5;
};
-struct compat_flock {
- short l_type;
- short l_whence;
- compat_off_t l_start;
- compat_off_t l_len;
- compat_pid_t l_pid;
-};
-
/*
- * IA32 uses 4 byte alignment for 64 bit quantities,
- * so we need to pack this structure.
+ * IA32 uses 4 byte alignment for 64 bit quantities, so we need to pack the
+ * compat flock64 structure.
*/
-struct compat_flock64 {
- short l_type;
- short l_whence;
- compat_loff_t l_start;
- compat_loff_t l_len;
- compat_pid_t l_pid;
-} __attribute__((packed));
+#define __ARCH_NEED_COMPAT_FLOCK64_PACKED
struct compat_statfs {
int f_type;
diff --git a/include/linux/compat.h b/include/linux/compat.h
index 6e65be75360321..9d196f8a94d5ea 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -258,6 +258,37 @@ struct compat_rlimit {
compat_ulong_t rlim_max;
};
+#ifdef __ARCH_NEED_COMPAT_FLOCK64_PACKED
+#define __ARCH_COMPAT_FLOCK64_PACK __attribute__((packed))
+#else
+#define __ARCH_COMPAT_FLOCK64_PACK
+#endif
+
+struct compat_flock {
+ short l_type;
+ short l_whence;
+ compat_off_t l_start;
+ compat_off_t l_len;
+#ifdef __ARCH_COMPAT_FLOCK_EXTRA_SYSID
+ __ARCH_COMPAT_FLOCK_EXTRA_SYSID
+#endif
+ compat_pid_t l_pid;
+#ifdef __ARCH_COMPAT_FLOCK_PAD
+ __ARCH_COMPAT_FLOCK_PAD
+#endif
+};
+
+struct compat_flock64 {
+ short l_type;
+ short l_whence;
+ compat_loff_t l_start;
+ compat_loff_t l_len;
+ compat_pid_t l_pid;
+#ifdef __ARCH_COMPAT_FLOCK64_PAD
+ __ARCH_COMPAT_FLOCK64_PAD
+#endif
+} __ARCH_COMPAT_FLOCK64_PACK;
+
struct compat_rusage {
struct old_timeval32 ru_utime;
struct old_timeval32 ru_stime;
--
2.30.1
^ permalink raw reply related
* [PATCH 2/5] uapi: simplify __ARCH_FLOCK{,64}_PAD a little
From: Christoph Hellwig @ 2021-04-12 8:55 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
James E.J. Bottomley, Helge Deller, Michael Ellerman,
Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
David S. Miller, x86, Arnd Bergmann
Cc: linux-arch, linux-s390, linux-parisc, linux-kernel, linux-mips,
sparclinux, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20210412085545.2595431-1-hch@lst.de>
Don't bother to define emtpty versions of the macros if the architecture
doesn't define them.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
include/uapi/asm-generic/fcntl.h | 12 ++++--------
tools/include/uapi/asm-generic/fcntl.h | 12 ++++--------
2 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index fb454bb629d114..df7ad6962dff71 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -189,22 +189,16 @@ struct f_owner_ex {
#define F_LINUX_SPECIFIC_BASE 1024
#ifndef HAVE_ARCH_STRUCT_FLOCK
-#ifndef __ARCH_FLOCK_PAD
-#define __ARCH_FLOCK_PAD
-#endif
-
struct flock {
short l_type;
short l_whence;
__kernel_off_t l_start;
__kernel_off_t l_len;
__kernel_pid_t l_pid;
+#ifdef __ARCH_FLOCK_PAD
__ARCH_FLOCK_PAD
-};
#endif
-
-#ifndef __ARCH_FLOCK64_PAD
-#define __ARCH_FLOCK64_PAD
+};
#endif
struct flock64 {
@@ -213,7 +207,9 @@ struct flock64 {
__kernel_loff_t l_start;
__kernel_loff_t l_len;
__kernel_pid_t l_pid;
+#ifdef __ARCH_FLOCK64_PAD
__ARCH_FLOCK64_PAD
+#endif
};
#endif /* _ASM_GENERIC_FCNTL_H */
diff --git a/tools/include/uapi/asm-generic/fcntl.h b/tools/include/uapi/asm-generic/fcntl.h
index 4a49d33ca4d55d..82054502b9748d 100644
--- a/tools/include/uapi/asm-generic/fcntl.h
+++ b/tools/include/uapi/asm-generic/fcntl.h
@@ -188,22 +188,16 @@ struct f_owner_ex {
#define F_LINUX_SPECIFIC_BASE 1024
#ifndef HAVE_ARCH_STRUCT_FLOCK
-#ifndef __ARCH_FLOCK_PAD
-#define __ARCH_FLOCK_PAD
-#endif
-
struct flock {
short l_type;
short l_whence;
__kernel_off_t l_start;
__kernel_off_t l_len;
__kernel_pid_t l_pid;
+#ifdef __ARCH_FLOCK_PAD
__ARCH_FLOCK_PAD
-};
#endif
-
-#ifndef __ARCH_FLOCK64_PAD
-#define __ARCH_FLOCK64_PAD
+};
#endif
struct flock64 {
@@ -212,7 +206,9 @@ struct flock64 {
__kernel_loff_t l_start;
__kernel_loff_t l_len;
__kernel_pid_t l_pid;
+#ifdef __ARCH_FLOCK64_PAD
__ARCH_FLOCK64_PAD
+#endif
};
#endif /* _ASM_GENERIC_FCNTL_H */
--
2.30.1
^ permalink raw reply related
* [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h
From: Christoph Hellwig @ 2021-04-12 8:55 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
James E.J. Bottomley, Helge Deller, Michael Ellerman,
Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
David S. Miller, x86, Arnd Bergmann
Cc: linux-arch, linux-s390, linux-parisc, linux-kernel, linux-mips,
sparclinux, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20210412085545.2595431-1-hch@lst.de>
The F_GETLK64/F_SETLK64/F_SETLKW64 commands are only implemented for
32-bit syscall APIs, but we also need them for compat handling on 64-bit
kernels.
Given that redefining them is rather error prone, as shown by parisc
getting the opcodes wrong currently, just use the existing definitions
for the compat handling.
In theory we could try to hide them from userspace; but given that only
MIPS manages to properly do that while the asm-generic version used by
most architectures relies on a Kconfig symbol that is never set by
userspace there doesn't seem to be much of a point to even bother.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm64/include/asm/compat.h | 4 ----
arch/mips/include/asm/compat.h | 4 ----
arch/mips/include/uapi/asm/fcntl.h | 2 --
arch/powerpc/include/asm/compat.h | 4 ----
arch/s390/include/asm/compat.h | 4 ----
arch/sparc/include/asm/compat.h | 4 ----
arch/x86/include/asm/compat.h | 4 ----
include/uapi/asm-generic/fcntl.h | 2 --
tools/include/uapi/asm-generic/fcntl.h | 2 --
9 files changed, 30 deletions(-)
diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index 23a9fb73c04ff8..a5fe4558a6ecc0 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -74,10 +74,6 @@ struct compat_flock {
compat_pid_t l_pid;
};
-#define F_GETLK64 12 /* using 'struct flock64' */
-#define F_SETLK64 13
-#define F_SETLKW64 14
-
struct compat_flock64 {
short l_type;
short l_whence;
diff --git a/arch/mips/include/asm/compat.h b/arch/mips/include/asm/compat.h
index 65975712a22dcf..a13436e91c3938 100644
--- a/arch/mips/include/asm/compat.h
+++ b/arch/mips/include/asm/compat.h
@@ -60,10 +60,6 @@ struct compat_flock {
s32 pad[4];
};
-#define F_GETLK64 33
-#define F_SETLK64 34
-#define F_SETLKW64 35
-
struct compat_flock64 {
short l_type;
short l_whence;
diff --git a/arch/mips/include/uapi/asm/fcntl.h b/arch/mips/include/uapi/asm/fcntl.h
index 9e44ac810db94d..1769fc50d35f0e 100644
--- a/arch/mips/include/uapi/asm/fcntl.h
+++ b/arch/mips/include/uapi/asm/fcntl.h
@@ -44,11 +44,9 @@
#define F_SETOWN 24 /* for sockets. */
#define F_GETOWN 23 /* for sockets. */
-#ifndef __mips64
#define F_GETLK64 33 /* using 'struct flock64' */
#define F_SETLK64 34
#define F_SETLKW64 35
-#endif
#if _MIPS_SIM != _MIPS_SIM_ABI64
#define __ARCH_FLOCK_EXTRA_SYSID long l_sysid;
diff --git a/arch/powerpc/include/asm/compat.h b/arch/powerpc/include/asm/compat.h
index 9191fc29e6ed11..b0f2c3f7fe45a5 100644
--- a/arch/powerpc/include/asm/compat.h
+++ b/arch/powerpc/include/asm/compat.h
@@ -56,10 +56,6 @@ struct compat_flock {
compat_pid_t l_pid;
};
-#define F_GETLK64 12 /* using 'struct flock64' */
-#define F_SETLK64 13
-#define F_SETLKW64 14
-
struct compat_flock64 {
short l_type;
short l_whence;
diff --git a/arch/s390/include/asm/compat.h b/arch/s390/include/asm/compat.h
index ea5b9c34b7be5b..e0896758779da4 100644
--- a/arch/s390/include/asm/compat.h
+++ b/arch/s390/include/asm/compat.h
@@ -111,10 +111,6 @@ struct compat_flock {
compat_pid_t l_pid;
};
-#define F_GETLK64 12
-#define F_SETLK64 13
-#define F_SETLKW64 14
-
struct compat_flock64 {
short l_type;
short l_whence;
diff --git a/arch/sparc/include/asm/compat.h b/arch/sparc/include/asm/compat.h
index b85842cda99fe0..4524997424043f 100644
--- a/arch/sparc/include/asm/compat.h
+++ b/arch/sparc/include/asm/compat.h
@@ -85,10 +85,6 @@ struct compat_flock {
short __unused;
};
-#define F_GETLK64 12
-#define F_SETLK64 13
-#define F_SETLKW64 14
-
struct compat_flock64 {
short l_type;
short l_whence;
diff --git a/arch/x86/include/asm/compat.h b/arch/x86/include/asm/compat.h
index be09c7eac89f09..b1691cf148be10 100644
--- a/arch/x86/include/asm/compat.h
+++ b/arch/x86/include/asm/compat.h
@@ -59,10 +59,6 @@ struct compat_flock {
compat_pid_t l_pid;
};
-#define F_GETLK64 12 /* using 'struct flock64' */
-#define F_SETLK64 13
-#define F_SETLKW64 14
-
/*
* IA32 uses 4 byte alignment for 64 bit quantities,
* so we need to pack this structure.
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index 7e714443a8d2e3..6430a2f8023fc3 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -116,13 +116,11 @@
#define F_GETSIG 11 /* for sockets. */
#endif
-#ifndef CONFIG_64BIT
#ifndef F_GETLK64
#define F_GETLK64 12 /* using 'struct flock64' */
#define F_SETLK64 13
#define F_SETLKW64 14
#endif
-#endif
#ifndef F_SETOWN_EX
#define F_SETOWN_EX 15
diff --git a/tools/include/uapi/asm-generic/fcntl.h b/tools/include/uapi/asm-generic/fcntl.h
index bf961a71802e0e..6e16722026f39a 100644
--- a/tools/include/uapi/asm-generic/fcntl.h
+++ b/tools/include/uapi/asm-generic/fcntl.h
@@ -115,13 +115,11 @@
#define F_GETSIG 11 /* for sockets. */
#endif
-#ifndef CONFIG_64BIT
#ifndef F_GETLK64
#define F_GETLK64 12 /* using 'struct flock64' */
#define F_SETLK64 13
#define F_SETLKW64 14
#endif
-#endif
#ifndef F_SETOWN_EX
#define F_SETOWN_EX 15
--
2.30.1
^ permalink raw reply related
* consolidate the flock uapi definitions
From: Christoph Hellwig @ 2021-04-12 8:55 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
James E.J. Bottomley, Helge Deller, Michael Ellerman,
Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
David S. Miller, x86, Arnd Bergmann
Cc: linux-arch, linux-s390, linux-parisc, linux-kernel, linux-mips,
sparclinux, linuxppc-dev, linux-arm-kernel
Hi all,
currently we deal with the slight differents in the various architecture
variants of the flock and flock64 stuctures in a very cruft way. This
series switches to just use small arch hooks and define the rest in
asm-generic and linux/compat.h instead.
Diffstat:
arch/arm64/include/asm/compat.h | 20 --------------------
arch/mips/include/asm/compat.h | 23 ++---------------------
arch/mips/include/uapi/asm/fcntl.h | 28 +++-------------------------
arch/parisc/include/asm/compat.h | 16 ----------------
arch/powerpc/include/asm/compat.h | 20 --------------------
arch/s390/include/asm/compat.h | 20 --------------------
arch/sparc/include/asm/compat.h | 22 +---------------------
arch/x86/include/asm/compat.h | 24 +++---------------------
include/linux/compat.h | 31 +++++++++++++++++++++++++++++++
include/uapi/asm-generic/fcntl.h | 21 +++++++--------------
tools/include/uapi/asm-generic/fcntl.h | 21 +++++++--------------
11 files changed, 54 insertions(+), 192 deletions(-)
^ permalink raw reply
* [PATCH 1/5] uapi: remove the unused HAVE_ARCH_STRUCT_FLOCK64 define
From: Christoph Hellwig @ 2021-04-12 8:55 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
James E.J. Bottomley, Helge Deller, Michael Ellerman,
Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
David S. Miller, x86, Arnd Bergmann
Cc: linux-arch, linux-s390, linux-parisc, linux-kernel, linux-mips,
sparclinux, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20210412085545.2595431-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
include/uapi/asm-generic/fcntl.h | 2 --
tools/include/uapi/asm-generic/fcntl.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index 9dc0bf0c5a6ee8..fb454bb629d114 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -203,7 +203,6 @@ struct flock {
};
#endif
-#ifndef HAVE_ARCH_STRUCT_FLOCK64
#ifndef __ARCH_FLOCK64_PAD
#define __ARCH_FLOCK64_PAD
#endif
@@ -216,6 +215,5 @@ struct flock64 {
__kernel_pid_t l_pid;
__ARCH_FLOCK64_PAD
};
-#endif
#endif /* _ASM_GENERIC_FCNTL_H */
diff --git a/tools/include/uapi/asm-generic/fcntl.h b/tools/include/uapi/asm-generic/fcntl.h
index ac190958c98144..4a49d33ca4d55d 100644
--- a/tools/include/uapi/asm-generic/fcntl.h
+++ b/tools/include/uapi/asm-generic/fcntl.h
@@ -202,7 +202,6 @@ struct flock {
};
#endif
-#ifndef HAVE_ARCH_STRUCT_FLOCK64
#ifndef __ARCH_FLOCK64_PAD
#define __ARCH_FLOCK64_PAD
#endif
@@ -215,6 +214,5 @@ struct flock64 {
__kernel_pid_t l_pid;
__ARCH_FLOCK64_PAD
};
-#endif
#endif /* _ASM_GENERIC_FCNTL_H */
--
2.30.1
^ permalink raw reply related
* [PATCH 3/5] uapi: merge the 32-bit mips struct flock into the generic one
From: Christoph Hellwig @ 2021-04-12 8:55 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Thomas Bogendoerfer,
James E.J. Bottomley, Helge Deller, Michael Ellerman,
Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
David S. Miller, x86, Arnd Bergmann
Cc: linux-arch, linux-s390, linux-parisc, linux-kernel, linux-mips,
sparclinux, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20210412085545.2595431-1-hch@lst.de>
Add a new __ARCH_FLOCK_EXTRA_SYSID macro following the style of
__ARCH_FLOCK_PAD to avoid having a separate definition just for one
architecture.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/mips/include/uapi/asm/fcntl.h | 26 +++-----------------------
include/uapi/asm-generic/fcntl.h | 5 +++--
tools/include/uapi/asm-generic/fcntl.h | 5 +++--
3 files changed, 9 insertions(+), 27 deletions(-)
diff --git a/arch/mips/include/uapi/asm/fcntl.h b/arch/mips/include/uapi/asm/fcntl.h
index 42e13dead54319..9e44ac810db94d 100644
--- a/arch/mips/include/uapi/asm/fcntl.h
+++ b/arch/mips/include/uapi/asm/fcntl.h
@@ -50,30 +50,10 @@
#define F_SETLKW64 35
#endif
-/*
- * The flavours of struct flock. "struct flock" is the ABI compliant
- * variant. Finally struct flock64 is the LFS variant of struct flock. As
- * a historic accident and inconsistence with the ABI definition it doesn't
- * contain all the same fields as struct flock.
- */
-
#if _MIPS_SIM != _MIPS_SIM_ABI64
-
-#include <linux/types.h>
-
-struct flock {
- short l_type;
- short l_whence;
- __kernel_off_t l_start;
- __kernel_off_t l_len;
- long l_sysid;
- __kernel_pid_t l_pid;
- long pad[4];
-};
-
-#define HAVE_ARCH_STRUCT_FLOCK
-
-#endif /* _MIPS_SIM == _MIPS_SIM_ABI32 */
+#define __ARCH_FLOCK_EXTRA_SYSID long l_sysid;
+#define __ARCH_FLOCK_PAD long pad[4];
+#endif
#include <asm-generic/fcntl.h>
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index df7ad6962dff71..7e714443a8d2e3 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -188,18 +188,19 @@ struct f_owner_ex {
#define F_LINUX_SPECIFIC_BASE 1024
-#ifndef HAVE_ARCH_STRUCT_FLOCK
struct flock {
short l_type;
short l_whence;
__kernel_off_t l_start;
__kernel_off_t l_len;
+#ifdef __ARCH_FLOCK_EXTRA_SYSID
+ __ARCH_FLOCK_EXTRA_SYSID
+#endif
__kernel_pid_t l_pid;
#ifdef __ARCH_FLOCK_PAD
__ARCH_FLOCK_PAD
#endif
};
-#endif
struct flock64 {
short l_type;
diff --git a/tools/include/uapi/asm-generic/fcntl.h b/tools/include/uapi/asm-generic/fcntl.h
index 82054502b9748d..bf961a71802e0e 100644
--- a/tools/include/uapi/asm-generic/fcntl.h
+++ b/tools/include/uapi/asm-generic/fcntl.h
@@ -187,18 +187,19 @@ struct f_owner_ex {
#define F_LINUX_SPECIFIC_BASE 1024
-#ifndef HAVE_ARCH_STRUCT_FLOCK
struct flock {
short l_type;
short l_whence;
__kernel_off_t l_start;
__kernel_off_t l_len;
+#ifdef __ARCH_FLOCK_EXTRA_SYSID
+ __ARCH_FLOCK_EXTRA_SYSID
+#endif
__kernel_pid_t l_pid;
#ifdef __ARCH_FLOCK_PAD
__ARCH_FLOCK_PAD
#endif
};
-#endif
struct flock64 {
short l_type;
--
2.30.1
^ permalink raw reply related
* RE: [PATCH 5/5] compat: consolidate the compat_flock{,64} definition
From: David Laight @ 2021-04-12 9:37 UTC (permalink / raw)
To: 'Christoph Hellwig', Catalin Marinas, Will Deacon,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, David S. Miller, x86@kernel.org,
Arnd Bergmann
Cc: linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mips@vger.kernel.org, sparclinux@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20210412085545.2595431-6-hch@lst.de>
From: Christoph Hellwig
> Sent: 12 April 2021 09:56
>
> Provide a single common definition for the compat_flock and
> compat_flock64 structures using the same tricks as for the native
> variants. An extra define is added for the packing required on x86.
>
...
> /*
> - * IA32 uses 4 byte alignment for 64 bit quantities,
> - * so we need to pack this structure.
> + * IA32 uses 4 byte alignment for 64 bit quantities, so we need to pack the
> + * compat flock64 structure.
> */
> -struct compat_flock64 {
> - short l_type;
> - short l_whence;
> - compat_loff_t l_start;
> - compat_loff_t l_len;
> - compat_pid_t l_pid;
> -} __attribute__((packed));
> +#define __ARCH_NEED_COMPAT_FLOCK64_PACKED
That shouldn't need to be packed at all.
(Since the 32bit variant isn't packed.)
compat_loff_t should itself have __attribute__((aligned(4)))
probably inherited from compat_s64.
So l_start will be at offset 4 without the __packed.
I'm guessing that compat_pid_t is 16 bits?
So the native 32bit version has an unnamed 2 byte structure pad.
The 'packed' removes this pad from the compat structure.
AFAICT (apart from mips) the __ARCH_COMPAT_FLOCK_PAD is just
adding an explicit pad for the implicit pad the compiler
would generate because compat_pid_t is 16 bits.
If the padding need not be named for the 64bit system calls.
(Where there is probably rather more padding all over the place.)
then it doesn't need to be named for the compat variants.
Even the mips extra padding could be removed.
F_GETLK might be expected to do a read-write of them, so
return EFAULT if not mapped.
But nothing should be testing the EFAULT is returned!
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH 1/2] vfio/pci: remove vfio_pci_nvlink2
From: Michael Ellerman @ 2021-04-12 9:41 UTC (permalink / raw)
To: Alex Williamson, Christoph Hellwig
Cc: Jason Gunthorpe, kvm, David Airlie, linux-kernel, dri-devel,
Paul Mackerras, Daniel Vetter, Greg Kroah-Hartman, linux-api,
linuxppc-dev
In-Reply-To: <20210406133805.715120bd@omen>
Alex Williamson <alex.williamson@redhat.com> writes:
> On Fri, 26 Mar 2021 07:13:10 +0100
> Christoph Hellwig <hch@lst.de> wrote:
>
>> This driver never had any open userspace (which for VFIO would include
>> VM kernel drivers) that use it, and thus should never have been added
>> by our normal userspace ABI rules.
>>
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> ---
>> drivers/vfio/pci/Kconfig | 6 -
>> drivers/vfio/pci/Makefile | 1 -
>> drivers/vfio/pci/vfio_pci.c | 18 -
>> drivers/vfio/pci/vfio_pci_nvlink2.c | 490 ----------------------------
>> drivers/vfio/pci/vfio_pci_private.h | 14 -
>> include/uapi/linux/vfio.h | 38 +--
>> 6 files changed, 4 insertions(+), 563 deletions(-)
>> delete mode 100644 drivers/vfio/pci/vfio_pci_nvlink2.c
>
> Hearing no objections, applied to vfio next branch for v5.13. Thanks,
Looks like you only took patch 1?
I can't take patch 2 on its own, that would break the build.
Do you want to take both patches? There's currently no conflicts against
my tree. It's possible one could appear before the v5.13 merge window,
though it would probably just be something minor.
Or I could apply both patches to my tree, which means patch 1 would
appear as two commits in the git history, but that's not a big deal.
cheers
^ permalink raw reply
* Re: [RFC/PATCH] powerpc/smp: Add SD_SHARE_PKG_RESOURCES flag to MC sched-domain
From: Mel Gorman @ 2021-04-12 9:37 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Gautham R. Shenoy, Michael Neuling, Vaidyanathan Srinivasan,
Vincent Guittot, Rik van Riel, LKML, Nicholas Piggin,
Dietmar Eggemann, Parth Shah, linuxppc-dev, Valentin Schneider
In-Reply-To: <20210412062436.GB2633526@linux.vnet.ibm.com>
On Mon, Apr 12, 2021 at 11:54:36AM +0530, Srikar Dronamraju wrote:
> * Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2021-04-02 11:07:54]:
>
> >
> > To remedy this, this patch proposes that the LLC be moved to the MC
> > level which is a group of cores in one half of the chip.
> >
> > SMT (SMT4) --> MC (Hemisphere)[LLC] --> DIE
> >
>
> I think marking Hemisphere as a LLC in a P10 scenario is a good idea.
>
> > While there is no cache being shared at this level, this is still the
> > level where some amount of cache-snooping takes place and it is
> > relatively faster to access the data from the caches of the cores
> > within this domain. With this change, we no longer see regressions on
> > P10 for applications which require single threaded performance.
>
> Peter, Valentin, Vincent, Mel, etal
>
> On architectures where we have multiple levels of cache access latencies
> within a DIE, (For example: one within the current LLC or SMT core and the
> other at MC or Hemisphere, and finally across hemispheres), do you have any
> suggestions on how we could handle the same in the core scheduler?
>
Minimally I think it would be worth detecting when there are multiple
LLCs per node and detecting that in generic code as a static branch. In
select_idle_cpu, consider taking two passes -- first on the LLC domain
and if no idle CPU is found then taking a second pass if the search depth
allows within the node with the LLC CPUs masked out. While there would be
a latency hit because cache is not shared, it would still be a CPU local
to memory that is idle. That would potentially be beneficial on Zen*
as well without having to introduce new domains in the topology hierarchy.
--
Mel Gorman
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/5] uapi: remove the unused HAVE_ARCH_STRUCT_FLOCK64 define
From: Arnd Bergmann @ 2021-04-12 9:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, linux-s390, Thomas Bogendoerfer, Parisc List,
Vasily Gorbik, linuxppc-dev, Catalin Marinas, Helge Deller,
the arch/x86 maintainers, Linux Kernel Mailing List,
David S. Miller, James E.J. Bottomley, Christian Borntraeger,
sparclinux, open list:BROADCOM NVRAM DRIVER, Will Deacon,
Heiko Carstens, Linux ARM
In-Reply-To: <20210412085545.2595431-2-hch@lst.de>
On Mon, Apr 12, 2021 at 10:55 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
The patch looks good, but I'd like to see a description for each one.
How about:
| The check was added when Stephen Rothwell created the file, but
| no architecture ever defined it.
Arnd
^ permalink raw reply
* [PATCH] powerpc: alignment: Remove unneeded variables
From: Wan Jiabing @ 2021-04-12 9:59 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Shuah Khan, Jordan Niethe, Michael Neuling, Wan Jiabing,
linuxppc-dev, linux-kselftest, linux-kernel
Cc: kael_w
Fix coccicheck warning:
./tools/testing/selftests/powerpc/alignment/alignment_handler.c:539:5-7:
Unneeded variable: "rc". Return "0" on line 562
./tools/testing/selftests/powerpc/alignment/alignment_handler.c:567:5-7:
Unneeded variable: "rc". Return "0" on line 580
./tools/testing/selftests/powerpc/alignment/alignment_handler.c:585:5-7:
Unneeded variable: "rc". Return "0" on line 594
./tools/testing/selftests/powerpc/alignment/alignment_handler.c:600:5-7:
Unneeded variable: "rc". Return "0" on line 611
./tools/testing/selftests/powerpc/alignment/alignment_handler.c:416:5-7:
Unneeded variable: "rc". Return "0" on line 470
./tools/testing/selftests/powerpc/alignment/alignment_handler.c:475:5-7:
Unneeded variable: "rc". Return "0" on line 485
./tools/testing/selftests/powerpc/alignment/alignment_handler.c:490:5-7:
Unneeded variable: "rc". Return "0" on line 506
./tools/testing/selftests/powerpc/alignment/alignment_handler.c:511:5-7:
Unneeded variable: "rc". Return "0" on line 534
./tools/testing/selftests/powerpc/alignment/alignment_handler.c:331:5-7:
Unneeded variable: "rc". Return "0" on line 344
./tools/testing/selftests/powerpc/alignment/alignment_handler.c:349:5-7:
Unneeded variable: "rc". Return "0" on line 360
./tools/testing/selftests/powerpc/alignment/alignment_handler.c:365:5-7:
Unneeded variable: "rc". Return "0" on line 392
./tools/testing/selftests/powerpc/alignment/alignment_handler.c:397:5-7:
Unneeded variable: "rc". Return "0" on line 411
Signed-off-by: Wan Jiabing <wanjiabing@vivo.com>
---
.../powerpc/alignment/alignment_handler.c | 48 +++++--------------
1 file changed, 12 insertions(+), 36 deletions(-)
diff --git a/tools/testing/selftests/powerpc/alignment/alignment_handler.c b/tools/testing/selftests/powerpc/alignment/alignment_handler.c
index c25cf7cd45e9..48bfb7b36d84 100644
--- a/tools/testing/selftests/powerpc/alignment/alignment_handler.c
+++ b/tools/testing/selftests/powerpc/alignment/alignment_handler.c
@@ -328,8 +328,6 @@ static bool can_open_cifile(void)
int test_alignment_handler_vsx_206(void)
{
- int rc = 0;
-
SKIP_IF(!can_open_cifile());
SKIP_IF(!have_hwcap(PPC_FEATURE_ARCH_2_06));
@@ -341,13 +339,11 @@ int test_alignment_handler_vsx_206(void)
STORE_VSX_XFORM_TEST(stxvd2x);
STORE_VSX_XFORM_TEST(stxvw4x);
STORE_VSX_XFORM_TEST(stxsdx);
- return rc;
+ return 0;
}
int test_alignment_handler_vsx_207(void)
{
- int rc = 0;
-
SKIP_IF(!can_open_cifile());
SKIP_IF(!have_hwcap2(PPC_FEATURE2_ARCH_2_07));
@@ -357,13 +353,11 @@ int test_alignment_handler_vsx_207(void)
LOAD_VSX_XFORM_TEST(lxsiwzx);
STORE_VSX_XFORM_TEST(stxsspx);
STORE_VSX_XFORM_TEST(stxsiwx);
- return rc;
+ return 0;
}
int test_alignment_handler_vsx_300(void)
{
- int rc = 0;
-
SKIP_IF(!can_open_cifile());
SKIP_IF(!have_hwcap2(PPC_FEATURE2_ARCH_3_00));
@@ -389,13 +383,11 @@ int test_alignment_handler_vsx_300(void)
STORE_VSX_XFORM_TEST(stxvx);
STORE_VSX_XFORM_TEST(stxvl);
STORE_VSX_XFORM_TEST(stxvll);
- return rc;
+ return 0;
}
int test_alignment_handler_vsx_prefix(void)
{
- int rc = 0;
-
SKIP_IF(!can_open_cifile());
SKIP_IF(!have_hwcap2(PPC_FEATURE2_ARCH_3_1));
@@ -408,13 +400,11 @@ int test_alignment_handler_vsx_prefix(void)
STORE_VSX_8LS_PREFIX_TEST(PSTXSSP, 0);
STORE_VSX_8LS_PREFIX_TEST(PSTXV0, 0);
STORE_VSX_8LS_PREFIX_TEST(PSTXV1, 1);
- return rc;
+ return 0;
}
int test_alignment_handler_integer(void)
{
- int rc = 0;
-
SKIP_IF(!can_open_cifile());
printf("Integer\n");
@@ -467,13 +457,11 @@ int test_alignment_handler_integer(void)
STORE_DFORM_TEST(stmw);
#endif
- return rc;
+ return 0;
}
int test_alignment_handler_integer_206(void)
{
- int rc = 0;
-
SKIP_IF(!can_open_cifile());
SKIP_IF(!have_hwcap(PPC_FEATURE_ARCH_2_06));
@@ -482,13 +470,11 @@ int test_alignment_handler_integer_206(void)
LOAD_XFORM_TEST(ldbrx);
STORE_XFORM_TEST(stdbrx);
- return rc;
+ return 0;
}
int test_alignment_handler_integer_prefix(void)
{
- int rc = 0;
-
SKIP_IF(!can_open_cifile());
SKIP_IF(!have_hwcap2(PPC_FEATURE2_ARCH_3_1));
@@ -503,13 +489,11 @@ int test_alignment_handler_integer_prefix(void)
STORE_MLS_PREFIX_TEST(PSTH);
STORE_MLS_PREFIX_TEST(PSTW);
STORE_8LS_PREFIX_TEST(PSTD);
- return rc;
+ return 0;
}
int test_alignment_handler_vmx(void)
{
- int rc = 0;
-
SKIP_IF(!can_open_cifile());
SKIP_IF(!have_hwcap(PPC_FEATURE_HAS_ALTIVEC));
@@ -531,13 +515,11 @@ int test_alignment_handler_vmx(void)
STORE_VMX_XFORM_TEST(stvehx);
STORE_VMX_XFORM_TEST(stvewx);
STORE_VMX_XFORM_TEST(stvxl);
- return rc;
+ return 0;
}
int test_alignment_handler_fp(void)
{
- int rc = 0;
-
SKIP_IF(!can_open_cifile());
printf("Floating point\n");
@@ -559,13 +541,11 @@ int test_alignment_handler_fp(void)
STORE_FLOAT_XFORM_TEST(stfsux);
STORE_FLOAT_XFORM_TEST(stfiwx);
- return rc;
+ return 0;
}
int test_alignment_handler_fp_205(void)
{
- int rc = 0;
-
SKIP_IF(!can_open_cifile());
SKIP_IF(!have_hwcap(PPC_FEATURE_ARCH_2_05));
@@ -577,13 +557,11 @@ int test_alignment_handler_fp_205(void)
STORE_FLOAT_DFORM_TEST(stfdp);
STORE_FLOAT_XFORM_TEST(stfdpx);
- return rc;
+ return 0;
}
int test_alignment_handler_fp_206(void)
{
- int rc = 0;
-
SKIP_IF(!can_open_cifile());
SKIP_IF(!have_hwcap(PPC_FEATURE_ARCH_2_06));
@@ -591,14 +569,12 @@ int test_alignment_handler_fp_206(void)
LOAD_FLOAT_XFORM_TEST(lfiwzx);
- return rc;
+ return 0;
}
int test_alignment_handler_fp_prefix(void)
{
- int rc = 0;
-
SKIP_IF(!can_open_cifile());
SKIP_IF(!have_hwcap2(PPC_FEATURE2_ARCH_3_1));
@@ -608,7 +584,7 @@ int test_alignment_handler_fp_prefix(void)
LOAD_FLOAT_MLS_PREFIX_TEST(PLFD);
STORE_FLOAT_MLS_PREFIX_TEST(PSTFS);
STORE_FLOAT_MLS_PREFIX_TEST(PSTFD);
- return rc;
+ return 0;
}
void usage(char *prog)
--
2.30.2
^ permalink raw reply related
* Re: consolidate the flock uapi definitions
From: Arnd Bergmann @ 2021-04-12 10:03 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, linux-s390, Thomas Bogendoerfer, Parisc List,
Vasily Gorbik, linuxppc-dev, Catalin Marinas, Helge Deller,
the arch/x86 maintainers, Linux Kernel Mailing List,
David S. Miller, James E.J. Bottomley, Christian Borntraeger,
sparclinux, open list:BROADCOM NVRAM DRIVER, Will Deacon,
Heiko Carstens, Linux ARM
In-Reply-To: <20210412085545.2595431-1-hch@lst.de>
On Mon, Apr 12, 2021 at 10:55 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Hi all,
>
> currently we deal with the slight differents in the various architecture
> variants of the flock and flock64 stuctures in a very cruft way. This
> series switches to just use small arch hooks and define the rest in
> asm-generic and linux/compat.h instead.
Nice cleanup. I can merge it through the asm-generic tree if you like,
though it's a little late just ahead of the merge window.
I would not want to change the compat_loff_t definition to compat_s64
to avoid the padding at this time, though that might be a useful cleanup
for a future cycle.
Arnd
^ permalink raw reply
* Re: [RFC/PATCH] powerpc/smp: Add SD_SHARE_PKG_RESOURCES flag to MC sched-domain
From: Valentin Schneider @ 2021-04-12 10:06 UTC (permalink / raw)
To: Mel Gorman, Srikar Dronamraju
Cc: Gautham R. Shenoy, Michael Neuling, Vaidyanathan Srinivasan,
Vincent Guittot, Rik van Riel, LKML, Nicholas Piggin, Parth Shah,
linuxppc-dev, Dietmar Eggemann
In-Reply-To: <20210412093722.GS3697@techsingularity.net>
On 12/04/21 10:37, Mel Gorman wrote:
> On Mon, Apr 12, 2021 at 11:54:36AM +0530, Srikar Dronamraju wrote:
>> * Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2021-04-02 11:07:54]:
>>
>> >
>> > To remedy this, this patch proposes that the LLC be moved to the MC
>> > level which is a group of cores in one half of the chip.
>> >
>> > SMT (SMT4) --> MC (Hemisphere)[LLC] --> DIE
>> >
>>
>> I think marking Hemisphere as a LLC in a P10 scenario is a good idea.
>>
>> > While there is no cache being shared at this level, this is still the
>> > level where some amount of cache-snooping takes place and it is
>> > relatively faster to access the data from the caches of the cores
>> > within this domain. With this change, we no longer see regressions on
>> > P10 for applications which require single threaded performance.
>>
>> Peter, Valentin, Vincent, Mel, etal
>>
>> On architectures where we have multiple levels of cache access latencies
>> within a DIE, (For example: one within the current LLC or SMT core and the
>> other at MC or Hemisphere, and finally across hemispheres), do you have any
>> suggestions on how we could handle the same in the core scheduler?
>>
>
> Minimally I think it would be worth detecting when there are multiple
> LLCs per node and detecting that in generic code as a static branch. In
> select_idle_cpu, consider taking two passes -- first on the LLC domain
> and if no idle CPU is found then taking a second pass if the search depth
> allows within the node with the LLC CPUs masked out.
I think that's actually a decent approach. Tying SD_SHARE_PKG_RESOURCES to
something other than pure cache topology in a generic manner is tough (as
it relies on murky, ill-defined hardware fabric properties).
Last I tried thinking about that, I stopped at having a core-to-core
latency matrix, building domains off of that, and having some knob
specifying the highest distance value below which we'd set
SD_SHARE_PKG_RESOURCES. There's a few things I 'hate' about that; for one
it makes cpus_share_cache() somewhat questionable.
> While there would be
> a latency hit because cache is not shared, it would still be a CPU local
> to memory that is idle. That would potentially be beneficial on Zen*
> as well without having to introduce new domains in the topology hierarchy.
>
> --
> Mel Gorman
> SUSE Labs
^ permalink raw reply
* RE: consolidate the flock uapi definitions
From: David Laight @ 2021-04-12 10:22 UTC (permalink / raw)
To: 'Arnd Bergmann', Christoph Hellwig
Cc: linux-arch, linux-s390, Thomas Bogendoerfer, Parisc List,
Vasily Gorbik, Catalin Marinas, Helge Deller,
the arch/x86 maintainers, Linux Kernel Mailing List,
open list:BROADCOM NVRAM DRIVER, James E.J. Bottomley,
Christian Borntraeger, Will Deacon, Heiko Carstens, sparclinux,
linuxppc-dev, David S. Miller, Linux ARM
In-Reply-To: <CAK8P3a38qgkjkh4+fDKp4TufL+2_W-quZBFK9pJFf7wXP=84xQ@mail.gmail.com>
From: Arnd Bergmann
> Sent: 12 April 2021 11:04
>
> On Mon, Apr 12, 2021 at 10:55 AM Christoph Hellwig <hch@lst.de> wrote:
> >
> > Hi all,
> >
> > currently we deal with the slight differents in the various architecture
> > variants of the flock and flock64 stuctures in a very cruft way. This
> > series switches to just use small arch hooks and define the rest in
> > asm-generic and linux/compat.h instead.
>
> Nice cleanup. I can merge it through the asm-generic tree if you like,
> though it's a little late just ahead of the merge window.
>
> I would not want to change the compat_loff_t definition to compat_s64
> to avoid the padding at this time, though that might be a useful cleanup
> for a future cycle.
Is x86 the only architecture that has 32bit and 64bit variants where
the 32bit variant aligns 64bit items on 32bit boundaries?
I've just checked MIPS and ARM, and I'm fairly sure sparc 64bit
aligns them.
Are there any others?
Might also be interesting to check whether compat_loff_t gets
used anywhere else - where the x64-64 compat code will get it
wrong.
ISTM that fixing compat_loff_t shouldn't have any fallout.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Don't use devm_regmap_init_mmio_clk
From: Shengjiu Wang @ 2021-04-12 10:37 UTC (permalink / raw)
To: Guenter Roeck
Cc: alsa-devel, Timur Tabi, Xiubo Li, Fabio Estevam, Shengjiu Wang,
Takashi Iwai, Liam Girdwood, Nicolin Chen, Mark Brown,
linuxppc-dev, linux-kernel
In-Reply-To: <20210411144157.GA80935@roeck-us.net>
On Sun, Apr 11, 2021 at 10:43 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Fri, Mar 19, 2021 at 04:06:43PM +0800, Shengjiu Wang wrote:
> > When there is power domain bind with bus clock,
> >
> > The call flow:
> > devm_regmap_init_mmio_clk
> > - clk_prepare()
> > - clk_pm_runtime_get()
> >
> > cause the power domain of clock always be enabled after
> > regmap_init(). which impact the power consumption.
> >
> > So use devm_regmap_init_mmio instead of
> > devm_regmap_init_mmio_clk, then explicitly enable clock when
> > using by pm_runtime_get(), if CONFIG_PM=n, then
> > fsl_sai_runtime_resume will be explicitly called.
> >
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> > Signed-off-by: Viorel Suman <viorel.suman@nxp.com>
>
> This patch results in a crash when running mcimx6ul-evk in qemu.
> Reverting it fixes the problem.
>
> Crash and bisect logs attached.
>
> Guenter
>
> ---
> [ 19.196778] 8<--- cut here ---
> [ 19.197011] Unhandled fault: external abort on non-linefetch (0x808) at 0xd1588000
> [ 19.197135] pgd = (ptrval)
> [ 19.197203] [d1588000] *pgd=824da811, *pte=0202c653, *ppte=0202c453
> [ 19.197764] Internal error: : 808 [#1] SMP ARM
> [ 19.197953] Modules linked in:
> [ 19.198108] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc6-next-20210409 #1
> [ 19.198234] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
> [ 19.198354] PC is at regmap_mmio_write32le+0x24/0x2c
> [ 19.198482] LR is at regmap_mmio_write32le+0x1c/0x2c
> [ 19.198544] pc : [<c0965d6c>] lr : [<c0965d64>] psr: 60000093
> [ 19.198611] sp : c20b5cf0 ip : 00000000 fp : c017a344
> [ 19.198669] r10: c217c1b0 r9 : c20b4000 r8 : c26fcc00
> [ 19.198729] r7 : 01000000 r6 : c26ff580 r5 : 00000000 r4 : 01000000
> [ 19.198801] r3 : d1588000 r2 : 01000000 r1 : d1588000 r0 : c26ff580
> [ 19.198896] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
> [ 19.198982] Control: 10c5387d Table: 826bc06a DAC: 00000051
> [ 19.199060] Register r0 information: slab kmalloc-64 start c26ff580 pointer offset 0 size 64
> [ 19.199421] Register r1 information: 0-page vmalloc region starting at 0xd1588000 allocated at __devm_ioremap+0x90/0xa4
> [ 19.199587] Register r2 information: non-paged memory
> [ 19.199667] Register r3 information: 0-page vmalloc region starting at 0xd1588000 allocated at __devm_ioremap+0x90/0xa4
> [ 19.199774] Register r4 information: non-paged memory
> [ 19.199832] Register r5 information: NULL pointer
> [ 19.199888] Register r6 information: slab kmalloc-64 start c26ff580 pointer offset 0 size 64
> [ 19.199998] Register r7 information: non-paged memory
> [ 19.200056] Register r8 information: slab kmalloc-1k start c26fcc00 pointer offset 0 size 1024
> [ 19.200167] Register r9 information: non-slab/vmalloc memory
> [ 19.200252] Register r10 information: slab kmalloc-1k start c217c000 pointer offset 432 size 1024
> [ 19.200367] Register r11 information: non-slab/vmalloc memory
> [ 19.200431] Register r12 information: NULL pointer
> [ 19.200495] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
> [ 19.200596] Stack: (0xc20b5cf0 to 0xc20b6000)
> [ 19.200755] 5ce0: c26ff580 00000000 01000000 c0965f40
> [ 19.200932] 5d00: c26fcc00 00000000 00000000 c095f3cc c20c0000 c26fcc00 00000000 01000000
> [ 19.201096] 5d20: c269b840 00000000 c20b4000 c217c1b0 c017a344 c0961130 00000080 c217c010
> [ 19.201259] 5d40: c26ff5c0 c0d21354 c217c010 c0946e24 00000000 c0946e24 c217c114 c094a894
> [ 19.201420] 5d60: c217c010 c0946e24 c2173810 c217c114 c2173914 c20b4000 c217c1b0 c094a930
> [ 19.201582] 5d80: c217c010 c0946e24 c2173810 c094a468 c20c0000 c20b4000 c094a6a0 60000013
> [ 19.201744] 5da0: 00000002 cbdc8024 c217c114 5bdc6b72 60000013 60000013 c217c114 00000004
> [ 19.201906] 5dc0: 00000002 cbdc8024 c20b4000 c269b880 00000000 c094a6b4 c269b840 c217c010
> [ 19.202067] 5de0: c217c000 c0d2176c 00000000 00000000 00000000 00000000 c2176340 c21d5c00
> [ 19.202228] 5e00: 00000000 6b6c636d 00000033 5bdc6b72 00000000 00000000 c217c010 c18d47fc
> [ 19.202389] 5e20: c1f70c20 00000000 c18d47fc 00000000 00000000 c093f540 c217c010 c1f70c1c
> [ 19.202551] 5e40: 00000000 c1f70c20 00000000 c093cdec c217c010 c18d47fc c18d47fc c20b4000
> [ 19.202712] 5e60: 00000000 c166e854 c20af880 c093d0fc c217c010 00000000 c18d47fc c093d418
> [ 19.202873] 5e80: 00000000 c18d47fc c217c010 c093d484 00000000 c18d47fc c093d420 c093aefc
> [ 19.203035] 5ea0: c26fe980 c20ae2b0 c214be94 5bdc6b72 c20ae2e4 c18d47fc c26fe980 00000000
> [ 19.203196] 5ec0: c187bcf8 c093c0b8 c14db3fc c1661678 c18f4c20 c18d47fc c1661678 c18f4c20
> [ 19.203357] 5ee0: c17093d0 c093e1e4 c20b4000 c1661678 c18f4c20 c01022b0 00000000 00000000
> [ 19.203533] 5f00: c20af8ec 00000000 c17e0b10 c0f39294 c17093d0 ffffffff c14a1cb8 c20b4000
> [ 19.203696] 5f20: c18f4c20 c17093d0 c15644e0 c18ff000 c166e854 000001c6 00000000 c01af994
> [ 19.203858] 5f40: 00000000 5bdc6b72 c168dca8 00000007 c166e874 c15644e0 c18ff000 c166e854
> [ 19.204019] 5f60: c20af880 c16010a0 00000006 00000006 00000000 c16003e8 c0f46080 000001c6
> [ 19.204180] 5f80: c17097d0 00000000 c0f3a784 00000000 00000000 00000000 00000000 00000000
> [ 19.204342] 5fa0: 00000000 c0f3a78c 00000000 c010013c 00000000 00000000 00000000 00000000
> [ 19.204503] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 19.204663] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [ 19.204828] [<c0965d6c>] (regmap_mmio_write32le) from [<c0965f40>] (regmap_mmio_write+0x3c/0x54)
> [ 19.204947] [<c0965f40>] (regmap_mmio_write) from [<c095f3cc>] (_regmap_write+0x4c/0x1f4)
> [ 19.205034] [<c095f3cc>] (_regmap_write) from [<c0961130>] (regmap_write+0x3c/0x60)
> [ 19.205114] [<c0961130>] (regmap_write) from [<c0d21354>] (fsl_sai_runtime_resume+0x9c/0x1ec)
> [ 19.205206] [<c0d21354>] (fsl_sai_runtime_resume) from [<c094a894>] (__rpm_callback+0xb4/0x130)
> [ 19.205297] [<c094a894>] (__rpm_callback) from [<c094a930>] (rpm_callback+0x20/0x80)
> [ 19.205379] [<c094a930>] (rpm_callback) from [<c094a468>] (rpm_resume+0x604/0x7ec)
> [ 19.205459] [<c094a468>] (rpm_resume) from [<c094a6b4>] (__pm_runtime_resume+0x64/0xa4)
> [ 19.205543] [<c094a6b4>] (__pm_runtime_resume) from [<c0d2176c>] (fsl_sai_probe+0x2c8/0x674)
> [ 19.205630] [<c0d2176c>] (fsl_sai_probe) from [<c093f540>] (platform_probe+0x58/0xb8)
> [ 19.205694] [<c093f540>] (platform_probe) from [<c093cdec>] (really_probe+0xec/0x398)
> [ 19.205765] [<c093cdec>] (really_probe) from [<c093d0fc>] (driver_probe_device+0x64/0xc0)
> [ 19.205854] [<c093d0fc>] (driver_probe_device) from [<c093d418>] (device_driver_attach+0x58/0x60)
> [ 19.205944] [<c093d418>] (device_driver_attach) from [<c093d484>] (__driver_attach+0x64/0xdc)
> [ 19.206028] [<c093d484>] (__driver_attach) from [<c093aefc>] (bus_for_each_dev+0x78/0xb8)
> [ 19.206113] [<c093aefc>] (bus_for_each_dev) from [<c093c0b8>] (bus_add_driver+0x150/0x1dc)
> [ 19.206200] [<c093c0b8>] (bus_add_driver) from [<c093e1e4>] (driver_register+0x74/0x108)
> [ 19.206285] [<c093e1e4>] (driver_register) from [<c01022b0>] (do_one_initcall+0x80/0x3a8)
> [ 19.206374] [<c01022b0>] (do_one_initcall) from [<c16010a0>] (kernel_init_freeable+0x158/0x1f4)
> [ 19.206466] [<c16010a0>] (kernel_init_freeable) from [<c0f3a78c>] (kernel_init+0x8/0x11c)
> [ 19.206556] [<c0f3a78c>] (kernel_init) from [<c010013c>] (ret_from_fork+0x14/0x38)
> [ 19.206653] Exception stack(0xc20b5fb0 to 0xc20b5ff8)
> [ 19.206749] 5fa0: 00000000 00000000 00000000 00000000
> [ 19.206916] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 19.207063] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [ 19.207290] Code: ee073f9a ebdeca40 e5963000 e0831005 (e5814000)
> [ 19.207813] ---[ end trace 4c72393d5e30d6c1 ]---
>
> ---
> # bad: [e99d8a8495175df8cb8b739f8cf9b0fc9d0cd3b5] Add linux-next specific files for 20210409
> # good: [e49d033bddf5b565044e2abe4241353959bc9120] Linux 5.12-rc6
> git bisect start 'HEAD' 'v5.12-rc6'
> # good: [24c5f79572740c1744a7ec2e9e21b541acab6de3] Merge remote-tracking branch 'crypto/master'
> git bisect good 24c5f79572740c1744a7ec2e9e21b541acab6de3
> # bad: [4b90473874c7b6af320b9815f82ac305fd8807f7] Merge remote-tracking branch 'ftrace/for-next'
> git bisect bad 4b90473874c7b6af320b9815f82ac305fd8807f7
> # good: [9cf3382276b26848891c7e072db0a774fadd10e4] Merge remote-tracking branch 'sound/for-next'
> git bisect good 9cf3382276b26848891c7e072db0a774fadd10e4
> # bad: [f8d16164c586548d7ccedc058ca9ae547e0cebbe] Merge remote-tracking branch 'mmc/next'
> git bisect bad f8d16164c586548d7ccedc058ca9ae547e0cebbe
> # bad: [c7c19ec098b862a688291f5a1101f7de6e4b0a6c] ASoC: Intel: kbl: Add MST route change to kbl machine drivers
> git bisect bad c7c19ec098b862a688291f5a1101f7de6e4b0a6c
> # good: [1db19c151819dea7a0dc4d888250d25abaf229ca] ASoC: soc-pcm: fixup dpcm_be_dai_startup() user count
> git bisect good 1db19c151819dea7a0dc4d888250d25abaf229ca
> # bad: [f89c0a87b4066fbb0dc6f8039b211bd79a9ab663] Merge tag 'ib-mfd-extcon-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into asoc-5.13
> git bisect bad f89c0a87b4066fbb0dc6f8039b211bd79a9ab663
> # good: [a2cc1568dc50020a807c94bd14a053dd54e9c35e] ASoC: tscs454: remove useless test on PLL disable
> git bisect good a2cc1568dc50020a807c94bd14a053dd54e9c35e
> # good: [cb11f79b4af65005584880eb408f9748c32661d0] ASoC: soc-pcm: indicate error message at soc_pcm_hw_params()
> git bisect good cb11f79b4af65005584880eb408f9748c32661d0
> # good: [60adbd8fbf486214f4ae1946e61df69c3867e20b] ASoC: don't indicate error message for snd_soc_[pcm_]component_xxx()
> git bisect good 60adbd8fbf486214f4ae1946e61df69c3867e20b
> # bad: [dfb81e3b5f47aa0ea5e4832eeb720bc22f07d0c1] ASoC: SOF: Intel: hda: drop display power on/off in D0i3 flows
> git bisect bad dfb81e3b5f47aa0ea5e4832eeb720bc22f07d0c1
> # good: [7e71b48f9e27e437ca523432ea285c2585a539dc] ASoC: amd: Add support for RT5682 codec in machine driver
> git bisect good 7e71b48f9e27e437ca523432ea285c2585a539dc
> # bad: [b951b51e2ca4d37dc9781e14d8a49d2f2b7e715b] ASoC: SOF: add a helper to get topology configured mclk
> git bisect bad b951b51e2ca4d37dc9781e14d8a49d2f2b7e715b
> # bad: [2277e7e36b4b8c27eb8d2fb33a20440bc800c2d7] ASoC: fsl_sai: Don't use devm_regmap_init_mmio_clk
> git bisect bad 2277e7e36b4b8c27eb8d2fb33a20440bc800c2d7
> # first bad commit: [2277e7e36b4b8c27eb8d2fb33a20440bc800c2d7] ASoC: fsl_sai: Don't use devm_regmap_init_mmio_clk
The SAI module is not supported in QEMU, so the access of the register
failed.
you can add bypass the access in QEMU, for example:
diff --git a/hw/arm/fsl-imx6ul.c b/hw/arm/fsl-imx6ul.c
index e0128d7316..62f7bd92a4 100644
--- a/hw/arm/fsl-imx6ul.c
+++ b/hw/arm/fsl-imx6ul.c
@@ -534,6 +534,10 @@ static void fsl_imx6ul_realize(DeviceState *dev,
Error **errp)
*/
create_unimplemented_device("sdma", FSL_IMX6UL_SDMA_ADDR, 0x4000);
+ create_unimplemented_device("sai1", 0x02028000, 0x4000);
+ create_unimplemented_device("sai2", 0x0202c000, 0x4000);
+ create_unimplemented_device("sai3", 0x02030000, 0x4000);
best regards
wang shengjiu
^ permalink raw reply related
* RE: [PATCH 5/5] compat: consolidate the compat_flock{,64} definition
From: David Laight @ 2021-04-12 10:53 UTC (permalink / raw)
To: 'Christoph Hellwig', 'Catalin Marinas',
'Will Deacon', 'Thomas Bogendoerfer',
'James E.J. Bottomley', 'Helge Deller',
'Michael Ellerman', 'Heiko Carstens',
'Vasily Gorbik', 'Christian Borntraeger',
'David S. Miller', 'x86@kernel.org',
'Arnd Bergmann'
Cc: 'linux-arch@vger.kernel.org',
'linux-s390@vger.kernel.org',
'linux-parisc@vger.kernel.org',
'linux-kernel@vger.kernel.org',
'linux-mips@vger.kernel.org',
'sparclinux@vger.kernel.org',
'linuxppc-dev@lists.ozlabs.org',
'linux-arm-kernel@lists.infradead.org'
In-Reply-To: <15be19af19174c7692dd795297884096@AcuMS.aculab.com>
From: David Laight
> Sent: 12 April 2021 10:37
...
> I'm guessing that compat_pid_t is 16 bits?
> So the native 32bit version has an unnamed 2 byte structure pad.
> The 'packed' removes this pad from the compat structure.
>
> AFAICT (apart from mips) the __ARCH_COMPAT_FLOCK_PAD is just
> adding an explicit pad for the implicit pad the compiler
> would generate because compat_pid_t is 16 bits.
I've just looked at the header.
compat_pid_t is 32 bits.
So Linux must have gained 32bit pids at some earlier time.
(Historically Unix pids were 16 bit - even on 32bit systems.)
Which makes the explicit pad in 'sparc' rather 'interesting'.
Actually the tail pad can just be removed from the compat
structures.
Just a comment that mips and sparc have extra fields
in the uapi header is enough.
The kernel never needs to read/write the pad.
userspace must provide the pad in case the kernel writes it.
oh - compat_loff_t is only used in a couple of other places.
neither care in any way about the alignment.
(Provided get_user() doesn't fault on a 8n+4 aligned address.)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [RFC/PATCH] powerpc/smp: Add SD_SHARE_PKG_RESOURCES flag to MC sched-domain
From: Mel Gorman @ 2021-04-12 10:48 UTC (permalink / raw)
To: Valentin Schneider
Cc: Gautham R. Shenoy, Michael Neuling, Vaidyanathan Srinivasan,
Vincent Guittot, Srikar Dronamraju, Rik van Riel, LKML,
Nicholas Piggin, Parth Shah, linuxppc-dev, Dietmar Eggemann
In-Reply-To: <871rbfom04.mognet@arm.com>
On Mon, Apr 12, 2021 at 11:06:19AM +0100, Valentin Schneider wrote:
> On 12/04/21 10:37, Mel Gorman wrote:
> > On Mon, Apr 12, 2021 at 11:54:36AM +0530, Srikar Dronamraju wrote:
> >> * Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2021-04-02 11:07:54]:
> >>
> >> >
> >> > To remedy this, this patch proposes that the LLC be moved to the MC
> >> > level which is a group of cores in one half of the chip.
> >> >
> >> > SMT (SMT4) --> MC (Hemisphere)[LLC] --> DIE
> >> >
> >>
> >> I think marking Hemisphere as a LLC in a P10 scenario is a good idea.
> >>
> >> > While there is no cache being shared at this level, this is still the
> >> > level where some amount of cache-snooping takes place and it is
> >> > relatively faster to access the data from the caches of the cores
> >> > within this domain. With this change, we no longer see regressions on
> >> > P10 for applications which require single threaded performance.
> >>
> >> Peter, Valentin, Vincent, Mel, etal
> >>
> >> On architectures where we have multiple levels of cache access latencies
> >> within a DIE, (For example: one within the current LLC or SMT core and the
> >> other at MC or Hemisphere, and finally across hemispheres), do you have any
> >> suggestions on how we could handle the same in the core scheduler?
> >>
> >
> > Minimally I think it would be worth detecting when there are multiple
> > LLCs per node and detecting that in generic code as a static branch. In
> > select_idle_cpu, consider taking two passes -- first on the LLC domain
> > and if no idle CPU is found then taking a second pass if the search depth
> > allows within the node with the LLC CPUs masked out.
>
> I think that's actually a decent approach. Tying SD_SHARE_PKG_RESOURCES to
> something other than pure cache topology in a generic manner is tough (as
> it relies on murky, ill-defined hardware fabric properties).
>
Agreed. The LLC->node scan idea has been on my TODO list to try for
a while.
> Last I tried thinking about that, I stopped at having a core-to-core
> latency matrix, building domains off of that, and having some knob
> specifying the highest distance value below which we'd set
> SD_SHARE_PKG_RESOURCES. There's a few things I 'hate' about that; for one
> it makes cpus_share_cache() somewhat questionable.
>
And I thought about something like this too but worried it might get
complex, particularly on chiplets where we do not necessarily have
hardware info on latency depending on how it's wired up. It also might
lead to excessive cpumask manipulation in a fast path if we have to
traverse multiple distances with search cost exceeding gains from latency
reduction. Hence -- keeping it simple with two level only, LLC then node
within the allowed search depth and see what that gets us. It might be
"good enough" in most cases and would be a basis for comparison against
complex approaches.
At minimum, I expect IBM can evaluate the POWER10 aspect and I can run
an evaluation on Zen generations.
--
Mel Gorman
SUSE Labs
^ permalink raw reply
* Re: [PATCH] powerpc: alignment: Remove unneeded variables
From: Christophe Leroy @ 2021-04-12 11:01 UTC (permalink / raw)
To: Wan Jiabing, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Shuah Khan, Jordan Niethe, Michael Neuling,
linuxppc-dev, linux-kselftest, linux-kernel
Cc: kael_w
In-Reply-To: <20210412095923.3916-1-wanjiabing@vivo.com>
Le 12/04/2021 à 11:59, Wan Jiabing a écrit :
> Fix coccicheck warning:
Can you mention in the commit subject that it is selftests and not the core part of powerpc which is
addressed here ?
>
> ./tools/testing/selftests/powerpc/alignment/alignment_handler.c:539:5-7:
> Unneeded variable: "rc". Return "0" on line 562
> ./tools/testing/selftests/powerpc/alignment/alignment_handler.c:567:5-7:
> Unneeded variable: "rc". Return "0" on line 580
> ./tools/testing/selftests/powerpc/alignment/alignment_handler.c:585:5-7:
> Unneeded variable: "rc". Return "0" on line 594
> ./tools/testing/selftests/powerpc/alignment/alignment_handler.c:600:5-7:
> Unneeded variable: "rc". Return "0" on line 611
> ./tools/testing/selftests/powerpc/alignment/alignment_handler.c:416:5-7:
> Unneeded variable: "rc". Return "0" on line 470
> ./tools/testing/selftests/powerpc/alignment/alignment_handler.c:475:5-7:
> Unneeded variable: "rc". Return "0" on line 485
> ./tools/testing/selftests/powerpc/alignment/alignment_handler.c:490:5-7:
> Unneeded variable: "rc". Return "0" on line 506
> ./tools/testing/selftests/powerpc/alignment/alignment_handler.c:511:5-7:
> Unneeded variable: "rc". Return "0" on line 534
> ./tools/testing/selftests/powerpc/alignment/alignment_handler.c:331:5-7:
> Unneeded variable: "rc". Return "0" on line 344
> ./tools/testing/selftests/powerpc/alignment/alignment_handler.c:349:5-7:
> Unneeded variable: "rc". Return "0" on line 360
> ./tools/testing/selftests/powerpc/alignment/alignment_handler.c:365:5-7:
> Unneeded variable: "rc". Return "0" on line 392
> ./tools/testing/selftests/powerpc/alignment/alignment_handler.c:397:5-7:
> Unneeded variable: "rc". Return "0" on line 411
>
> Signed-off-by: Wan Jiabing <wanjiabing@vivo.com>
> ---
> .../powerpc/alignment/alignment_handler.c | 48 +++++--------------
> 1 file changed, 12 insertions(+), 36 deletions(-)
>
> diff --git a/tools/testing/selftests/powerpc/alignment/alignment_handler.c b/tools/testing/selftests/powerpc/alignment/alignment_handler.c
> index c25cf7cd45e9..48bfb7b36d84 100644
> --- a/tools/testing/selftests/powerpc/alignment/alignment_handler.c
> +++ b/tools/testing/selftests/powerpc/alignment/alignment_handler.c
> @@ -328,8 +328,6 @@ static bool can_open_cifile(void)
>
> int test_alignment_handler_vsx_206(void)
> {
> - int rc = 0;
> -
> SKIP_IF(!can_open_cifile());
> SKIP_IF(!have_hwcap(PPC_FEATURE_ARCH_2_06));
>
> @@ -341,13 +339,11 @@ int test_alignment_handler_vsx_206(void)
> STORE_VSX_XFORM_TEST(stxvd2x);
> STORE_VSX_XFORM_TEST(stxvw4x);
> STORE_VSX_XFORM_TEST(stxsdx);
> - return rc;
> + return 0;
> }
>
> int test_alignment_handler_vsx_207(void)
> {
> - int rc = 0;
> -
> SKIP_IF(!can_open_cifile());
> SKIP_IF(!have_hwcap2(PPC_FEATURE2_ARCH_2_07));
>
> @@ -357,13 +353,11 @@ int test_alignment_handler_vsx_207(void)
> LOAD_VSX_XFORM_TEST(lxsiwzx);
> STORE_VSX_XFORM_TEST(stxsspx);
> STORE_VSX_XFORM_TEST(stxsiwx);
> - return rc;
> + return 0;
> }
>
> int test_alignment_handler_vsx_300(void)
> {
> - int rc = 0;
> -
> SKIP_IF(!can_open_cifile());
>
> SKIP_IF(!have_hwcap2(PPC_FEATURE2_ARCH_3_00));
> @@ -389,13 +383,11 @@ int test_alignment_handler_vsx_300(void)
> STORE_VSX_XFORM_TEST(stxvx);
> STORE_VSX_XFORM_TEST(stxvl);
> STORE_VSX_XFORM_TEST(stxvll);
> - return rc;
> + return 0;
> }
>
> int test_alignment_handler_vsx_prefix(void)
> {
> - int rc = 0;
> -
> SKIP_IF(!can_open_cifile());
> SKIP_IF(!have_hwcap2(PPC_FEATURE2_ARCH_3_1));
>
> @@ -408,13 +400,11 @@ int test_alignment_handler_vsx_prefix(void)
> STORE_VSX_8LS_PREFIX_TEST(PSTXSSP, 0);
> STORE_VSX_8LS_PREFIX_TEST(PSTXV0, 0);
> STORE_VSX_8LS_PREFIX_TEST(PSTXV1, 1);
> - return rc;
> + return 0;
> }
>
> int test_alignment_handler_integer(void)
> {
> - int rc = 0;
> -
> SKIP_IF(!can_open_cifile());
>
> printf("Integer\n");
> @@ -467,13 +457,11 @@ int test_alignment_handler_integer(void)
> STORE_DFORM_TEST(stmw);
> #endif
>
> - return rc;
> + return 0;
> }
>
> int test_alignment_handler_integer_206(void)
> {
> - int rc = 0;
> -
> SKIP_IF(!can_open_cifile());
> SKIP_IF(!have_hwcap(PPC_FEATURE_ARCH_2_06));
>
> @@ -482,13 +470,11 @@ int test_alignment_handler_integer_206(void)
> LOAD_XFORM_TEST(ldbrx);
> STORE_XFORM_TEST(stdbrx);
>
> - return rc;
> + return 0;
> }
>
> int test_alignment_handler_integer_prefix(void)
> {
> - int rc = 0;
> -
> SKIP_IF(!can_open_cifile());
> SKIP_IF(!have_hwcap2(PPC_FEATURE2_ARCH_3_1));
>
> @@ -503,13 +489,11 @@ int test_alignment_handler_integer_prefix(void)
> STORE_MLS_PREFIX_TEST(PSTH);
> STORE_MLS_PREFIX_TEST(PSTW);
> STORE_8LS_PREFIX_TEST(PSTD);
> - return rc;
> + return 0;
> }
>
> int test_alignment_handler_vmx(void)
> {
> - int rc = 0;
> -
> SKIP_IF(!can_open_cifile());
> SKIP_IF(!have_hwcap(PPC_FEATURE_HAS_ALTIVEC));
>
> @@ -531,13 +515,11 @@ int test_alignment_handler_vmx(void)
> STORE_VMX_XFORM_TEST(stvehx);
> STORE_VMX_XFORM_TEST(stvewx);
> STORE_VMX_XFORM_TEST(stvxl);
> - return rc;
> + return 0;
> }
>
> int test_alignment_handler_fp(void)
> {
> - int rc = 0;
> -
> SKIP_IF(!can_open_cifile());
>
> printf("Floating point\n");
> @@ -559,13 +541,11 @@ int test_alignment_handler_fp(void)
> STORE_FLOAT_XFORM_TEST(stfsux);
> STORE_FLOAT_XFORM_TEST(stfiwx);
>
> - return rc;
> + return 0;
> }
>
> int test_alignment_handler_fp_205(void)
> {
> - int rc = 0;
> -
> SKIP_IF(!can_open_cifile());
> SKIP_IF(!have_hwcap(PPC_FEATURE_ARCH_2_05));
>
> @@ -577,13 +557,11 @@ int test_alignment_handler_fp_205(void)
> STORE_FLOAT_DFORM_TEST(stfdp);
> STORE_FLOAT_XFORM_TEST(stfdpx);
>
> - return rc;
> + return 0;
> }
>
> int test_alignment_handler_fp_206(void)
> {
> - int rc = 0;
> -
> SKIP_IF(!can_open_cifile());
> SKIP_IF(!have_hwcap(PPC_FEATURE_ARCH_2_06));
>
> @@ -591,14 +569,12 @@ int test_alignment_handler_fp_206(void)
>
> LOAD_FLOAT_XFORM_TEST(lfiwzx);
>
> - return rc;
> + return 0;
> }
>
>
> int test_alignment_handler_fp_prefix(void)
> {
> - int rc = 0;
> -
> SKIP_IF(!can_open_cifile());
> SKIP_IF(!have_hwcap2(PPC_FEATURE2_ARCH_3_1));
>
> @@ -608,7 +584,7 @@ int test_alignment_handler_fp_prefix(void)
> LOAD_FLOAT_MLS_PREFIX_TEST(PLFD);
> STORE_FLOAT_MLS_PREFIX_TEST(PSTFS);
> STORE_FLOAT_MLS_PREFIX_TEST(PSTFD);
> - return rc;
> + return 0;
> }
>
> void usage(char *prog)
>
^ permalink raw reply
* Re: consolidate the flock uapi definitions
From: Arnd Bergmann @ 2021-04-12 11:07 UTC (permalink / raw)
To: David Laight
Cc: linux-arch, linux-s390, Thomas Bogendoerfer, Parisc List,
Vasily Gorbik, Catalin Marinas, Helge Deller,
the arch/x86 maintainers, Linux Kernel Mailing List,
David S. Miller, James E.J. Bottomley, Christian Borntraeger,
Will Deacon, Heiko Carstens, sparclinux,
open list:BROADCOM NVRAM DRIVER, linuxppc-dev, Christoph Hellwig,
Linux ARM
In-Reply-To: <16c471554aa5424fbe2f6a4fd60bd662@AcuMS.aculab.com>
On Mon, Apr 12, 2021 at 12:22 PM David Laight <David.Laight@aculab.com> wrote:
>
> From: Arnd Bergmann
> > Sent: 12 April 2021 11:04
> >
> > On Mon, Apr 12, 2021 at 10:55 AM Christoph Hellwig <hch@lst.de> wrote:
> > >
> > > Hi all,
> > >
> > > currently we deal with the slight differents in the various architecture
> > > variants of the flock and flock64 stuctures in a very cruft way. This
> > > series switches to just use small arch hooks and define the rest in
> > > asm-generic and linux/compat.h instead.
> >
> > Nice cleanup. I can merge it through the asm-generic tree if you like,
> > though it's a little late just ahead of the merge window.
> >
> > I would not want to change the compat_loff_t definition to compat_s64
> > to avoid the padding at this time, though that might be a useful cleanup
> > for a future cycle.
>
> Is x86 the only architecture that has 32bit and 64bit variants where
> the 32bit variant aligns 64bit items on 32bit boundaries?
Yes.
> ISTM that fixing compat_loff_t shouldn't have any fallout.
That is my assumption as well, but I still wouldn't take the
risk one week before the merge window.
Arnd
^ 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