* [PATCH v15 05/10] ima: Move arch_ima_add_kexec_buffer() to ima
From: Lakshmi Ramasubramanian @ 2021-01-15 17:30 UTC (permalink / raw)
To: zohar, bauerman, robh, takahiro.akashi, gregkh, will,
catalin.marinas, mpe
Cc: mark.rutland, bhsharma, tao.li, paulus, vincenzo.frascino,
frowand.list, sashal, masahiroy, jmorris, linux-arm-kernel, serge,
devicetree, pasha.tatashin, prsriva, hsinyi, allison,
christophe.leroy, mbrugger, balajib, dmitry.kasatkin,
linux-kernel, james.morse, linux-integrity, linuxppc-dev
In-Reply-To: <20210115173017.30617-1-nramas@linux.microsoft.com>
arch_ima_add_kexec_buffer() defined in "arch/powerpc/kexec/ima.c"
sets up the address and size of the IMA measurement list in
the architecture specific fields in kimage struct. This function does not
have architecture specific code, but is currently limited to powerpc.
Move arch_ima_add_kexec_buffer() to ima.
Co-developed-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
Signed-off-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Acked-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
---
arch/powerpc/include/asm/ima.h | 3 ---
arch/powerpc/kexec/ima.c | 17 -----------------
security/integrity/ima/ima_kexec.c | 21 +++++++++++++++++++++
3 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/include/asm/ima.h b/arch/powerpc/include/asm/ima.h
index ead488cf3981..51f64fd06c19 100644
--- a/arch/powerpc/include/asm/ima.h
+++ b/arch/powerpc/include/asm/ima.h
@@ -14,9 +14,6 @@ static inline void remove_ima_buffer(void *fdt, int chosen_node) {}
#endif
#ifdef CONFIG_IMA_KEXEC
-int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
- size_t size);
-
int setup_ima_buffer(const struct kimage *image, void *fdt, int chosen_node);
#else
static inline int setup_ima_buffer(const struct kimage *image, void *fdt,
diff --git a/arch/powerpc/kexec/ima.c b/arch/powerpc/kexec/ima.c
index 720e50e490b6..7378d59c0c1e 100644
--- a/arch/powerpc/kexec/ima.c
+++ b/arch/powerpc/kexec/ima.c
@@ -128,23 +128,6 @@ void remove_ima_buffer(void *fdt, int chosen_node)
}
#ifdef CONFIG_IMA_KEXEC
-/**
- * arch_ima_add_kexec_buffer - do arch-specific steps to add the IMA buffer
- *
- * Architectures should use this function to pass on the IMA buffer
- * information to the next kernel.
- *
- * Return: 0 on success, negative errno on error.
- */
-int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
- size_t size)
-{
- image->arch.ima_buffer_addr = load_addr;
- image->arch.ima_buffer_size = size;
-
- return 0;
-}
-
static int write_number(void *p, u64 value, int cells)
{
if (cells == 1) {
diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
index 121de3e04af2..95513c97ce8f 100644
--- a/security/integrity/ima/ima_kexec.c
+++ b/security/integrity/ima/ima_kexec.c
@@ -71,6 +71,27 @@ static int ima_dump_measurement_list(unsigned long *buffer_size, void **buffer,
return ret;
}
+/**
+ * arch_ima_add_kexec_buffer - do arch-specific steps to add the IMA buffer
+ *
+ * @image: kimage struct to set IMA buffer data
+ * @load_addr: Starting address where IMA buffer is loaded at
+ * @size: Number of bytes in the IMA buffer
+ *
+ * Architectures should use this function to pass on the IMA buffer
+ * information to the next kernel.
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+static int arch_ima_add_kexec_buffer(struct kimage *image,
+ unsigned long load_addr, size_t size)
+{
+ image->arch.ima_buffer_addr = load_addr;
+ image->arch.ima_buffer_size = size;
+
+ return 0;
+}
+
/*
* Called during kexec_file_load so that IMA can add a segment to the kexec
* image for the measurement list for the next kernel.
--
2.30.0
^ permalink raw reply related
* [RESEND v2 0/7] Rid W=1 warnings in Ethernet
From: Lee Jones @ 2021-01-15 20:08 UTC (permalink / raw)
To: lee.jones
Cc: Paul Durrant, Kurt Kanzenbach, Alexei Starovoitov,
Gustavo A. R. Silva, Peter Cammaert, Paul Mackerras,
Sukadev Bhattiprolu, Wei Liu, Daniel Borkmann, John Fastabend,
Santiago Leon, Jakub Kicinski, Grygorii Strashko, Thomas Falcon,
Jesper Dangaard Brouer, Jens Osterkamp, Rusty Russell,
Daris A Nevil, Lijun Pan, xen-devel, Ivan Khoronzhuk,
Nicolas Pitre, Geoff Levand, netdev, linux-kernel, Erik Stahlman,
John Allen, Utz Bacher, Dany Madden, bpf, linuxppc-dev,
David S. Miller, Russell King
Resending the stragglers again.
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
No changes since v2, just a rebase onto net-next.
v2:
- Squashed IBM patches
- Fixed real issue in SMSC
- Added Andrew's Reviewed-by tags on remainder
Lee Jones (7):
net: ethernet: smsc: smc91x: Fix function name in kernel-doc header
net: xen-netback: xenbus: Demote nonconformant kernel-doc headers
net: ethernet: ti: am65-cpsw-qos: Demote non-conformant function
header
net: ethernet: ti: am65-cpts: Document am65_cpts_rx_enable()'s 'en'
parameter
net: ethernet: ibm: ibmvnic: Fix some kernel-doc misdemeanours
net: ethernet: toshiba: ps3_gelic_net: Fix some kernel-doc
misdemeanours
net: ethernet: toshiba: spider_net: Document a whole bunch of function
parameters
drivers/net/ethernet/ibm/ibmvnic.c | 27 ++++++++++----------
drivers/net/ethernet/smsc/smc91x.c | 2 +-
drivers/net/ethernet/ti/am65-cpsw-qos.c | 2 +-
drivers/net/ethernet/ti/am65-cpts.c | 2 +-
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 8 +++---
drivers/net/ethernet/toshiba/spider_net.c | 18 ++++++++-----
drivers/net/xen-netback/xenbus.c | 4 +--
drivers/net/xen-netfront.c | 6 ++---
8 files changed, 37 insertions(+), 32 deletions(-)
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: bpf@vger.kernel.org
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Dany Madden <drt@linux.ibm.com>
Cc: Daris A Nevil <dnevil@snmc.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Erik Stahlman <erik@vt.edu>
Cc: Geoff Levand <geoff@infradead.org>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Ishizaki Kou <kou.ishizaki@toshiba.co.jp>
Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
Cc: Jesper Dangaard Brouer <hawk@kernel.org>
Cc: John Allen <jallen@linux.vnet.ibm.com>
Cc: John Fastabend <john.fastabend@gmail.com>
Cc: Kurt Kanzenbach <kurt@linutronix.de>
Cc: Lijun Pan <ljp@linux.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: netdev@vger.kernel.org
Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: Paul Durrant <paul@xen.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Cammaert <pc@denkart.be>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Santiago Leon <santi_leon@yahoo.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Cc: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Cc: Utz Bacher <utz.bacher@de.ibm.com>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: xen-devel@lists.xenproject.org
--
2.25.1
^ permalink raw reply
* [PATCH 5/7] net: ethernet: ibm: ibmvnic: Fix some kernel-doc misdemeanours
From: Lee Jones @ 2021-01-15 20:09 UTC (permalink / raw)
To: lee.jones
Cc: Thomas Falcon, John Allen, linux-kernel, Santiago Leon,
Jakub Kicinski, netdev, Lijun Pan, Dany Madden, Paul Mackerras,
Sukadev Bhattiprolu, linuxppc-dev, David S. Miller
In-Reply-To: <20210115200905.3470941-1-lee.jones@linaro.org>
Fixes the following W=1 kernel build warning(s):
from drivers/net/ethernet/ibm/ibmvnic.c:35:
inlined from ‘handle_vpd_rsp’ at drivers/net/ethernet/ibm/ibmvnic.c:4124:3:
drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Function parameter or member 'hdr_field' not described in 'build_hdr_data'
drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Function parameter or member 'skb' not described in 'build_hdr_data'
drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Function parameter or member 'hdr_len' not described in 'build_hdr_data'
drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Function parameter or member 'hdr_data' not described in 'build_hdr_data'
drivers/net/ethernet/ibm/ibmvnic.c:1423: warning: Function parameter or member 'hdr_field' not described in 'create_hdr_descs'
drivers/net/ethernet/ibm/ibmvnic.c:1423: warning: Function parameter or member 'hdr_data' not described in 'create_hdr_descs'
drivers/net/ethernet/ibm/ibmvnic.c:1423: warning: Function parameter or member 'len' not described in 'create_hdr_descs'
drivers/net/ethernet/ibm/ibmvnic.c:1423: warning: Function parameter or member 'hdr_len' not described in 'create_hdr_descs'
drivers/net/ethernet/ibm/ibmvnic.c:1423: warning: Function parameter or member 'scrq_arr' not described in 'create_hdr_descs'
drivers/net/ethernet/ibm/ibmvnic.c:1474: warning: Function parameter or member 'txbuff' not described in 'build_hdr_descs_arr'
drivers/net/ethernet/ibm/ibmvnic.c:1474: warning: Function parameter or member 'num_entries' not described in 'build_hdr_descs_arr'
drivers/net/ethernet/ibm/ibmvnic.c:1474: warning: Function parameter or member 'hdr_field' not described in 'build_hdr_descs_arr'
drivers/net/ethernet/ibm/ibmvnic.c:1832: warning: Function parameter or member 'adapter' not described in 'do_change_param_reset'
drivers/net/ethernet/ibm/ibmvnic.c:1832: warning: Function parameter or member 'rwi' not described in 'do_change_param_reset'
drivers/net/ethernet/ibm/ibmvnic.c:1832: warning: Function parameter or member 'reset_state' not described in 'do_change_param_reset'
drivers/net/ethernet/ibm/ibmvnic.c:1911: warning: Function parameter or member 'adapter' not described in 'do_reset'
drivers/net/ethernet/ibm/ibmvnic.c:1911: warning: Function parameter or member 'rwi' not described in 'do_reset'
drivers/net/ethernet/ibm/ibmvnic.c:1911: warning: Function parameter or member 'reset_state' not described in 'do_reset'
Cc: Dany Madden <drt@linux.ibm.com>
Cc: Lijun Pan <ljp@linux.ibm.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Santiago Leon <santi_leon@yahoo.com>
Cc: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Cc: John Allen <jallen@linux.vnet.ibm.com>
Cc: netdev@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/net/ethernet/ibm/ibmvnic.c | 27 +++++++++++++--------------
drivers/net/xen-netfront.c | 6 +++---
2 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index aed985e08e8ad..4c4252e68de5a 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1384,10 +1384,10 @@ static int ibmvnic_close(struct net_device *netdev)
/**
* build_hdr_data - creates L2/L3/L4 header data buffer
- * @hdr_field - bitfield determining needed headers
- * @skb - socket buffer
- * @hdr_len - array of header lengths
- * @tot_len - total length of data
+ * @hdr_field: bitfield determining needed headers
+ * @skb: socket buffer
+ * @hdr_len: array of header lengths
+ * @hdr_data: buffer to write the header to
*
* Reads hdr_field to determine which headers are needed by firmware.
* Builds a buffer containing these headers. Saves individual header
@@ -1444,11 +1444,11 @@ static int build_hdr_data(u8 hdr_field, struct sk_buff *skb,
/**
* create_hdr_descs - create header and header extension descriptors
- * @hdr_field - bitfield determining needed headers
- * @data - buffer containing header data
- * @len - length of data buffer
- * @hdr_len - array of individual header lengths
- * @scrq_arr - descriptor array
+ * @hdr_field: bitfield determining needed headers
+ * @hdr_data: buffer containing header data
+ * @len: length of data buffer
+ * @hdr_len: array of individual header lengths
+ * @scrq_arr: descriptor array
*
* Creates header and, if needed, header extension descriptors and
* places them in a descriptor array, scrq_arr
@@ -1496,10 +1496,9 @@ static int create_hdr_descs(u8 hdr_field, u8 *hdr_data, int len, int *hdr_len,
/**
* build_hdr_descs_arr - build a header descriptor array
- * @skb - socket buffer
- * @num_entries - number of descriptors to be sent
- * @subcrq - first TX descriptor
- * @hdr_field - bit field determining which headers will be sent
+ * @txbuff: tx buffer
+ * @num_entries: number of descriptors to be sent
+ * @hdr_field: bit field determining which headers will be sent
*
* This function will build a TX descriptor array with applicable
* L2/L3/L4 packet header descriptors to be sent by send_subcrq_indirect.
@@ -1925,7 +1924,7 @@ static int ibmvnic_set_mac(struct net_device *netdev, void *p)
return rc;
}
-/**
+/*
* do_reset returns zero if we are able to keep processing reset events, or
* non-zero if we hit a fatal error and must halt.
*/
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index b01848ef46493..811ddc8a94eea 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1582,7 +1582,7 @@ static struct net_device *xennet_create_dev(struct xenbus_device *dev)
return ERR_PTR(err);
}
-/**
+/*
* Entry point to this code when a new device is created. Allocate the basic
* structures and the ring buffers for communication with the backend, and
* inform the backend of the appropriate details for those.
@@ -1659,7 +1659,7 @@ static void xennet_disconnect_backend(struct netfront_info *info)
}
}
-/**
+/*
* We are reconnecting to the backend, due to a suspend/resume, or a backend
* driver restart. We tear down our netif structure and recreate it, but
* leave the device-layer structures intact so that this is transparent to the
@@ -2305,7 +2305,7 @@ static int xennet_connect(struct net_device *dev)
return 0;
}
-/**
+/*
* Callback received when the backend's state changes.
*/
static void netback_changed(struct xenbus_device *dev,
--
2.25.1
^ permalink raw reply related
* [PATCH 6/7] net: ethernet: toshiba: ps3_gelic_net: Fix some kernel-doc misdemeanours
From: Lee Jones @ 2021-01-15 20:09 UTC (permalink / raw)
To: lee.jones
Cc: Andrew Lunn, Geoff Levand, linux-kernel, Jens Osterkamp, netdev,
Paul Mackerras, Utz Bacher, Jakub Kicinski, linuxppc-dev,
David S. Miller
In-Reply-To: <20210115200905.3470941-1-lee.jones@linaro.org>
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/toshiba/ps3_gelic_net.c:1107: warning: Function parameter or member 'irq' not described in 'gelic_card_interrupt'
drivers/net/ethernet/toshiba/ps3_gelic_net.c:1107: warning: Function parameter or member 'ptr' not described in 'gelic_card_interrupt'
drivers/net/ethernet/toshiba/ps3_gelic_net.c:1407: warning: Function parameter or member 'txqueue' not described in 'gelic_net_tx_timeout'
drivers/net/ethernet/toshiba/ps3_gelic_net.c:1439: warning: Function parameter or member 'napi' not described in 'gelic_ether_setup_netdev_ops'
drivers/net/ethernet/toshiba/ps3_gelic_net.c:1639: warning: Function parameter or member 'dev' not described in 'ps3_gelic_driver_probe'
drivers/net/ethernet/toshiba/ps3_gelic_net.c:1795: warning: Function parameter or member 'dev' not described in 'ps3_gelic_driver_remove'
Cc: Geoff Levand <geoff@infradead.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Utz Bacher <utz.bacher@de.ibm.com>
Cc: Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
Cc: netdev@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
index 3d1fc8d2ca667..55e652624bd76 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
@@ -1100,7 +1100,7 @@ static int gelic_net_poll(struct napi_struct *napi, int budget)
return packets_done;
}
-/**
+/*
* gelic_card_interrupt - event handler for gelic_net
*/
static irqreturn_t gelic_card_interrupt(int irq, void *ptr)
@@ -1400,6 +1400,7 @@ static void gelic_net_tx_timeout_task(struct work_struct *work)
/**
* gelic_net_tx_timeout - called when the tx timeout watchdog kicks in.
* @netdev: interface device structure
+ * @txqueue: unused
*
* called, if tx hangs. Schedules a task that resets the interface
*/
@@ -1431,6 +1432,7 @@ static const struct net_device_ops gelic_netdevice_ops = {
/**
* gelic_ether_setup_netdev_ops - initialization of net_device operations
* @netdev: net_device structure
+ * @napi: napi structure
*
* fills out function pointers in the net_device structure
*/
@@ -1632,7 +1634,7 @@ static void gelic_card_get_vlan_info(struct gelic_card *card)
dev_info(ctodev(card), "internal vlan %s\n",
card->vlan_required? "enabled" : "disabled");
}
-/**
+/*
* ps3_gelic_driver_probe - add a device to the control of this driver
*/
static int ps3_gelic_driver_probe(struct ps3_system_bus_device *dev)
@@ -1787,7 +1789,7 @@ static int ps3_gelic_driver_probe(struct ps3_system_bus_device *dev)
return result;
}
-/**
+/*
* ps3_gelic_driver_remove - remove a device from the control of this driver
*/
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v6 07/39] powerpc: bad_page_fault get registers from regs
From: Nicholas Piggin @ 2021-01-16 0:42 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <9120125b-6dce-4e89-7113-dfdcea43e191@csgroup.eu>
Excerpts from Christophe Leroy's message of January 16, 2021 3:09 am:
>
>
> Le 15/01/2021 à 17:49, Nicholas Piggin a écrit :
>> Similar to the previous patch this makes interrupt handler function
>> types more regular so they can be wrapped with the next patch.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/include/asm/bug.h | 5 +++--
>> arch/powerpc/kernel/entry_32.S | 3 +--
>> arch/powerpc/kernel/exceptions-64e.S | 3 +--
>> arch/powerpc/kernel/exceptions-64s.S | 4 +---
>> arch/powerpc/kernel/traps.c | 2 +-
>> arch/powerpc/mm/book3s64/hash_utils.c | 4 ++--
>> arch/powerpc/mm/book3s64/slb.c | 2 +-
>> arch/powerpc/mm/fault.c | 13 ++++++++++---
>> arch/powerpc/platforms/8xx/machine_check.c | 2 +-
>> 9 files changed, 21 insertions(+), 17 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
>> index f7827e993196..8f09ddae9305 100644
>> --- a/arch/powerpc/include/asm/bug.h
>> +++ b/arch/powerpc/include/asm/bug.h
>> @@ -112,8 +112,9 @@
>>
>> struct pt_regs;
>> long do_page_fault(struct pt_regs *);
>> -extern void bad_page_fault(struct pt_regs *, unsigned long, int);
>> -void __bad_page_fault(struct pt_regs *regs, unsigned long address, int sig);
>> +void bad_page_fault(struct pt_regs *, int);
>> +void __bad_page_fault(struct pt_regs *regs, int sig);
>> +void do_bad_page_fault_segv(struct pt_regs *regs);
>
> What is that do_bad_page_fault_segv() ? Shouldn't it be in a separate patch ?
Hmm, yeah probably. It will be an interrupt handler (that doesn't
require SIGSEGV argument).
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v6 17/39] powerpc/fsl_booke/32: CacheLockingException remove args
From: Nicholas Piggin @ 2021-01-16 0:43 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <1bd92a69-71ab-cc7f-fec5-e2a67830c81b@csgroup.eu>
Excerpts from Christophe Leroy's message of January 16, 2021 3:14 am:
>
>
> Le 15/01/2021 à 17:49, Nicholas Piggin a écrit :
>> Like other interrupt handler conversions, switch to getting registers
>> from the pt_regs argument.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/kernel/head_fsl_booke.S | 6 +++---
>> arch/powerpc/kernel/traps.c | 5 +++--
>> 2 files changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
>> index fdd4d274c245..0d4d9a6fcca1 100644
>> --- a/arch/powerpc/kernel/head_fsl_booke.S
>> +++ b/arch/powerpc/kernel/head_fsl_booke.S
>> @@ -364,12 +364,12 @@ interrupt_base:
>> /* Data Storage Interrupt */
>> START_EXCEPTION(DataStorage)
>> NORMAL_EXCEPTION_PROLOG(DATA_STORAGE)
>> - mfspr r5,SPRN_ESR /* Grab the ESR, save it, pass arg3 */
>> + mfspr r5,SPRN_ESR /* Grab the ESR, save it3 */
>> stw r5,_ESR(r11)
>> - mfspr r4,SPRN_DEAR /* Grab the DEAR, save it, pass arg2 */
>> + mfspr r4,SPRN_DEAR /* Grab the DEAR, save it */
>> + stw r4, _DEAR(r11)
>> andis. r10,r5,(ESR_ILK|ESR_DLK)@h
>> bne 1f
>> - stw r4, _DEAR(r11)
>> EXC_XFER_LITE(0x0300, handle_page_fault)
>> 1:
>> addi r3,r1,STACK_FRAME_OVERHEAD
>
> Why isn't the above done in patch 5 ?
I don't think it's required there, is it?
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v6 17/39] powerpc/fsl_booke/32: CacheLockingException remove args
From: Christophe Leroy @ 2021-01-16 7:38 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <1610757796.o87kxvdq5e.astroid@bobo.none>
Le 16/01/2021 à 01:43, Nicholas Piggin a écrit :
> Excerpts from Christophe Leroy's message of January 16, 2021 3:14 am:
>>
>>
>> Le 15/01/2021 à 17:49, Nicholas Piggin a écrit :
>>> Like other interrupt handler conversions, switch to getting registers
>>> from the pt_regs argument.
>>>
>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>> ---
>>> arch/powerpc/kernel/head_fsl_booke.S | 6 +++---
>>> arch/powerpc/kernel/traps.c | 5 +++--
>>> 2 files changed, 6 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
>>> index fdd4d274c245..0d4d9a6fcca1 100644
>>> --- a/arch/powerpc/kernel/head_fsl_booke.S
>>> +++ b/arch/powerpc/kernel/head_fsl_booke.S
>>> @@ -364,12 +364,12 @@ interrupt_base:
>>> /* Data Storage Interrupt */
>>> START_EXCEPTION(DataStorage)
>>> NORMAL_EXCEPTION_PROLOG(DATA_STORAGE)
>>> - mfspr r5,SPRN_ESR /* Grab the ESR, save it, pass arg3 */
>>> + mfspr r5,SPRN_ESR /* Grab the ESR, save it3 */
>>> stw r5,_ESR(r11)
>>> - mfspr r4,SPRN_DEAR /* Grab the DEAR, save it, pass arg2 */
>>> + mfspr r4,SPRN_DEAR /* Grab the DEAR, save it */
>>> + stw r4, _DEAR(r11)
>>> andis. r10,r5,(ESR_ILK|ESR_DLK)@h
>>> bne 1f
>>> - stw r4, _DEAR(r11)
>>> EXC_XFER_LITE(0x0300, handle_page_fault)
>>> 1:
>>> addi r3,r1,STACK_FRAME_OVERHEAD
>>
>> Why isn't the above done in patch 5 ?
>
> I don't think it's required there, is it?
Ah yes, moving the 'stw' is needed only here.
But the comments changes belong to patch 5, you have done exactly similar changes there in
kernel/head_40x.S
By the way, I think patch 17 could immediately follow patch 5 and patch 18 could follow patch 6.
>
> Thanks,
> Nick
>
^ permalink raw reply
* Re: [PATCH v6 17/39] powerpc/fsl_booke/32: CacheLockingException remove args
From: Nicholas Piggin @ 2021-01-16 10:34 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <0d953b03-b908-0fd6-61bf-d0e461312874@csgroup.eu>
Excerpts from Christophe Leroy's message of January 16, 2021 5:38 pm:
>
>
> Le 16/01/2021 à 01:43, Nicholas Piggin a écrit :
>> Excerpts from Christophe Leroy's message of January 16, 2021 3:14 am:
>>>
>>>
>>> Le 15/01/2021 à 17:49, Nicholas Piggin a écrit :
>>>> Like other interrupt handler conversions, switch to getting registers
>>>> from the pt_regs argument.
>>>>
>>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>>> ---
>>>> arch/powerpc/kernel/head_fsl_booke.S | 6 +++---
>>>> arch/powerpc/kernel/traps.c | 5 +++--
>>>> 2 files changed, 6 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
>>>> index fdd4d274c245..0d4d9a6fcca1 100644
>>>> --- a/arch/powerpc/kernel/head_fsl_booke.S
>>>> +++ b/arch/powerpc/kernel/head_fsl_booke.S
>>>> @@ -364,12 +364,12 @@ interrupt_base:
>>>> /* Data Storage Interrupt */
>>>> START_EXCEPTION(DataStorage)
>>>> NORMAL_EXCEPTION_PROLOG(DATA_STORAGE)
>>>> - mfspr r5,SPRN_ESR /* Grab the ESR, save it, pass arg3 */
>>>> + mfspr r5,SPRN_ESR /* Grab the ESR, save it3 */
>>>> stw r5,_ESR(r11)
>>>> - mfspr r4,SPRN_DEAR /* Grab the DEAR, save it, pass arg2 */
>>>> + mfspr r4,SPRN_DEAR /* Grab the DEAR, save it */
>>>> + stw r4, _DEAR(r11)
>>>> andis. r10,r5,(ESR_ILK|ESR_DLK)@h
>>>> bne 1f
>>>> - stw r4, _DEAR(r11)
>>>> EXC_XFER_LITE(0x0300, handle_page_fault)
>>>> 1:
>>>> addi r3,r1,STACK_FRAME_OVERHEAD
>>>
>>> Why isn't the above done in patch 5 ?
>>
>> I don't think it's required there, is it?
>
> Ah yes, moving the 'stw' is needed only here.
>
> But the comments changes belong to patch 5, you have done exactly similar changes there in
> kernel/head_40x.S
>
> By the way, I think patch 17 could immediately follow patch 5 and patch 18 could follow patch 6.
I can probably do all these. I'll wait a couple of days and check if
Michael will merge the series before sending an update for small
changes.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v6 01/39] KVM: PPC: Book3S HV: Context tracking exit guest context before enabling irqs
From: Nicholas Piggin @ 2021-01-16 10:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kvm-ppc
In-Reply-To: <20210115165012.1260253-2-npiggin@gmail.com>
Excerpts from Nicholas Piggin's message of January 16, 2021 2:49 am:
> Interrupts that occur in kernel mode expect that context tracking
> is set to kernel. Enabling local irqs before context tracking
> switches from guest to host means interrupts can come in and trigger
> warnings about wrong context, and possibly worse.
I think this is not actually a fix per se with context as it is today
because the interrupt handlers will save and update the state. It only
starts throwing warnings when moving to the more precise tracking
where kernel interrupts always expect context to be in kernel mode.
The patch stands on its own just fine, but I'll reword slightly and
move it in the series to where it's needed.
Thanks,
Nick
>
> Cc: kvm-ppc@vger.kernel.org
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/kvm/book3s_hv.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 6f612d240392..d348e77cee20 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -3407,8 +3407,9 @@ static noinline void kvmppc_run_core(struct kvmppc_vcore *vc)
>
> kvmppc_set_host_core(pcpu);
>
> + guest_exit_irqoff();
> +
> local_irq_enable();
> - guest_exit();
>
> /* Let secondaries go back to the offline loop */
> for (i = 0; i < controlled_threads; ++i) {
> @@ -4217,8 +4218,9 @@ int kvmhv_run_single_vcpu(struct kvm_vcpu *vcpu, u64 time_limit,
>
> kvmppc_set_host_core(pcpu);
>
> + guest_exit_irqoff();
> +
> local_irq_enable();
> - guest_exit();
>
> cpumask_clear_cpu(pcpu, &kvm->arch.cpu_in_guest);
>
> --
> 2.23.0
>
>
^ permalink raw reply
* Re: [PATCH v2] powerpc: Handle .text.{hot, unlikely}.* in linker script
From: Segher Boessenkool @ 2021-01-16 18:44 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Nick Desaulniers, linux-kernel, stable, clang-built-linux,
Paul Mackerras, linuxppc-dev
In-Reply-To: <20210104205952.1399409-1-natechancellor@gmail.com>
Hi!
Very late of course, and the patch is fine, but:
On Mon, Jan 04, 2021 at 01:59:53PM -0700, Nathan Chancellor wrote:
> Commit eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input
> sections") added ".text.unlikely.*" and ".text.hot.*" due to an LLVM
> change [1].
>
> After another LLVM change [2], these sections are seen in some PowerPC
> builds, where there is a orphan section warning then build failure:
>
> $ make -skj"$(nproc)" \
> ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- LLVM=1 O=out \
> distclean powernv_defconfig zImage.epapr
> ld.lld: warning: kernel/built-in.a(panic.o):(.text.unlikely.) is being placed in '.text.unlikely.'
Is the section really called ".text.unlikely.", i.e. the name ending in
a dot? How very unusual, is there some bug elsewhere?
Segher
^ permalink raw reply
* Re: [PATCH v2] powerpc: Handle .text.{hot,unlikely}.* in linker script
From: Nathan Chancellor @ 2021-01-16 18:52 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Nick Desaulniers, linux-kernel, stable, clang-built-linux,
Paul Mackerras, linuxppc-dev
In-Reply-To: <20210116184438.GE30983@gate.crashing.org>
On Sat, Jan 16, 2021 at 12:44:38PM -0600, Segher Boessenkool wrote:
> Hi!
>
> Very late of course, and the patch is fine, but:
>
> On Mon, Jan 04, 2021 at 01:59:53PM -0700, Nathan Chancellor wrote:
> > Commit eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input
> > sections") added ".text.unlikely.*" and ".text.hot.*" due to an LLVM
> > change [1].
> >
> > After another LLVM change [2], these sections are seen in some PowerPC
> > builds, where there is a orphan section warning then build failure:
> >
> > $ make -skj"$(nproc)" \
> > ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- LLVM=1 O=out \
> > distclean powernv_defconfig zImage.epapr
> > ld.lld: warning: kernel/built-in.a(panic.o):(.text.unlikely.) is being placed in '.text.unlikely.'
>
> Is the section really called ".text.unlikely.", i.e. the name ending in
> a dot? How very unusual, is there some bug elsewhere?
No, this was an intention change done by LLVM:
https://reviews.llvm.org/D79600
Cheers,
Nathan
^ permalink raw reply
* Re: CONFIG_PPC_VAS depends on 64k pages...?
From: Carlos Eduardo de Paula @ 2021-01-15 13:54 UTC (permalink / raw)
To: Will Springer
Cc: Tulio Magno Quites Machado Filho, daniel, haren, Bulent Abali,
Sukadev Bhattiprolu, linuxppc-dev, Raphael M Zinsly
In-Reply-To: <7176054.EvYhyI6sBW@sheen>
[-- Attachment #1: Type: text/plain, Size: 6228 bytes --]
Hi all, any news on this matter?
Can a patch be submitted for evaluation?
Thanks,
Carlos
On Wed, Dec 2, 2020 at 4:19 AM Will Springer <skirmisher@protonmail.com>
wrote:
> On Tuesday, December 1, 2020 5:16:51 AM PST Bulent Abali wrote:
> > I don't know anything about VAS page size requirements in the kernel. I
> > checked the user compression library and saw that we do a sysconf to
> > get the page size; so the library should be immune to page size by
> > design. But it wouldn't surprise me if a 64KB constant is inadvertently
> > hardcoded somewhere else in the library. Giving heads up to Tulio and
> > Raphael who are owners of the github repo.
> >
> > https://github.com/libnxz/power-gzip/blob/master/lib/nx_zlib.c#L922
> >
> > If we got this wrong in the library it might manifest itself as an error
> > message of the sort "excessive page faults". The library must touch
> > pages ahead to make them present in the memory; occasional page faults
> > is acceptable. It will retry.
>
> Hm, good to know. As I said I haven't noticed any problems so far, over a
> few different days of testing. My change is now in the Void Linux kernel
> package, and is working for others as well (including the Void maintainer
> Daniel/q66 who I CC'd initially).
>
> >
> > Bulent
> >
> >
> >
> >
> > From: "Sukadev Bhattiprolu" <sukadev@linux.ibm.com>
> > To: "Christophe Leroy" <christophe.leroy@csgroup.eu>
> > Cc: "Will Springer" <skirmisher@protonmail.com>,
> > linuxppc-dev@lists.ozlabs.org, daniel@octaforge.org, Bulent
> > Abali/Watson/IBM@IBM, haren@linux.ibm.com Date: 12/01/2020 12:53
> > AM
> > Subject: Re: CONFIG_PPC_VAS depends on 64k pages...?
> >
> > Christophe Leroy [christophe.leroy@csgroup.eu] wrote:
> > > Hi,
> > >
> > > Le 19/11/2020 à 11:58, Will Springer a écrit :
> > > > I learned about the POWER9 gzip accelerator a few months ago when
> > > > the
> > > > support hit upstream Linux 5.8. However, for some reason the Kconfig
> > > > dictates that VAS depends on a 64k page size, which is problematic
> > > > as I
> > > > run Void Linux, which uses a 4k-page kernel.
> > > >
> > > > Some early poking by others indicated there wasn't an obvious page
> > > > size
> > > > dependency in the code, and suggested I try modifying the config to
> > > > switch it on. I did so, but was stopped by a minor complaint of an
> > > > "unexpected DT configuration" by the VAS code. I wasn't equipped to
> > > > figure out exactly what this meant, even after finding the
> > > > offending condition, so after writing a very drawn-out forum post
> > > > asking for help, I dropped the subject.
> > > >
> > > > Fast forward to today, when I was reminded of the whole thing again,
> > > > and decided to debug a bit further. Apparently the VAS platform
> > > > device (derived from the DT node) has 5 resources on my 4k kernel,
> > > > instead of 4 (which evidently works for others who have had success
> > > > on 64k kernels). I have no idea what this means in practice (I
> > > > don't know how to introspect it), but after making a tiny patch[1],
> > > > everything came up smoothly and I was doing blazing-fast gzip
> > > > (de)compression in no time.
> > > >
> > > > Everything seems to work fine on 4k pages. So, what's up? Are there
> > > > pitfalls lurking around that I've yet to stumble over? More
> > > > reasonably,
> > > > I'm curious as to why the feature supposedly depends on 64k pages,
> > > > or if there's anything else I should be concerned about.
> >
> > Will,
> >
> > The reason I put in that config check is because we were only able to
> > test 64K pages at that point.
> >
> > It is interesting that it is working for you. Following code in skiboot
> > https://github.com/open-power/skiboot/blob/master/hw/vas.cshould
> > restrict it to 64K pages. IIRC there is also a corresponding change in
> > some NX registers that should also be configured to allow 4K pages.
>
> Huh, that is interesting indeed. As far as the kernel code, the only thing
> specific to 64k pages I could find was in [1], where
> VAS_XLATE_LPCR_PAGE_SIZE is set. There is also NX_PAGE_SIZE in drivers/
> crypto/nx/nx.h, which is set to 4096, but I don't know if that's related
> to
> kernel page size at all. Without a better idea of the code base, I didn't
> examine more thoroughly.
>
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/powerpc/platforms/powernv/vas-window.c#n293
>
> > static int init_north_ctl(struct proc_chip *chip)
> > {
> > uint64_t val = 0ULL;
> >
> > val = SETFIELD(VAS_64K_MODE_MASK, val,
> > true); val = SETFIELD(VAS_ACCEPT_PASTE_MASK, val, true); val =
> > SETFIELD(VAS_ENABLE_WC_MMIO_BAR, val, true); val =
> > SETFIELD(VAS_ENABLE_UWC_MMIO_BAR, val, true); val =
> > SETFIELD(VAS_ENABLE_RMA_MMIO_BAR, val, true);
> >
> > return vas_scom_write(chip,
> > VAS_MISC_N_CTL, val); }
> >
> > I am copying Bulent Albali and Haren Myneni who have been working with
> > VAS/NX for their thoughts/experience.
>
> Thanks for this and for your input, by the way.
>
> >
> > > Maybe ask Sukadev who did the implementation and is maintaining it ?
> > >
> > > > I do have to say I'm quite satisfied with the results of the NX
> > > > accelerator, though. Being able to shuffle data to a RaptorCS box
> > > > over gigE and get compressed data back faster than most software
> > > > gzip could ever hope to achieve is no small feat, let alone the
> > > > instantaneous results locally.> >
> > > > :)
> > > >
> > > > Cheers,
> > > > Will Springer [she/her]
> > > >
> > > > [1]:
> > > >
> https://github.com/Skirmisher/void-packages/blob/vas-4k-pages/srcpkgs/linux5.9/patches/ppc-vas-on-4k.patch
> > > Christophe
>
> Will [she/her]
>
>
>
>
>
--
________________________________________
Carlos Eduardo de Paula
me@carlosedp.com
http://carlosedp.com
https://twitter.com/carlosedp
https://www.linkedin.com/in/carlosedp/
________________________________________
[-- Attachment #2: Type: text/html, Size: 9450 bytes --]
^ permalink raw reply
* RE: [PATCH] Adds a new ioctl32 syscall for backwards compatibility layers
From: David Laight @ 2021-01-15 20:01 UTC (permalink / raw)
To: 'sonicadvance1@gmail.com'
Cc: linux-xtensa@linux-xtensa.org, Rich Felker, Jan Kara,
Miklos Szeredi, Dominik Brodowski, linux-kernel@vger.kernel.org,
James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux@vger.kernel.org,
linux-ia64@vger.kernel.org, Christian Brauner, Vincenzo Frascino,
Will Deacon, linux-arch@vger.kernel.org, Stephen Rothwell,
Arnd Bergmann, Yoshinori Sato, linux-sh@vger.kernel.org,
Helge Deller, x86@kernel.org, YueHaibing, Russell King,
Christian Borntraeger, Ingo Molnar, Geert Uytterhoeven,
linux-arm-kernel@lists.infradead.org, Catalin Marinas,
Matt Turner, linux-mips@vger.kernel.org, Fenghua Yu,
Arnaldo Carvalho de Melo, Vasily Gorbik,
linux-s390@vger.kernel.org, Brian Gerst, Heiko Carstens,
David Rientjes, Willem de Bruijn, Nicholas Piggin,
Suren Baghdasaryan, Aleksa Sarai, Thomas Bogendoerfer,
Ivan Kokshaysky, Alexander Viro, Andy Lutomirski, Thomas Gleixner,
Xiaoming Ni, Vlastimil Babka, Richard Henderson, Chris Zankel,
Michal Simek, Tony Luck, linux-parisc@vger.kernel.org,
linux-m68k@lists.linux-m68k.org, linux-api@vger.kernel.org,
Oleg Nesterov, Minchan Kim, Eric W. Biederman,
linux-alpha@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Borislav Petkov, Andrew Morton, linuxppc-dev@lists.ozlabs.org,
David S. Miller
In-Reply-To: <20210115070326.294332-1-Sonicadvance1@gmail.com>
From: sonicadvance1@gmail.com
> Sent: 15 January 2021 07:03
> Problem presented:
> A backwards compatibility layer that allows running x86-64 and x86
> processes inside of an AArch64 process.
> - CPU is emulated
> - Syscall interface is mostly passthrough
> - Some syscalls require patching or emulation depending on behaviour
> - Not viable from the emulator design to use an AArch32 host process
>
You are going to need to add all the x86 compatibility code into
your arm64 kernel.
This is likely to be different from the 32bit arm compatibility
because 64bit items are only aligned on 32bit boundaries.
The x86 x32 compatibility will be more like the 32bit arm 'compat'
code - I'm pretty sure arm32 64bit aligned 64bit data.
You'll then need to remember how the process entered the kernel
to work out which compatibility code to invoke.
This is what x86 does.
It allows a single process to do all three types of system call.
Trying to 'patch up' structures outside the kernel, or in the
syscall interface code will always cause grief somewhere.
The only sane place is in the code that uses the structures.
Which, for ioctls, means inside the driver that parses them.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH] Adds a new ioctl32 syscall for backwards compatibility layers
From: Arnd Bergmann @ 2021-01-15 22:17 UTC (permalink / raw)
To: David Laight
Cc: linux-xtensa@linux-xtensa.org, Rich Felker, Jan Kara,
Miklos Szeredi, Dominik Brodowski, linux-kernel@vger.kernel.org,
James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux@vger.kernel.org,
linux-ia64@vger.kernel.org, Christian Brauner, Vincenzo Frascino,
Will Deacon, linux-arch@vger.kernel.org, Stephen Rothwell,
Arnd Bergmann, Yoshinori Sato, linux-sh@vger.kernel.org,
Helge Deller, x86@kernel.org, YueHaibing, Russell King,
Christian Borntraeger, Ingo Molnar, Geert Uytterhoeven,
linux-arm-kernel@lists.infradead.org, Catalin Marinas,
Matt Turner, linux-mips@vger.kernel.org, Fenghua Yu,
Arnaldo Carvalho de Melo, Vasily Gorbik, sonicadvance1@gmail.com,
Brian Gerst, Heiko Carstens, David Rientjes, Willem de Bruijn,
Nicholas Piggin, Suren Baghdasaryan, Aleksa Sarai,
Thomas Bogendoerfer, Ivan Kokshaysky, Alexander Viro,
Andy Lutomirski, Thomas Gleixner, Xiaoming Ni, Vlastimil Babka,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
linux-parisc@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
linux-s390@vger.kernel.org, Oleg Nesterov, Minchan Kim,
Eric W. Biederman, linux-alpha@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Borislav Petkov, Andrew Morton,
linux-api@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
David S. Miller
In-Reply-To: <b15672b1caec4cf980f2753d06b03596@AcuMS.aculab.com>
On Fri, Jan 15, 2021 at 9:01 PM David Laight <David.Laight@aculab.com> wrote:
>
> From: sonicadvance1@gmail.com
> > Sent: 15 January 2021 07:03
> > Problem presented:
> > A backwards compatibility layer that allows running x86-64 and x86
> > processes inside of an AArch64 process.
> > - CPU is emulated
> > - Syscall interface is mostly passthrough
> > - Some syscalls require patching or emulation depending on behaviour
> > - Not viable from the emulator design to use an AArch32 host process
> >
>
> You are going to need to add all the x86 compatibility code into
> your arm64 kernel.
> This is likely to be different from the 32bit arm compatibility
> because 64bit items are only aligned on 32bit boundaries.
> The x86 x32 compatibility will be more like the 32bit arm 'compat'
> code - I'm pretty sure arm32 64bit aligned 64bit data.
All other architectures that have both 32-bit and 64-bit variants
use the same alignment for all types, except for x86.
There are additional differences though, especially if one
were to try to generalize the interface to all architectures.
A subset of the issues includes
- x32 has 64-bit types in places of some types that are
32 bit everywhere else (time_t, ino_t, off_t, clock_t, ...)
- m68k aligns struct members to at most 16 bits
- uid_t/gid_t/ino_t/dev_t/... are
> You'll then need to remember how the process entered the kernel
> to work out which compatibility code to invoke.
> This is what x86 does.
> It allows a single process to do all three types of system call.
>
> Trying to 'patch up' structures outside the kernel, or in the
> syscall interface code will always cause grief somewhere.
> The only sane place is in the code that uses the structures.
> Which, for ioctls, means inside the driver that parses them.
He's already doing the system call emulation for all the system
calls other than ioctl in user space though. In my experience,
there are actually fairly few ioctl commands that are different
between architectures -- most of them have no misaligned
or architecture-defined struct members at all.
Once you have conversion functions to deal with the 32/64-bit
interface differences and architecture specifics of sockets,
sysvipc, signals, stat, and input_event, handling the
x86-32 specific ioctl commands is comparably easy.
Arnd
^ permalink raw reply
* RE: [PATCH] Adds a new ioctl32 syscall for backwards compatibility layers
From: David Laight @ 2021-01-15 22:39 UTC (permalink / raw)
To: 'Arnd Bergmann'
Cc: linux-xtensa@linux-xtensa.org, Rich Felker, Jan Kara,
Miklos Szeredi, Dominik Brodowski, linux-kernel@vger.kernel.org,
James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux@vger.kernel.org,
linux-ia64@vger.kernel.org, Christian Brauner, Vincenzo Frascino,
Will Deacon, linux-arch@vger.kernel.org, Stephen Rothwell,
Arnd Bergmann, Yoshinori Sato, linux-sh@vger.kernel.org,
Helge Deller, x86@kernel.org, YueHaibing, Russell King,
Christian Borntraeger, Ingo Molnar, Geert Uytterhoeven,
linux-arm-kernel@lists.infradead.org, Catalin Marinas,
Matt Turner, linux-mips@vger.kernel.org, Fenghua Yu,
Arnaldo Carvalho de Melo, Vasily Gorbik, sonicadvance1@gmail.com,
Brian Gerst, Heiko Carstens, David Rientjes, Willem de Bruijn,
Nicholas Piggin, Suren Baghdasaryan, Aleksa Sarai,
Thomas Bogendoerfer, Ivan Kokshaysky, Alexander Viro,
Andy Lutomirski, Thomas Gleixner, Xiaoming Ni, Vlastimil Babka,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
linux-parisc@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
linux-s390@vger.kernel.org, Oleg Nesterov, Minchan Kim,
Eric W. Biederman, linux-alpha@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Borislav Petkov, Andrew Morton,
linux-api@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
David S. Miller
In-Reply-To: <CAK8P3a1gqt-gBCPTdNeY+8SaG8eUGN4zkCrNKSjA=aEL-TkaUQ@mail.gmail.com>
...
> He's already doing the system call emulation for all the system
> calls other than ioctl in user space though. In my experience,
> there are actually fairly few ioctl commands that are different
> between architectures -- most of them have no misaligned
> or architecture-defined struct members at all.
Aren't there also some intractable issues with socket options?
IIRC the kernel code that tried to change them to 64bit was
horribly broken in some obscure cases.
Pushing the conversion down the stack not only identified the
issues, it also made them easier to fix.
If you change the kernel so a 64bit process can execute 32bit
system calls then a lot of the problems do go away.
This is probably easiest done by setting a high bit on the
system call number - as x86_64 does for x32 calls.
You still have to solve the different alignment of 64bit data
on i386.
Of course the system call numbers are different - but that is
just a lookup.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH] Adds a new ioctl32 syscall for backwards compatibility layers
From: Rich Felker @ 2021-01-15 22:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-xtensa@linux-xtensa.org, Jan Kara, Miklos Szeredi,
Dominik Brodowski, linux-kernel@vger.kernel.org,
James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux@vger.kernel.org,
linux-ia64@vger.kernel.org, Christian Brauner, Vincenzo Frascino,
Will Deacon, linux-arch@vger.kernel.org, Stephen Rothwell,
Arnd Bergmann, Yoshinori Sato, linux-sh@vger.kernel.org,
Helge Deller, x86@kernel.org, YueHaibing, Russell King,
Christian Borntraeger, Ingo Molnar, Geert Uytterhoeven,
linux-arm-kernel@lists.infradead.org, Catalin Marinas,
Matt Turner, linux-mips@vger.kernel.org, Fenghua Yu,
Arnaldo Carvalho de Melo, Vasily Gorbik, sonicadvance1@gmail.com,
Brian Gerst, Heiko Carstens, David Rientjes, Willem de Bruijn,
Nicholas Piggin, Suren Baghdasaryan, Aleksa Sarai,
Thomas Bogendoerfer, Ivan Kokshaysky, Alexander Viro,
Andy Lutomirski, Thomas Gleixner, Xiaoming Ni, Vlastimil Babka,
Richard Henderson, Chris Zankel, Michal Simek, Tony Luck,
linux-parisc@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
linux-s390@vger.kernel.org, Oleg Nesterov, Minchan Kim,
David Laight, Eric W. Biederman, linux-alpha@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Borislav Petkov, Andrew Morton,
linux-api@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
David S. Miller
In-Reply-To: <CAK8P3a1gqt-gBCPTdNeY+8SaG8eUGN4zkCrNKSjA=aEL-TkaUQ@mail.gmail.com>
On Fri, Jan 15, 2021 at 11:17:09PM +0100, Arnd Bergmann wrote:
> On Fri, Jan 15, 2021 at 9:01 PM David Laight <David.Laight@aculab.com> wrote:
> >
> > From: sonicadvance1@gmail.com
> > > Sent: 15 January 2021 07:03
> > > Problem presented:
> > > A backwards compatibility layer that allows running x86-64 and x86
> > > processes inside of an AArch64 process.
> > > - CPU is emulated
> > > - Syscall interface is mostly passthrough
> > > - Some syscalls require patching or emulation depending on behaviour
> > > - Not viable from the emulator design to use an AArch32 host process
> > >
> >
> > You are going to need to add all the x86 compatibility code into
> > your arm64 kernel.
> > This is likely to be different from the 32bit arm compatibility
> > because 64bit items are only aligned on 32bit boundaries.
> > The x86 x32 compatibility will be more like the 32bit arm 'compat'
> > code - I'm pretty sure arm32 64bit aligned 64bit data.
>
> All other architectures that have both 32-bit and 64-bit variants
> use the same alignment for all types, except for x86.
>
> There are additional differences though, especially if one
> were to try to generalize the interface to all architectures.
> A subset of the issues includes
>
> - x32 has 64-bit types in places of some types that are
> 32 bit everywhere else (time_t, ino_t, off_t, clock_t, ...)
>
> - m68k aligns struct members to at most 16 bits
>
> - uid_t/gid_t/ino_t/dev_t/... are
>
> > You'll then need to remember how the process entered the kernel
> > to work out which compatibility code to invoke.
> > This is what x86 does.
> > It allows a single process to do all three types of system call.
> >
> > Trying to 'patch up' structures outside the kernel, or in the
> > syscall interface code will always cause grief somewhere.
> > The only sane place is in the code that uses the structures.
> > Which, for ioctls, means inside the driver that parses them.
>
> He's already doing the system call emulation for all the system
> calls other than ioctl in user space though. In my experience,
> there are actually fairly few ioctl commands that are different
> between architectures -- most of them have no misaligned
> or architecture-defined struct members at all.
>
> Once you have conversion functions to deal with the 32/64-bit
> interface differences and architecture specifics of sockets,
> sysvipc, signals, stat, and input_event, handling the
> x86-32 specific ioctl commands is comparably easy.
Indeed, all of this should just be done in userspace. Note (as you of
course know, but others on CC probably don't) that we did this in musl
libc for the sake of being able to run a time64 userspace on a
pre-time64 kernel, with translation from the new time64 ioctl
structures to the versions needed by the old ioctls and back using a
fairly simple table:
https://git.musl-libc.org/cgit/musl/tree/src/misc/ioctl.c?id=v1.2.2
I imagine there's a fair bit more to be done for 32-/64-bit mismatch
in size/long/pointer types and different alignments, but the problem
is almost certainly tractable, and much easier than what they already
have to be doing for syscalls.
Rich
^ permalink raw reply
* Re: [RESEND v2 0/7] Rid W=1 warnings in Ethernet
From: patchwork-bot+netdevbpf @ 2021-01-17 2:20 UTC (permalink / raw)
To: Lee Jones
Cc: paul, kurt, ast, gustavoars, pc, paulus, sukadev, wei.liu, daniel,
john.fastabend, santi_leon, kuba, grygorii.strashko, tlfalcon,
hawk, Jens.Osterkamp, rusty, dnevil, ljp, xen-devel,
ivan.khoronzhuk, nico, geoff, netdev, linux-kernel, erik, jallen,
utz.bacher, drt, bpf, linuxppc-dev, davem, rmk
In-Reply-To: <20210115200905.3470941-1-lee.jones@linaro.org>
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Fri, 15 Jan 2021 20:08:58 +0000 you wrote:
> Resending the stragglers again.
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> No changes since v2, just a rebase onto net-next.
>
> [...]
Here is the summary with links:
- [1/7] net: ethernet: smsc: smc91x: Fix function name in kernel-doc header
https://git.kernel.org/netdev/net-next/c/7d2a92445e3f
- [2/7] net: xen-netback: xenbus: Demote nonconformant kernel-doc headers
https://git.kernel.org/netdev/net-next/c/090c7ae8e0d0
- [3/7] net: ethernet: ti: am65-cpsw-qos: Demote non-conformant function header
https://git.kernel.org/netdev/net-next/c/935888cda820
- [4/7] net: ethernet: ti: am65-cpts: Document am65_cpts_rx_enable()'s 'en' parameter
https://git.kernel.org/netdev/net-next/c/e49e4647f3e2
- [5/7] net: ethernet: ibm: ibmvnic: Fix some kernel-doc misdemeanours
https://git.kernel.org/netdev/net-next/c/807086021bf5
- [6/7] net: ethernet: toshiba: ps3_gelic_net: Fix some kernel-doc misdemeanours
https://git.kernel.org/netdev/net-next/c/b51036321461
- [7/7] net: ethernet: toshiba: spider_net: Document a whole bunch of function parameters
https://git.kernel.org/netdev/net-next/c/e242d5989965
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* ibmvnic: Race condition in remove callback
From: Uwe Kleine-König @ 2021-01-17 10:12 UTC (permalink / raw)
To: Dany Madden, Lijun Pan, Sukadev Bhattiprolu, Michael Ellerman,
Juliet Kim
Cc: Greg Kroah-Hartman, Paul Mackerras, kernel, netdev,
Jakub Kicinski, linuxppc-dev, David S. Miller
[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]
Hello,
while working on some cleanup I stumbled over a problem in the ibmvnic's
remove callback. Since commit
7d7195a026ba ("ibmvnic: Do not process device remove during device reset")
there is the following code in the remove callback:
static int ibmvnic_remove(struct vio_dev *dev)
{
...
spin_lock_irqsave(&adapter->state_lock, flags);
if (test_bit(0, &adapter->resetting)) {
spin_unlock_irqrestore(&adapter->state_lock, flags);
return -EBUSY;
}
adapter->state = VNIC_REMOVING;
spin_unlock_irqrestore(&adapter->state_lock, flags);
flush_work(&adapter->ibmvnic_reset);
flush_delayed_work(&adapter->ibmvnic_delayed_reset);
...
}
Unfortunately returning -EBUSY doesn't work as intended. That's because
the return value of this function is ignored[1] and the device is
considered unbound by the device core (shortly) after ibmvnic_remove()
returns.
While looking into fixing that I noticed a worse problem:
If ibmvnic_reset() (e.g. called by the tx_timeout callback) calls
schedule_work(&adapter->ibmvnic_reset); just after the work queue is
flushed above the problem that 7d7195a026ba intends to fix will trigger
resulting in a use-after-free.
Also ibmvnic_reset() checks for adapter->state without holding the lock
which might be racy, too.
Best regards
Uwe
[1] vio_bus_remove (in arch/powerpc/platforms/pseries/vio.c) records the
return value and passes it on. But the driver core doesn't care for
the return value (see __device_release_driver() in drivers/base/dd.c
calling dev->bus->remove()).
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.11-4 tag
From: Michael Ellerman @ 2021-01-17 10:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: arielmarcovitch, schwab, linuxppc-dev, linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Linus,
Please pull some more powerpc fixes for 5.11:
The following changes since commit 3ce47d95b7346dcafd9bed3556a8d072cb2b8571:
powerpc: Handle .text.{hot,unlikely}.* in linker script (2021-01-06 21:59:04 +1100)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.11-4
for you to fetch changes up to 41131a5e54ae7ba5a2bb8d7b30d1818b3f5b13d2:
powerpc/vdso: Fix clock_gettime_fallback for vdso32 (2021-01-14 15:56:44 +1100)
- ------------------------------------------------------------------
powerpc fixes for 5.11 #4
One fix for a lack of alignment in our linker script, that can lead to crashes
depending on configuration etc.
One fix for the 32-bit VDSO after the C VDSO conversion.
Thanks to:
Andreas Schwab, Ariel Marcovitch, Christophe Leroy.
- ------------------------------------------------------------------
Andreas Schwab (1):
powerpc/vdso: Fix clock_gettime_fallback for vdso32
Ariel Marcovitch (1):
powerpc: Fix alignment bug within the init sections
arch/powerpc/include/asm/vdso/gettimeofday.h | 16 +++++++++++++++-
arch/powerpc/kernel/vmlinux.lds.S | 8 ++++++++
2 files changed, 23 insertions(+), 1 deletion(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmAED74ACgkQUevqPMjh
pYAyFRAAr2/3tLnaJgu8LIkr64AUuNAXsAhTaVb3MEemJtR7FSEK8pJjw/AtQmHh
aTB9Y4qp2kOSQq6C6j4cMitGUYOiDEayCHPP1SserIRVJXmC453jqKb/iHrpaVWo
zBdrqrMzgFhlfT6/IDVw/+e5rjycwp9QicQZ0DRX15ZXlqlMSr1b6VH3opku4DyV
a9OP/LlR6PAgZQn+qTfeB/z7HnwOdy9R5i/UnrALqrzKGOneQXd+jv7THbudMs/D
aVTapfuoon1SPSLWy7xSVKIjFxwV4KUMi0R5kjWlWkXFqdLA2r8XRE3sKcLW1IN1
0Yibv1DRddsnluqe5lclQgzWPfRLdjPhgoIwIq3Ze50aSMuLXU5TatPzXVVKFDWT
emVMyQ/SOzWdI7mwsbN1GK85x7cvWW7wMLtEnvJ82vQJpJtAJEyWEZ9UozfpBrPq
/H2rrisWMFyZhl3eDdcJCwV7YeOxdCnmqmJnnkTMypRRXyWlfJDHs0CP7fWiKu+j
XMsPhxM1hyfrueOW7iPBEt/ZkB17Eq1V0Z2OQU+chXqJmmh9gwSBb/F8iJ48Iphi
4L2ynxJTAHwFY27xE1CQIF0VKycIc7djkDhYoJaL8PaVXQkUo/NWy4zOVNzJpeen
HbeLjHKGeeGetWxOniBCgD0PxoOQH8ThQauz+NwzeACGgyPzkM0=
=fJl5
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH v15 09/10] arm64: Call kmalloc() to allocate DTB buffer
From: Mimi Zohar @ 2021-01-17 13:23 UTC (permalink / raw)
To: Lakshmi Ramasubramanian, bauerman, robh, takahiro.akashi, gregkh,
will, catalin.marinas, mpe, Arnd Bergmann
Cc: mark.rutland, bhsharma, tao.li, paulus, vincenzo.frascino,
frowand.list, sashal, masahiroy, jmorris, linux-arm-kernel, serge,
devicetree, pasha.tatashin, prsriva, hsinyi, allison,
christophe.leroy, mbrugger, balajib, dmitry.kasatkin,
linux-kernel, james.morse, linux-integrity, linuxppc-dev
In-Reply-To: <20210115173017.30617-10-nramas@linux.microsoft.com>
Hi Ard,
On Fri, 2021-01-15 at 09:30 -0800, Lakshmi Ramasubramanian wrote:
> create_dtb() function allocates kernel virtual memory for
> the device tree blob (DTB). This is not consistent with other
> architectures, such as powerpc, which calls kmalloc() for allocating
> memory for the DTB.
>
> Call kmalloc() to allocate memory for the DTB, and kfree() to free
> the allocated memory.
The vmalloc() function description says, "vmalloc - allocate virtually
contiguous memory". I'd appreciate your reviewing this patch, in
particular, which replaces vmalloc() with kmalloc().
thanks,
Mimi
>
> Co-developed-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
> Signed-off-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
> Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
> ---
> arch/arm64/kernel/machine_kexec_file.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> index 7de9c47dee7c..51c40143d6fa 100644
> --- a/arch/arm64/kernel/machine_kexec_file.c
> +++ b/arch/arm64/kernel/machine_kexec_file.c
> @@ -29,7 +29,7 @@ const struct kexec_file_ops * const kexec_file_loaders[] = {
>
> int arch_kimage_file_post_load_cleanup(struct kimage *image)
> {
> - vfree(image->arch.dtb);
> + kfree(image->arch.dtb);
> image->arch.dtb = NULL;
>
> vfree(image->arch.elf_headers);
> @@ -59,19 +59,21 @@ static int create_dtb(struct kimage *image,
> + cmdline_len + DTB_EXTRA_SPACE;
>
> for (;;) {
> - buf = vmalloc(buf_size);
> + buf = kmalloc(buf_size, GFP_KERNEL);
> if (!buf)
> return -ENOMEM;
>
> /* duplicate a device tree blob */
> ret = fdt_open_into(initial_boot_params, buf, buf_size);
> - if (ret)
> + if (ret) {
> + kfree(buf);
> return -EINVAL;
> + }
>
> ret = of_kexec_setup_new_fdt(image, buf, initrd_load_addr,
> initrd_len, cmdline);
> if (ret) {
> - vfree(buf);
> + kfree(buf);
> if (ret == -ENOMEM) {
> /* unlikely, but just in case */
> buf_size += DTB_EXTRA_SPACE;
> @@ -217,6 +219,6 @@ int load_other_segments(struct kimage *image,
> return 0;
>
> out_err:
> - vfree(dtb);
> + kfree(dtb);
> return ret;
> }
^ permalink raw reply
* Re: [PATCH v3 4/8] powerpc/signal64: Remove TM ifdefery in middle of if/else block
From: Christopher M. Riedl @ 2021-01-17 17:16 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <80d49969-880f-5161-c829-cf319f94351d@csgroup.eu>
On Mon Jan 11, 2021 at 7:29 AM CST, Christophe Leroy wrote:
>
>
> Le 09/01/2021 à 04:25, Christopher M. Riedl a écrit :
> > Rework the messy ifdef breaking up the if-else for TM similar to
> > commit f1cf4f93de2f ("powerpc/signal32: Remove ifdefery in middle of if/else").
> >
> > Unlike that commit for ppc32, the ifdef can't be removed entirely since
> > uc_transact in sigframe depends on CONFIG_PPC_TRANSACTIONAL_MEM.
> >
> > Signed-off-by: Christopher M. Riedl <cmr@codefail.de>
> > ---
> > arch/powerpc/kernel/signal_64.c | 17 +++++++----------
> > 1 file changed, 7 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
> > index b211a8ea4f6e..dd3787f67a78 100644
> > --- a/arch/powerpc/kernel/signal_64.c
> > +++ b/arch/powerpc/kernel/signal_64.c
> > @@ -710,9 +710,7 @@ SYSCALL_DEFINE0(rt_sigreturn)
> > struct pt_regs *regs = current_pt_regs();
> > struct ucontext __user *uc = (struct ucontext __user *)regs->gpr[1];
> > sigset_t set;
> > -#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> > unsigned long msr;
> > -#endif
> >
> > /* Always make any pending restarted system calls return -EINTR */
> > current->restart_block.fn = do_no_restart_syscall;
> > @@ -762,10 +760,12 @@ SYSCALL_DEFINE0(rt_sigreturn)
> > * restore_tm_sigcontexts.
> > */
> > regs->msr &= ~MSR_TS_MASK;
> > +#endif
> >
> > if (__get_user(msr, &uc->uc_mcontext.gp_regs[PT_MSR]))
> > goto badframe;
>
> This means you are doing that __get_user() even when msr is not used.
> That should be avoided.
>
Thanks, I moved it into the #ifdef block right above it instead for the
next spin.
> > if (MSR_TM_ACTIVE(msr)) {
> > +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> > /* We recheckpoint on return. */
> > struct ucontext __user *uc_transact;
> >
> > @@ -778,9 +778,8 @@ SYSCALL_DEFINE0(rt_sigreturn)
> > if (restore_tm_sigcontexts(current, &uc->uc_mcontext,
> > &uc_transact->uc_mcontext))
> > goto badframe;
> > - } else
> > #endif
> > - {
> > + } else {
> > /*
> > * Fall through, for non-TM restore
> > *
> > @@ -818,10 +817,8 @@ int handle_rt_signal64(struct ksignal *ksig, sigset_t *set,
> > unsigned long newsp = 0;
> > long err = 0;
> > struct pt_regs *regs = tsk->thread.regs;
> > -#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> > /* Save the thread's msr before get_tm_stackpointer() changes it */
> > - unsigned long msr = regs->msr;
> > -#endif
> > + unsigned long msr __maybe_unused = regs->msr;
>
> I don't thing __maybe_unused() is the right solution.
>
> I think MSR_TM_ACTIVE() should be fixed instead, either by changing it
> into a static inline
> function, or doing something similar to
> https://github.com/linuxppc/linux/commit/05a4ab823983d9136a460b7b5e0d49ee709a6f86
>
Agreed, I'll change MSR_TM_ACTIVE() to reference its argument in the
macro. This keeps it consistent with all the other MSR_TM_* macros in
reg.h. Probably better than changing it to static inline since that
would mean changing all the macros too which seems unecessary.
> >
> > frame = get_sigframe(ksig, tsk, sizeof(*frame), 0);
> > if (!access_ok(frame, sizeof(*frame)))
> > @@ -836,8 +833,9 @@ int handle_rt_signal64(struct ksignal *ksig, sigset_t *set,
> > /* Create the ucontext. */
> > err |= __put_user(0, &frame->uc.uc_flags);
> > err |= __save_altstack(&frame->uc.uc_stack, regs->gpr[1]);
> > -#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> > +
> > if (MSR_TM_ACTIVE(msr)) {
> > +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> > /* The ucontext_t passed to userland points to the second
> > * ucontext_t (for transactional state) with its uc_link ptr.
> > */
> > @@ -847,9 +845,8 @@ int handle_rt_signal64(struct ksignal *ksig, sigset_t *set,
> > tsk, ksig->sig, NULL,
> > (unsigned long)ksig->ka.sa.sa_handler,
> > msr);
> > - } else
> > #endif
> > - {
> > + } else {
> > err |= __put_user(0, &frame->uc.uc_link);
> > prepare_setup_sigcontext(tsk, 1);
> > err |= setup_sigcontext(&frame->uc.uc_mcontext, tsk, ksig->sig,
> >
>
> Christophe
^ permalink raw reply
* Re: [PATCH v3 1/8] powerpc/uaccess: Add unsafe_copy_from_user
From: Christopher M. Riedl @ 2021-01-17 17:19 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <eb4f68f4-f606-007d-6552-8a46cb9912b4@csgroup.eu>
On Mon Jan 11, 2021 at 7:22 AM CST, Christophe Leroy wrote:
>
>
> Le 09/01/2021 à 04:25, Christopher M. Riedl a écrit :
> > Implement raw_copy_from_user_allowed() which assumes that userspace read
> > access is open. Use this new function to implement raw_copy_from_user().
> > Finally, wrap the new function to follow the usual "unsafe_" convention
> > of taking a label argument.
>
> I think there is no point implementing raw_copy_from_user_allowed(), see
> https://github.com/linuxppc/linux/commit/4b842e4e25b1 and
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/8c74fc9ce8131cabb10b3e95dc0e430f396ee83e.1610369143.git.christophe.leroy@csgroup.eu/
>
> You should simply do:
>
> #define unsafe_copy_from_user(d, s, l, e) \
> unsafe_op_wrap(__copy_tofrom_user((__force void __user *)d, s, l), e)
>
I gave this a try and the signal ops decreased by ~8K. Now, to be
honest, I am not sure what an "acceptable" benchmark number here
actually is - so maybe this is ok? Same loss with both radix and hash:
| | hash | radix |
| ------------------------------------ | ------ | ------ |
| linuxppc/next | 118693 | 133296 |
| linuxppc/next w/o KUAP+KUEP | 228911 | 228654 |
| unsafe-signal64 | 200480 | 234067 |
| unsafe-signal64 (__copy_tofrom_user) | 192467 | 225119 |
To put this into perspective, prior to KUAP and uaccess flush, signal
performance in this benchmark was ~290K on hash.
>
> Christophe
>
> >
> > The new raw_copy_from_user_allowed() calls non-inline __copy_tofrom_user()
> > internally. This is still safe to call inside user access blocks formed
> > with user_*_access_begin()/user_*_access_end() since asm functions are not
> > instrumented for tracing.
> >
> > Signed-off-by: Christopher M. Riedl <cmr@codefail.de>
> > ---
> > arch/powerpc/include/asm/uaccess.h | 28 +++++++++++++++++++---------
> > 1 file changed, 19 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
> > index 501c9a79038c..698f3a6d6ae5 100644
> > --- a/arch/powerpc/include/asm/uaccess.h
> > +++ b/arch/powerpc/include/asm/uaccess.h
> > @@ -403,38 +403,45 @@ raw_copy_in_user(void __user *to, const void __user *from, unsigned long n)
> > }
> > #endif /* __powerpc64__ */
> >
> > -static inline unsigned long raw_copy_from_user(void *to,
> > - const void __user *from, unsigned long n)
> > +static inline unsigned long
> > +raw_copy_from_user_allowed(void *to, const void __user *from, unsigned long n)
> > {
> > - unsigned long ret;
> > if (__builtin_constant_p(n) && (n <= 8)) {
> > - ret = 1;
> > + unsigned long ret = 1;
> >
> > switch (n) {
> > case 1:
> > barrier_nospec();
> > - __get_user_size(*(u8 *)to, from, 1, ret);
> > + __get_user_size_allowed(*(u8 *)to, from, 1, ret);
> > break;
> > case 2:
> > barrier_nospec();
> > - __get_user_size(*(u16 *)to, from, 2, ret);
> > + __get_user_size_allowed(*(u16 *)to, from, 2, ret);
> > break;
> > case 4:
> > barrier_nospec();
> > - __get_user_size(*(u32 *)to, from, 4, ret);
> > + __get_user_size_allowed(*(u32 *)to, from, 4, ret);
> > break;
> > case 8:
> > barrier_nospec();
> > - __get_user_size(*(u64 *)to, from, 8, ret);
> > + __get_user_size_allowed(*(u64 *)to, from, 8, ret);
> > break;
> > }
> > if (ret == 0)
> > return 0;
> > }
> >
> > + return __copy_tofrom_user((__force void __user *)to, from, n);
> > +}
> > +
> > +static inline unsigned long
> > +raw_copy_from_user(void *to, const void __user *from, unsigned long n)
> > +{
> > + unsigned long ret;
> > +
> > barrier_nospec();
> > allow_read_from_user(from, n);
> > - ret = __copy_tofrom_user((__force void __user *)to, from, n);
> > + ret = raw_copy_from_user_allowed(to, from, n);
> > prevent_read_from_user(from, n);
> > return ret;
> > }
> > @@ -542,6 +549,9 @@ user_write_access_begin(const void __user *ptr, size_t len)
> > #define unsafe_get_user(x, p, e) unsafe_op_wrap(__get_user_allowed(x, p), e)
> > #define unsafe_put_user(x, p, e) __put_user_goto(x, p, e)
> >
> > +#define unsafe_copy_from_user(d, s, l, e) \
> > + unsafe_op_wrap(raw_copy_from_user_allowed(d, s, l), e)
> > +
> > #define unsafe_copy_to_user(d, s, l, e) \
> > do { \
> > u8 __user *_dst = (u8 __user *)(d); \
> >
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.11-4 tag
From: pr-tracker-bot @ 2021-01-17 20:31 UTC (permalink / raw)
To: Michael Ellerman
Cc: arielmarcovitch, schwab, Linus Torvalds, linuxppc-dev,
linux-kernel
In-Reply-To: <87o8hnn9of.fsf@mpe.ellerman.id.au>
The pull request you sent on Sun, 17 Jan 2021 21:24:00 +1100:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.11-4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a1339d6355ac42e1bf4fcdfce8bfce61172f8891
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: powerpc: Add a schema for the 'sleep' property
From: Johan Jonker @ 2021-01-17 16:10 UTC (permalink / raw)
To: Rob Herring, devicetree
Cc: Heiko Stuebner, linux-kernel, open list:ARM/Rockchip SoC...,
Paul Mackerras, linuxppc-dev
In-Reply-To: <20201008142420.2083861-1-robh@kernel.org>
Hi Rob,
This patch generates notifications in the Rockchip ARM and arm64 tree.
Could you limit the scope to PowerPC only.
Kind regards,
Johan Jonker
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/powerpc/sleep.yaml
make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/powerpc/sleep.yaml
Example:
/arch/arm64/boot/dts/rockchip/rk3399pro-rock-pi-n10.dt.yaml: pinctrl:
sleep: {'ddrio-pwroff': {'rockchip,pins': [[0, 1, 1, 168]]},
'ap-pwroff': {'rockchip,pins': [[1, 5, 1, 168]]}} is not of type 'array'
From schema: /Documentation/devicetree/bindings/powerpc/sleep.yaml
On 10/8/20 4:24 PM, Rob Herring wrote:
> Document the PowerPC specific 'sleep' property as a schema. It is
> currently only documented in booting-without-of.rst which is getting
> removed.
>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/powerpc/sleep.yaml | 47 +++++++++++++++++++
> 1 file changed, 47 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/powerpc/sleep.yaml
>
> diff --git a/Documentation/devicetree/bindings/powerpc/sleep.yaml b/Documentation/devicetree/bindings/powerpc/sleep.yaml
> new file mode 100644
> index 000000000000..6494c7d08b93
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/sleep.yaml
> @@ -0,0 +1,47 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/powerpc/sleep.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PowerPC sleep property
> +
> +maintainers:
> + - Rob Herring <robh@kernel.org>
> +
> +description: |
> + Devices on SOCs often have mechanisms for placing devices into low-power
> + states that are decoupled from the devices' own register blocks. Sometimes,
> + this information is more complicated than a cell-index property can
> + reasonably describe. Thus, each device controlled in such a manner
> + may contain a "sleep" property which describes these connections.
> +
> + The sleep property consists of one or more sleep resources, each of
> + which consists of a phandle to a sleep controller, followed by a
> + controller-specific sleep specifier of zero or more cells.
> +
> + The semantics of what type of low power modes are possible are defined
> + by the sleep controller. Some examples of the types of low power modes
> + that may be supported are:
> +
> + - Dynamic: The device may be disabled or enabled at any time.
> + - System Suspend: The device may request to be disabled or remain
> + awake during system suspend, but will not be disabled until then.
> + - Permanent: The device is disabled permanently (until the next hard
> + reset).
> +
> + Some devices may share a clock domain with each other, such that they should
> + only be suspended when none of the devices are in use. Where reasonable,
> + such nodes should be placed on a virtual bus, where the bus has the sleep
> + property. If the clock domain is shared among devices that cannot be
> + reasonably grouped in this manner, then create a virtual sleep controller
> + (similar to an interrupt nexus, except that defining a standardized
> + sleep-map should wait until its necessity is demonstrated).
> +
> +select: true
> +
> +properties:
> + sleep:
> + $ref: /schemas/types.yaml#definitions/phandle-array
> +
> +additionalProperties: true
>
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 41d8cb7ece7c81e4eb897ed7ec7d3c3d72fd0af4
From: kernel test robot @ 2021-01-17 23:05 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 41d8cb7ece7c81e4eb897ed7ec7d3c3d72fd0af4 Automatic merge of 'master' into merge (2021-01-17 21:16)
elapsed time: 758m
configs tested: 112
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arc axs101_defconfig
arc axs103_smp_defconfig
mips loongson1b_defconfig
c6x dsk6455_defconfig
mips rbtx49xx_defconfig
sh se7343_defconfig
powerpc adder875_defconfig
powerpc linkstation_defconfig
mips capcella_defconfig
powerpc katmai_defconfig
h8300 allyesconfig
powerpc holly_defconfig
powerpc stx_gp3_defconfig
arm integrator_defconfig
mips maltasmvp_eva_defconfig
parisc generic-32bit_defconfig
sh sh2007_defconfig
m68k m5272c3_defconfig
sh rts7751r2dplus_defconfig
powerpc ps3_defconfig
arm clps711x_defconfig
arc vdk_hs38_defconfig
arm sama5_defconfig
powerpc iss476-smp_defconfig
nds32 defconfig
sh ap325rxa_defconfig
parisc defconfig
powerpc storcenter_defconfig
xtensa common_defconfig
powerpc mpc885_ads_defconfig
alpha alldefconfig
mips rs90_defconfig
arm pxa910_defconfig
sh ecovec24_defconfig
mips malta_kvm_guest_defconfig
nios2 alldefconfig
powerpc klondike_defconfig
mips nlm_xlr_defconfig
arm multi_v7_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
arc defconfig
sh allmodconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a006-20210117
x86_64 randconfig-a004-20210117
x86_64 randconfig-a001-20210117
x86_64 randconfig-a005-20210117
x86_64 randconfig-a003-20210117
x86_64 randconfig-a002-20210117
i386 randconfig-a005-20210117
i386 randconfig-a006-20210117
i386 randconfig-a004-20210117
i386 randconfig-a002-20210117
i386 randconfig-a003-20210117
i386 randconfig-a001-20210117
i386 randconfig-a012-20210117
i386 randconfig-a011-20210117
i386 randconfig-a016-20210117
i386 randconfig-a013-20210117
i386 randconfig-a015-20210117
i386 randconfig-a014-20210117
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a015-20210117
x86_64 randconfig-a016-20210117
x86_64 randconfig-a014-20210117
x86_64 randconfig-a012-20210117
x86_64 randconfig-a013-20210117
x86_64 randconfig-a011-20210117
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ 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