* Re: [PATCH 4.19] mm: fix exec activate_mm vs TLB shootdown and lazy tlb switching race
From: Greg KH @ 2020-11-04 9:05 UTC (permalink / raw)
To: Michael Ellerman; +Cc: peterz, linuxppc-dev, npiggin, linux-kernel, stable
In-Reply-To: <20201104011406.598487-1-mpe@ellerman.id.au>
On Wed, Nov 04, 2020 at 12:14:06PM +1100, Michael Ellerman wrote:
> From: Nicholas Piggin <npiggin@gmail.com>
>
> commit d53c3dfb23c45f7d4f910c3a3ca84bf0a99c6143 upstream.
>
> Reading and modifying current->mm and current->active_mm and switching
> mm should be done with irqs off, to prevent races seeing an intermediate
> state.
>
> This is similar to commit 38cf307c1f20 ("mm: fix kthread_use_mm() vs TLB
> invalidate"). At exec-time when the new mm is activated, the old one
> should usually be single-threaded and no longer used, unless something
> else is holding an mm_users reference (which may be possible).
>
> Absent other mm_users, there is also a race with preemption and lazy tlb
> switching. Consider the kernel_execve case where the current thread is
> using a lazy tlb active mm:
>
> call_usermodehelper()
> kernel_execve()
> old_mm = current->mm;
> active_mm = current->active_mm;
> *** preempt *** --------------------> schedule()
> prev->active_mm = NULL;
> mmdrop(prev active_mm);
> ...
> <-------------------- schedule()
> current->mm = mm;
> current->active_mm = mm;
> if (!old_mm)
> mmdrop(active_mm);
>
> If we switch back to the kernel thread from a different mm, there is a
> double free of the old active_mm, and a missing free of the new one.
>
> Closing this race only requires interrupts to be disabled while ->mm
> and ->active_mm are being switched, but the TLB problem requires also
> holding interrupts off over activate_mm. Unfortunately not all archs
> can do that yet, e.g., arm defers the switch if irqs are disabled and
> expects finish_arch_post_lock_switch() to be called to complete the
> flush; um takes a blocking lock in activate_mm().
>
> So as a first step, disable interrupts across the mm/active_mm updates
> to close the lazy tlb preempt race, and provide an arch option to
> extend that to activate_mm which allows architectures doing IPI based
> TLB shootdowns to close the second race.
>
> This is a bit ugly, but in the interest of fixing the bug and backporting
> before all architectures are converted this is a compromise.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> [mpe: Manual backport to 4.19 due to membarrier_exec_mmap(mm) changes]
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Link: https://lore.kernel.org/r/20200914045219.3736466-2-npiggin@gmail.com
> ---
> arch/Kconfig | 7 +++++++
> fs/exec.c | 15 ++++++++++++++-
> 2 files changed, 21 insertions(+), 1 deletion(-)
Now queued up, thanks!
greg k-h
^ permalink raw reply
* [PATCH 00/12] [Set 2] Rid W=1 warnings in Net
From: Lee Jones @ 2020-11-04 9:05 UTC (permalink / raw)
To: davem, kuba
Cc: Song Liu, Michael S. Tsirkin, Martin Habets, Kurt Kanzenbach,
Alexei Starovoitov, Gustavo A. R. Silva, Peter Cammaert,
Paul Mackerras, Dustin McIntire, Sukadev Bhattiprolu, Lee Jones,
Michal Simek, Wei Liu, Stefano Stabellini, Daniel Borkmann,
Paul Durrant, John Fastabend, Andrii Nakryiko, John Williams,
xen-devel, Woojung Huh, Grygorii Strashko, Thomas Falcon,
Jesper Dangaard Brouer, Jens Osterkamp, Rusty Russell,
Daris A Nevil, Lijun Pan, Yonghong Song, KP Singh,
Boris Ostrovsky, Santiago Leon, linux-arm-kernel, Juergen Gross,
Ivan Khoronzhuk, Nicolas Pitre, Geoff Levand, netdev, linux-usb,
linux-kernel, Microchip Linux Driver Support, Erik Stahlman,
John Allen, Utz Bacher, Dany Madden, bpf, Shannon Nelson,
linuxppc-dev, Martin KaFai Lau, Russell King
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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.
This is the last set.
Lee Jones (12):
net: usb: lan78xx: Remove lots of set but unused 'ret' variables
net: ethernet: smsc: smc911x: Mark 'status' as __maybe_unused
net: ethernet: xilinx: xilinx_emaclite: Document 'txqueue' even if it
is unused
net: ethernet: smsc: smc91x: Demote non-conformant kernel function
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: xen-netfront: Demote non-kernel-doc headers to standard comment
blocks
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
net: ethernet: ibm: ibmvnic: Fix some kernel-doc issues
drivers/net/ethernet/ibm/ibmvnic.c | 27 ++-
drivers/net/ethernet/smsc/smc911x.c | 6 +-
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 | 9 +-
drivers/net/ethernet/toshiba/spider_net.c | 18 +-
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 1 +
drivers/net/usb/lan78xx.c | 212 +++++++++---------
drivers/net/xen-netback/xenbus.c | 4 +-
drivers/net/xen-netfront.c | 6 +-
11 files changed, 141 insertions(+), 148 deletions(-)
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
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: Dustin McIntire <dustin@sensoria.com>
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: John Williams <john.williams@xilinx.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: KP Singh <kpsingh@chromium.org>
Cc: Kurt Kanzenbach <kurt@linutronix.de>
Cc: Lijun Pan <ljp@linux.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-usb@vger.kernel.org
Cc: Martin Habets <mhabets@solarflare.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
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: Shannon Nelson <snelson@pensando.io>
Cc: Song Liu <songliubraving@fb.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
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: Woojung Huh <woojung.huh@microchip.com>
Cc: xen-devel@lists.xenproject.org
Cc: Yonghong Song <yhs@fb.com>
--
2.25.1
^ permalink raw reply
* [PATCH 09/12] net: ethernet: ibm: ibmvnic: Fix some kernel-doc misdemeanours
From: Lee Jones @ 2020-11-04 9:06 UTC (permalink / raw)
To: davem, kuba
Cc: Thomas Falcon, linuxppc-dev, linux-kernel, Santiago Leon,
John Allen, netdev, Lijun Pan, Dany Madden, Paul Mackerras,
Sukadev Bhattiprolu, Lee Jones, linux-arm-kernel
In-Reply-To: <20201104090610.1446616-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 | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 1dc3cfdb38abc..b30e1f5784bad 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1357,10 +1357,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
+ * @tot_len: total length of data
*
* Reads hdr_field to determine which headers are needed by firmware.
* Builds a buffer containing these headers. Saves individual header
@@ -1417,11 +1417,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
+ * @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
@@ -1469,10 +1469,10 @@ 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
+ * @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
*
* This function will build a TX descriptor array with applicable
* L2/L3/L4 packet header descriptors to be sent by send_subcrq_indirect.
@@ -1835,7 +1835,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.
*/
--
2.25.1
^ permalink raw reply related
* [PATCH 10/12] net: ethernet: toshiba: ps3_gelic_net: Fix some kernel-doc misdemeanours
From: Lee Jones @ 2020-11-04 9:06 UTC (permalink / raw)
To: davem, kuba
Cc: Geoff Levand, linuxppc-dev, linux-kernel, Jens Osterkamp, netdev,
Paul Mackerras, Utz Bacher, Lee Jones, linux-arm-kernel
In-Reply-To: <20201104090610.1446616-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
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
index d9a5722f561b5..f886e23f8ed0a 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,10 +1789,9 @@ 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
*/
-
static int ps3_gelic_driver_remove(struct ps3_system_bus_device *dev)
{
struct gelic_card *card = ps3_system_bus_get_drvdata(dev);
--
2.25.1
^ permalink raw reply related
* [PATCH 12/12] net: ethernet: ibm: ibmvnic: Fix some kernel-doc issues
From: Lee Jones @ 2020-11-04 9:06 UTC (permalink / raw)
To: davem, kuba
Cc: Thomas Falcon, linuxppc-dev, linux-kernel, Santiago Leon,
John Allen, netdev, Paul Mackerras, Dany Madden, Lijun Pan,
Sukadev Bhattiprolu, Lee Jones, linux-arm-kernel
In-Reply-To: <20201104090610.1446616-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_data' not described in 'build_hdr_data'
drivers/net/ethernet/ibm/ibmvnic.c:1362: warning: Excess function parameter 'tot_len' description in 'build_hdr_data'
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: Excess function parameter 'data' description 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: Excess function parameter 'skb' description in 'build_hdr_descs_arr'
drivers/net/ethernet/ibm/ibmvnic.c:1474: warning: Excess function parameter 'subcrq' description in 'build_hdr_descs_arr'
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Dany Madden <drt@linux.ibm.com>
Cc: Lijun Pan <ljp@linux.ibm.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
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: linuxppc-dev@lists.ozlabs.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/net/ethernet/ibm/ibmvnic.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index b30e1f5784bad..08dab7a94b7ea 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1360,7 +1360,7 @@ static int ibmvnic_close(struct net_device *netdev)
* @hdr_field: bitfield determining needed headers
* @skb: socket buffer
* @hdr_len: array of header lengths
- * @tot_len: total length of data
+ * @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
@@ -1418,7 +1418,7 @@ 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
+ * @hdr_data: buffer containing header data
* @len: length of data buffer
* @hdr_len: array of individual header lengths
* @scrq_arr: descriptor array
@@ -1469,9 +1469,8 @@ 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
+ * @txbuff: tx buffer
* @num_entries: number of descriptors to be sent
- * @subcrq: first TX descriptor
* @hdr_field: bit field determining which headers will be sent
*
* This function will build a TX descriptor array with applicable
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] powerpc/32s: Setup the early hash table at all time.
From: Serge Belyshev @ 2020-11-04 9:28 UTC (permalink / raw)
To: Christophe Leroy
Cc: Paul Mackerras, Andreas Schwab, linuxppc-dev, linux-kernel
In-Reply-To: <871rh9mu4e.fsf@depni.sinp.msu.ru>
>> To be sure we are not in front of a long lasting bug, could you try
>> CONFIG_KASAN=y on v5.9 ?
>
> Indeed it started to fail somewhere between v5.6 and v5.7.
>
> v5.7 fails early with few messages on the console with reboot, v5.8 and
> later hang right at bootloader.
>
> I'm bisecting now.
(side note: I tried FB_OF=y instead of DRM_RADEON + DRM_FBDEV_* to speed
up bisection and it turns out in that configuration KASAN never worked,
down to commit 305d600123046, hanging right after bootloader or even
with invalid access in the bootloader itself).
^ permalink raw reply
* Re: [PATCH] x86/mpx: fix recursive munmap() corruption
From: Laurent Dufour @ 2020-11-04 9:41 UTC (permalink / raw)
To: Dmitry Safonov, Christophe Leroy, Michael Ellerman
Cc: mhocko, rguenther, linux-mm, Dave Hansen, x86, stable, LKML,
Dave Hansen, Thomas Gleixner, luto, linuxppc-dev, Andrew Morton,
vbabka
In-Reply-To: <02389b9c-141c-f5b7-756a-516599063766@gmail.com>
Le 03/11/2020 à 22:08, Dmitry Safonov a écrit :
> Hi Laurent, Christophe, Michael, all,
>
> On 11/3/20 5:11 PM, Laurent Dufour wrote:
>> Le 23/10/2020 à 14:28, Christophe Leroy a écrit :
> [..]
>>>>> That seems like it would work for CRIU and make sense in general?
>>>>
>>>> Sorry for the late answer, yes this would make more sense.
>>>>
>>>> Here is a patch doing that.
>>>>
>>>
>>> In your patch, the test seems overkill:
>>>
>>> + if ((start <= vdso_base && vdso_end <= end) || /* 1 */
>>> + (vdso_base <= start && start < vdso_end) || /* 3,4 */
>>> + (vdso_base < end && end <= vdso_end)) /* 2,3 */
>>> + mm->context.vdso_base = mm->context.vdso_end = 0;
>>>
>>> What about
>>>
>>> if (start < vdso_end && vdso_start < end)
>>> mm->context.vdso_base = mm->context.vdso_end = 0;
>>>
>>> This should cover all cases, or am I missing something ?
>>>
>>>
>>> And do we really need to store vdso_end in the context ?
>>> I think it should be possible to re-calculate it: the size of the VDSO
>>> should be (&vdso32_end - &vdso32_start) + PAGE_SIZE for 32 bits VDSO,
>>> and (&vdso64_end - &vdso64_start) + PAGE_SIZE for the 64 bits VDSO.
>>
>> Thanks Christophe for the advise.
>>
>> That is covering all the cases, and indeed is similar to the Michael's
>> proposal I missed last year.
>>
>> I'll send a patch fixing this issue following your proposal.
>
> It's probably not necessary anymore. I've sent patches [1], currently in
> akpm, the last one forbids splitting of vm_special_mapping.
> So, a user is able munmap() or mremap() vdso as a whole, but not partly.
Hi Dmitry,
That's a good thing too, but I think my patch is still valid in the PowerPC
code, fixing a bad check, even if some corner cases are handled earlier in the code.
> [1]:
> https://lore.kernel.org/linux-mm/20201013013416.390574-1-dima@arista.com/
>
> Thanks,
> Dmitry
>
^ permalink raw reply
* Re: [PATCH v1 2/4] powerpc/mm: print warning in arch_remove_linear_mapping()
From: osalvador @ 2020-11-04 9:42 UTC (permalink / raw)
To: David Hildenbrand
Cc: Michal Hocko, Wei Yang, linux-kernel, linux-mm, Paul Mackerras,
Rashmica Gupta, linuxppc-dev, Andrew Morton, Mike Rapoport
In-Reply-To: <20201029162718.29910-3-david@redhat.com>
On Thu, Oct 29, 2020 at 05:27:16PM +0100, David Hildenbrand wrote:
> Let's print a warning similar to in arch_add_linear_mapping() instead of
> WARN_ON_ONCE() and eventually crashing the kernel.
>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Rashmica Gupta <rashmica.g@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: Wei Yang <richard.weiyang@linux.alibaba.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> arch/powerpc/mm/mem.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 8a86d81f8df0..685028451dd2 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -145,7 +145,9 @@ void __ref arch_remove_linear_mapping(u64 start, u64 size)
> flush_dcache_range_chunked(start, start + size, FLUSH_CHUNK_SIZE);
>
> ret = remove_section_mapping(start, start + size);
> - WARN_ON_ONCE(ret);
> + if (ret)
> + pr_warn("Unable to remove linear mapping for 0x%llx..0x%llx: %d\n",
> + start, start + size, ret);
I guess the fear is to panic on systems that do have panic_on_warn (not
sure how many productions systems have this out there).
But anyway, being coherent with that, I think you should remove the WARN_ON
in hash__remove_section_mapping as well.
Besides that:
Reviewed-by: Oscar Salvador <osalvador@suse.
Not sure if the functions below that also have any sort of WARN_ON.
native_hpte_removebolted has a VM_WARN_ON, but that is on
CONFIG_DEBUG_VM so does not really matter.
--
Oscar Salvador
SUSE L3
^ permalink raw reply
* Re: [PATCH v1 3/4] powerpc/mm: remove linear mapping if __add_pages() fails in arch_add_memory()
From: osalvador @ 2020-11-04 9:50 UTC (permalink / raw)
To: David Hildenbrand
Cc: Michal Hocko, Wei Yang, linux-kernel, linux-mm, Paul Mackerras,
Rashmica Gupta, linuxppc-dev, Andrew Morton, Mike Rapoport
In-Reply-To: <20201029162718.29910-4-david@redhat.com>
On Thu, Oct 29, 2020 at 05:27:17PM +0100, David Hildenbrand wrote:
> Let's revert what we did in case seomthing goes wrong and we return an
> error.
Dumb question, but should not we do this for other arches as well?
--
Oscar Salvador
SUSE L3
^ permalink raw reply
* Re: [PATCH seccomp 3/8] powerpc: Enable seccomp architecture tracking
From: Michael Ellerman @ 2020-11-04 10:22 UTC (permalink / raw)
To: YiFei Zhu, containers
Cc: linux-sh, Tobin Feldman-Fitzthum, Hubertus Franke, Jack Chen,
linux-riscv, Andrea Arcangeli, linux-s390, YiFei Zhu, linux-csky,
Tianyin Xu, linux-xtensa, Kees Cook, Jann Horn, Valentin Rothberg,
Aleksa Sarai, Josep Torrellas, Will Drewry, linux-parisc,
linux-kernel, Andy Lutomirski, Dimitrios Skarlatos, David Laight,
Giuseppe Scrivano, linuxppc-dev, Tycho Andersen
In-Reply-To: <4ec2970fcc819eb4d5dac2bd35233ccdadfda845.1604410035.git.yifeifz2@illinois.edu>
YiFei Zhu <zhuyifei1999@gmail.com> writes:
> From: YiFei Zhu <yifeifz2@illinois.edu>
>
> To enable seccomp constant action bitmaps, we need to have a static
> mapping to the audit architecture and system call table size. Add these
> for powerpc.
>
> Signed-off-by: YiFei Zhu <yifeifz2@illinois.edu>
> ---
> arch/powerpc/include/asm/seccomp.h | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/seccomp.h b/arch/powerpc/include/asm/seccomp.h
> index 51209f6071c5..3efcc83e9cc6 100644
> --- a/arch/powerpc/include/asm/seccomp.h
> +++ b/arch/powerpc/include/asm/seccomp.h
> @@ -8,4 +8,25 @@
>
> #include <asm-generic/seccomp.h>
>
> +#ifdef __LITTLE_ENDIAN__
As Kees mentioned this should (must?!) match the configured endian.
But I think it would still be better to use the CONFIG symbol, which is
CONFIG_CPU_LITTLE_ENDIAN.
> +#define __SECCOMP_ARCH_LE_BIT __AUDIT_ARCH_LE
> +#else
> +#define __SECCOMP_ARCH_LE_BIT 0
> +#endif
> +
> +#ifdef CONFIG_PPC64
> +# define SECCOMP_ARCH_NATIVE (AUDIT_ARCH_PPC64 | __SECCOMP_ARCH_LE)
You use __SECCOMP_ARCH_LE there, but previously you only defined
__SECCOMP_ARCH_LE_BIT.
Is there some magic somewhere that defines __SECCOMP_ARCH_LE based on
__SECCOMP_ARCH_LE_BIT ?
> +# define SECCOMP_ARCH_NATIVE_NR NR_syscalls
> +# define SECCOMP_ARCH_NATIVE_NAME "ppc64"
What's the name used for?
Usually we use "ppc64" for 64-bit big endian and "ppc64le" for 64-bit
little endian.
> +# ifdef CONFIG_COMPAT
> +# define SECCOMP_ARCH_COMPAT (AUDIT_ARCH_PPC | __SECCOMP_ARCH_LE)
> +# define SECCOMP_ARCH_COMPAT_NR NR_syscalls
> +# define SECCOMP_ARCH_COMPAT_NAME "powerpc"
And usually we use "ppc" for 32-bit.
> +# endif
> +#else /* !CONFIG_PPC64 */
> +# define SECCOMP_ARCH_NATIVE (AUDIT_ARCH_PPC | __SECCOMP_ARCH_LE)
> +# define SECCOMP_ARCH_NATIVE_NR NR_syscalls
> +# define SECCOMP_ARCH_NATIVE_NAME "powerpc"
> +#endif
> +
> #endif /* _ASM_POWERPC_SECCOMP_H */
> --
> 2.29.2
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Don't use asm goto for put_user() with GCC 4.9
From: Michael Ellerman @ 2020-11-04 11:04 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev; +Cc: schwab
In-Reply-To: <4fe837f8-ecae-f009-c193-8da386a70705@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 03/11/2020 à 14:29, Michael Ellerman a écrit :
>> Andreas reported that commit ee0a49a6870e ("powerpc/uaccess: Switch
>> __put_user_size_allowed() to __put_user_asm_goto()") broke
>> CLONE_CHILD_SETTID.
>>
>> Further inspection showed that the put_user() in schedule_tail() was
>> missing entirely, the store not emitted by the compiler.
>>
>> Notice there are no stores other than to the stack. There should be a
>> stw in there for the store to current->set_child_tid.
>>
>> This is only seen with GCC 4.9 era compilers (tested with 4.9.3 and
>> 4.9.4), and only when CONFIG_PPC_KUAP is disabled.
>>
>> When CONFIG_PPC_KUAP=y, the memory clobber that's part of the isync()
>> and mtspr() inlined via allow_user_access() seems to be enough to
>> avoid the bug.
>>
>> For now though let's just not use asm goto with GCC 4.9, to avoid this
>> bug and any other issues we haven't noticed yet. Possibly in future we
>> can find a smaller workaround.
>
> Is that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670 ?
>
> Should we use asm_volatile_goto() defined in include/linux/compiler-gcc.h ?
Ugh. I knew of that work around, but thought we'd dropped it when we
moved up to GCC 4.9. I should have looked more closely.
I'll send a patch to switch to it.
cheers
^ permalink raw reply
* [PATCH] powerpc: Use asm_goto_volatile for put_user()
From: Michael Ellerman @ 2020-11-04 11:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: schwab
Andreas reported that commit ee0a49a6870e ("powerpc/uaccess: Switch
__put_user_size_allowed() to __put_user_asm_goto()") broke
CLONE_CHILD_SETTID.
Further inspection showed that the put_user() in schedule_tail() was
missing entirely, the store not emitted by the compiler.
<.schedule_tail>:
mflr r0
std r0,16(r1)
stdu r1,-112(r1)
bl <.finish_task_switch>
ld r9,2496(r3)
cmpdi cr7,r9,0
bne cr7,<.schedule_tail+0x60>
ld r3,392(r13)
ld r9,1392(r3)
cmpdi cr7,r9,0
beq cr7,<.schedule_tail+0x3c>
li r4,0
li r5,0
bl <.__task_pid_nr_ns>
nop
bl <.calculate_sigpending>
nop
addi r1,r1,112
ld r0,16(r1)
mtlr r0
blr
nop
nop
nop
bl <.__balance_callback>
b <.schedule_tail+0x1c>
Notice there are no stores other than to the stack. There should be a
stw in there for the store to current->set_child_tid.
This is only seen with GCC 4.9 era compilers (tested with 4.9.3 and
4.9.4), and only when CONFIG_PPC_KUAP is disabled.
When CONFIG_PPC_KUAP=y, the inline asm that's part of the isync()
and mtspr() inlined via allow_user_access() seems to be enough to
avoid the bug.
We already have a macro to work around this (or a similar bug), called
asm_volatile_goto which includes an empty asm block to tickle the
compiler into generating the right code. So use that.
With this applied the code generation looks more like it will work:
<.schedule_tail>:
mflr r0
std r31,-8(r1)
std r0,16(r1)
stdu r1,-144(r1)
std r3,112(r1)
bl <._mcount>
nop
ld r3,112(r1)
bl <.finish_task_switch>
ld r9,2624(r3)
cmpdi cr7,r9,0
bne cr7,<.schedule_tail+0xa0>
ld r3,2408(r13)
ld r31,1856(r3)
cmpdi cr7,r31,0
beq cr7,<.schedule_tail+0x80>
li r4,0
li r5,0
bl <.__task_pid_nr_ns>
nop
li r9,-1
clrldi r9,r9,12
cmpld cr7,r31,r9
bgt cr7,<.schedule_tail+0x80>
lis r9,16
rldicr r9,r9,32,31
subf r9,r31,r9
cmpldi cr7,r9,3
ble cr7,<.schedule_tail+0x80>
li r9,0
stw r3,0(r31) <-- stw
nop
bl <.calculate_sigpending>
nop
addi r1,r1,144
ld r0,16(r1)
ld r31,-8(r1)
mtlr r0
blr
nop
bl <.__balance_callback>
b <.schedule_tail+0x30>
Fixes: ee0a49a6870e ("powerpc/uaccess: Switch __put_user_size_allowed() to __put_user_asm_goto()")
Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Suggested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/uaccess.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
index ef5bbb705c08..501c9a79038c 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -178,7 +178,7 @@ do { \
* are no aliasing issues.
*/
#define __put_user_asm_goto(x, addr, label, op) \
- asm volatile goto( \
+ asm_volatile_goto( \
"1: " op "%U1%X1 %0,%1 # put_user\n" \
EX_TABLE(1b, %l2) \
: \
@@ -191,7 +191,7 @@ do { \
__put_user_asm_goto(x, ptr, label, "std")
#else /* __powerpc64__ */
#define __put_user_asm2_goto(x, addr, label) \
- asm volatile goto( \
+ asm_volatile_goto( \
"1: stw%X1 %0, %1\n" \
"2: stw%X1 %L0, %L1\n" \
EX_TABLE(1b, %l2) \
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] powerpc: Use asm_goto_volatile for put_user()
From: Andreas Schwab @ 2020-11-04 11:20 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <20201104111742.672142-1-mpe@ellerman.id.au>
With that patch the kernel is working again.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] powerpc/smp: Move rcu_cpu_starting() earlier
From: Michael Ellerman @ 2020-11-04 11:38 UTC (permalink / raw)
To: Paul E . McKenney, Qian Cai
Cc: Peter Zijlstra, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20201028182334.13466-1-cai@redhat.com>
On Wed, 28 Oct 2020 14:23:34 -0400, Qian Cai wrote:
> The call to rcu_cpu_starting() in start_secondary() is not early enough
> in the CPU-hotplug onlining process, which results in lockdep splats as
> follows:
>
> WARNING: suspicious RCU usage
> -----------------------------
> kernel/locking/lockdep.c:3497 RCU-list traversed in non-reader section!!
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/smp: Call rcu_cpu_starting() earlier
https://git.kernel.org/powerpc/c/99f070b62322a4b8c1252952735806d09eb44b68
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/eeh_cache: Fix a possible debugfs deadlock
From: Michael Ellerman @ 2020-11-04 11:38 UTC (permalink / raw)
To: Michael Ellerman, Qian Cai
Cc: linuxppc-dev, Oliver O'Halloran, linux-kernel, Paul Mackerras
In-Reply-To: <20201028152717.8967-1-cai@redhat.com>
On Wed, 28 Oct 2020 11:27:17 -0400, Qian Cai wrote:
> Lockdep complains that a possible deadlock below in
> eeh_addr_cache_show() because it is acquiring a lock with IRQ enabled,
> but eeh_addr_cache_insert_dev() needs to acquire the same lock with IRQ
> disabled. Let's just make eeh_addr_cache_show() acquire the lock with
> IRQ disabled as well.
>
> CPU0 CPU1
> ---- ----
> lock(&pci_io_addr_cache_root.piar_lock);
> local_irq_disable();
> lock(&tp->lock);
> lock(&pci_io_addr_cache_root.piar_lock);
> <Interrupt>
> lock(&tp->lock);
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/eeh_cache: Fix a possible debugfs deadlock
https://git.kernel.org/powerpc/c/fd552e0542b4532483289cce48fdbd27b692984b
cheers
^ permalink raw reply
* Re: [PATCH v1 3/4] powerpc/mm: remove linear mapping if __add_pages() fails in arch_add_memory()
From: Mike Rapoport @ 2020-11-04 12:06 UTC (permalink / raw)
To: osalvador
Cc: Michal Hocko, Wei Yang, David Hildenbrand, linux-kernel, linux-mm,
Paul Mackerras, Rashmica Gupta, linuxppc-dev, Andrew Morton
In-Reply-To: <20201104095007.GB4981@localhost.localdomain>
On Wed, Nov 04, 2020 at 10:50:07AM +0100, osalvador wrote:
> On Thu, Oct 29, 2020 at 05:27:17PM +0100, David Hildenbrand wrote:
> > Let's revert what we did in case seomthing goes wrong and we return an
> > error.
>
> Dumb question, but should not we do this for other arches as well?
It seems arm64 and s390 already do that.
x86 could have its arch_add_memory() improved though :)
> --
> Oscar Salvador
> SUSE L3
--
Sincerely yours,
Mike.
^ permalink raw reply
* [PATCH] powerpc: Use the common INIT_DATA_SECTION macro in vmlinux.lds.S
From: Youling Tang @ 2020-11-04 10:59 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
Use the common INIT_DATA_SECTION rule for the linker script in an effort
to regularize the linker script.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
---
arch/powerpc/kernel/vmlinux.lds.S | 19 +------------------
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index e0548b4..5dc05f3 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -186,21 +186,7 @@ SECTIONS
EXIT_TEXT
}
- .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
- INIT_DATA
- }
-
- .init.setup : AT(ADDR(.init.setup) - LOAD_OFFSET) {
- INIT_SETUP(16)
- }
-
- .initcall.init : AT(ADDR(.initcall.init) - LOAD_OFFSET) {
- INIT_CALLS
- }
-
- .con_initcall.init : AT(ADDR(.con_initcall.init) - LOAD_OFFSET) {
- CON_INITCALL
- }
+ INIT_DATA_SECTION(16)
. = ALIGN(8);
__ftr_fixup : AT(ADDR(__ftr_fixup) - LOAD_OFFSET) {
@@ -228,9 +214,6 @@ SECTIONS
__stop___fw_ftr_fixup = .;
}
#endif
- .init.ramfs : AT(ADDR(.init.ramfs) - LOAD_OFFSET) {
- INIT_RAM_FS
- }
PERCPU_SECTION(L1_CACHE_BYTES)
--
2.1.0
^ permalink raw reply related
* Re: [PATCH seccomp 3/8] powerpc: Enable seccomp architecture tracking
From: YiFei Zhu @ 2020-11-04 11:48 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-sh, Tobin Feldman-Fitzthum, Hubertus Franke, Jack Chen,
linux-riscv, Andrea Arcangeli, linux-s390, YiFei Zhu, linux-csky,
Tianyin Xu, linux-xtensa, Kees Cook, Jann Horn, Valentin Rothberg,
Aleksa Sarai, Josep Torrellas, Will Drewry, linux-parisc,
Linux Containers, kernel list, Andy Lutomirski,
Dimitrios Skarlatos, David Laight, Giuseppe Scrivano,
linuxppc-dev, Tycho Andersen
In-Reply-To: <87wnz1to9n.fsf@mpe.ellerman.id.au>
On Wed, Nov 4, 2020 at 4:22 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
> > +#ifdef __LITTLE_ENDIAN__
>
> As Kees mentioned this should (must?!) match the configured endian.
>
> But I think it would still be better to use the CONFIG symbol, which is
> CONFIG_CPU_LITTLE_ENDIAN.
My attempt here is to be consistent with asm/syscall.h
syscall_get_arch [1]. Would it make sense to change that to
CONFIG_CPU_LITTLE_ENDIAN then?
[1] https://elixir.bootlin.com/linux/latest/source/arch/powerpc/include/asm/syscall.h#L116
> > +# define SECCOMP_ARCH_NATIVE (AUDIT_ARCH_PPC64 | __SECCOMP_ARCH_LE)
>
> You use __SECCOMP_ARCH_LE there, but previously you only defined
> __SECCOMP_ARCH_LE_BIT.
>
> Is there some magic somewhere that defines __SECCOMP_ARCH_LE based on
> __SECCOMP_ARCH_LE_BIT ?
Oops, my bad here.
> > +# define SECCOMP_ARCH_NATIVE_NR NR_syscalls
> > +# define SECCOMP_ARCH_NATIVE_NAME "ppc64"
>
> What's the name used for?
This is used in the last patch in this series to report in procfs the
name of each architecture tracked by the bitmap cache.
> Usually we use "ppc64" for 64-bit big endian and "ppc64le" for 64-bit
> little endian.
>
> And usually we use "ppc" for 32-bit.
Ok.
YiFei Zhu
^ permalink raw reply
* Re: [PATCH v1 3/4] powerpc/mm: remove linear mapping if __add_pages() fails in arch_add_memory()
From: Oscar Salvador @ 2020-11-04 12:11 UTC (permalink / raw)
To: Mike Rapoport
Cc: Michal Hocko, Wei Yang, David Hildenbrand, linux-kernel, linux-mm,
Paul Mackerras, Rashmica Gupta, linuxppc-dev, Andrew Morton
In-Reply-To: <20201104120651.GQ4879@kernel.org>
On Wed, Nov 04, 2020 at 02:06:51PM +0200, Mike Rapoport wrote:
> On Wed, Nov 04, 2020 at 10:50:07AM +0100, osalvador wrote:
> > On Thu, Oct 29, 2020 at 05:27:17PM +0100, David Hildenbrand wrote:
> > > Let's revert what we did in case seomthing goes wrong and we return an
> > > error.
> >
> > Dumb question, but should not we do this for other arches as well?
>
> It seems arm64 and s390 already do that.
> x86 could have its arch_add_memory() improved though :)
Right, I only stared at x86 and see it did not have it.
I guess we want to have all arches aligned with this.
Thanks
--
Oscar Salvador
SUSE L3
^ permalink raw reply
* Re: [PATCH v1 3/4] powerpc/mm: remove linear mapping if __add_pages() fails in arch_add_memory()
From: Oscar Salvador @ 2020-11-04 12:11 UTC (permalink / raw)
To: David Hildenbrand
Cc: Michal Hocko, Wei Yang, linux-kernel, linux-mm, Paul Mackerras,
Rashmica Gupta, linuxppc-dev, Andrew Morton, Mike Rapoport
In-Reply-To: <20201029162718.29910-4-david@redhat.com>
On Thu, Oct 29, 2020 at 05:27:17PM +0100, David Hildenbrand wrote:
> Let's revert what we did in case seomthing goes wrong and we return an
> error.
>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Rashmica Gupta <rashmica.g@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: Wei Yang <richard.weiyang@linux.alibaba.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
> ---
> arch/powerpc/mm/mem.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 685028451dd2..69b3e8072261 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -165,7 +165,10 @@ int __ref arch_add_memory(int nid, u64 start, u64 size,
> rc = arch_create_linear_mapping(nid, start, size, params);
> if (rc)
> return rc;
> - return __add_pages(nid, start_pfn, nr_pages, params);
> + rc = __add_pages(nid, start_pfn, nr_pages, params);
> + if (rc)
> + arch_remove_linear_mapping(start, size);
> + return rc;
> }
>
> void __ref arch_remove_memory(int nid, u64 start, u64 size,
> --
> 2.26.2
>
--
Oscar Salvador
SUSE L3
^ permalink raw reply
* Re: [PATCH 09/12] net: ethernet: ibm: ibmvnic: Fix some kernel-doc misdemeanours
From: Andrew Lunn @ 2020-11-04 13:38 UTC (permalink / raw)
To: Lee Jones
Cc: Thomas Falcon, linux-kernel, Santiago Leon, John Allen, Lijun Pan,
linux-arm-kernel, netdev, Dany Madden, kuba, Sukadev Bhattiprolu,
linuxppc-dev, davem, Paul Mackerras
In-Reply-To: <20201104090610.1446616-10-lee.jones@linaro.org>
On Wed, Nov 04, 2020 at 09:06:07AM +0000, Lee Jones wrote:
> 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>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 10/12] net: ethernet: toshiba: ps3_gelic_net: Fix some kernel-doc misdemeanours
From: Andrew Lunn @ 2020-11-04 13:41 UTC (permalink / raw)
To: Lee Jones
Cc: Geoff Levand, linux-kernel, netdev, Paul Mackerras, Utz Bacher,
Jens Osterkamp, kuba, linuxppc-dev, davem, linux-arm-kernel
In-Reply-To: <20201104090610.1446616-11-lee.jones@linaro.org>
On Wed, Nov 04, 2020 at 09:06:08AM +0000, Lee Jones wrote:
> 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
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [Bug 209869] Kernel 5.10-rc1 fails to boot on a PowerMac G4 3,6 at an early stage
From: bugzilla-daemon @ 2020-11-04 14:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-209869-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=209869
--- Comment #3 from Christophe Leroy (christophe.leroy@csgroup.eu) ---
Ok, thanks for the verification. I'm still having hard time understand what the
problem can be. That commit sets up at all time the early hash table that was
previously only set up when CONFIG_KASAN was set. As far as I remember, you
tried KASAN many times.
Could you test whether CONFIG_KASAN works:
- on 5.10-rc1 with that commit reverted ?
- on 5.9 ?
If CONFIG_KASAN is already broken on 5.9, are you able to find the last kernel
version on which CONFIG_KASAN works ?
Thanks
Christophe
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH] powerpc/32s: Setup the early hash table at all time.
From: Serge Belyshev @ 2020-11-04 14:53 UTC (permalink / raw)
To: Christophe Leroy
Cc: Paul Mackerras, Andreas Schwab, linuxppc-dev, linux-kernel
In-Reply-To: <87wnz1lbce.fsf@depni.sinp.msu.ru>
>>> To be sure we are not in front of a long lasting bug, could you try
>>> CONFIG_KASAN=y on v5.9 ?
>>
>> Indeed it started to fail somewhere between v5.6 and v5.7.
>>
>> v5.7 fails early with few messages on the console with reboot, v5.8 and
>> later hang right at bootloader.
>>
>> I'm bisecting now.
>
> (side note: I tried FB_OF=y instead of DRM_RADEON + DRM_FBDEV_* to speed
> up bisection and it turns out in that configuration KASAN never worked,
> down to commit 305d600123046, hanging right after bootloader or even
> with invalid access in the bootloader itself).
My bisection ended up nowhere (at net-next merge with 2k commits), and
given the above failure with unrelated configuration change, I conclude
that KASAN=y was always broken on this box.
^ permalink raw reply
* Kernel 5.10-rc1 not mounting NAND flash (Bisected to d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits"))
From: Christophe Leroy @ 2020-11-04 17:33 UTC (permalink / raw)
To: Miquel Raynal; +Cc: linux-mtd, linuxppc-dev, linux-kernel
Hi Miquel,
I'm unable to boot 5.10-rc1 on my boards. I get the following error:
[ 4.125811] nand: device found, Manufacturer ID: 0xad, Chip ID: 0x76
[ 4.131992] nand: Hynix NAND 64MiB 3,3V 8-bit
[ 4.136173] nand: 64 MiB, SLC, erase size: 16 KiB, page size: 512,
OOB size: 16
[ 4.143534] ------------[ cut here ]------------
[ 4.147934] Unsupported ECC algorithm!
[ 4.152142] WARNING: CPU: 0 PID: 1 at
drivers/mtd/nand/raw/nand_base.c:5244 nand_scan_with_ids+0x1260/0x1640
...
[ 4.332052] ---[ end trace e3a36f62cae4ac56 ]---
[ 4.336882] gpio-nand: probe of c0000000.nand failed with error -22
Bisected to commit d7157ff49a5b ("mtd: rawnand: Use the ECC framework
user input parsing bits")
My first impression is that with that change, the value set in chip->ecc.algo
by gpio_nand_probe() in drivers/mtd/nand/raw/gpio.c gets overwritten
in rawnand_dt_init()
The following change fixes the problem, though I'm not sure it is the
right fix. Can you have a look ?
diff --git a/drivers/mtd/nand/raw/nand_base.c
b/drivers/mtd/nand/raw/nand_base.c
index 1f0d542d5923..aa74797cf2da 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5032,7 +5032,8 @@ static int rawnand_dt_init(struct nand_chip *chip)
chip->ecc.engine_type = nand->ecc.defaults.engine_type;
chip->ecc.placement = nand->ecc.user_conf.placement;
- chip->ecc.algo = nand->ecc.user_conf.algo;
+ if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN)
+ chip->ecc.algo = nand->ecc.user_conf.algo;
chip->ecc.strength = nand->ecc.user_conf.strength;
chip->ecc.size = nand->ecc.user_conf.step_size;
---
Thanks
Christophe
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox