* [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
* Re: [PATCH v4 1/4] mm: introduce debug_pagealloc_map_pages() helper
From: Vlastimil Babka @ 2020-11-04 17:35 UTC (permalink / raw)
To: Mike Rapoport, Andrew Morton
Cc: David Hildenbrand, Peter Zijlstra, Dave Hansen, linux-mm,
Paul Mackerras, Pavel Machek, H. Peter Anvin, sparclinux,
Christoph Lameter, Will Deacon, linux-riscv, linux-s390, x86,
Mike Rapoport, Christian Borntraeger, Ingo Molnar,
Catalin Marinas, Len Brown, Albert Ou, Vasily Gorbik, linux-pm,
Heiko Carstens, David Rientjes, Borislav Petkov, Andy Lutomirski,
Paul Walmsley, Kirill A. Shutemov, Thomas Gleixner,
linux-arm-kernel, Rafael J. Wysocki, linux-kernel, Pekka Enberg,
Palmer Dabbelt, Joonsoo Kim, Edgecombe, Rick P, linuxppc-dev,
David S. Miller, Kirill A . Shutemov
In-Reply-To: <20201103162057.22916-2-rppt@kernel.org>
On 11/3/20 5:20 PM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> When CONFIG_DEBUG_PAGEALLOC is enabled, it unmaps pages from the kernel
> direct mapping after free_pages(). The pages than need to be mapped back
> before they could be used. Theese mapping operations use
> __kernel_map_pages() guarded with with debug_pagealloc_enabled().
>
> The only place that calls __kernel_map_pages() without checking whether
> DEBUG_PAGEALLOC is enabled is the hibernation code that presumes
> availability of this function when ARCH_HAS_SET_DIRECT_MAP is set.
> Still, on arm64, __kernel_map_pages() will bail out when DEBUG_PAGEALLOC is
> not enabled but set_direct_map_invalid_noflush() may render some pages not
> present in the direct map and hibernation code won't be able to save such
> pages.
>
> To make page allocation debugging and hibernation interaction more robust,
> the dependency on DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP has to be made
> more explicit.
>
> Start with combining the guard condition and the call to
> __kernel_map_pages() into a single debug_pagealloc_map_pages() function to
> emphasize that __kernel_map_pages() should not be called without
> DEBUG_PAGEALLOC and use this new function to map/unmap pages when page
> allocation debug is enabled.
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> Reviewed-by: David Hildenbrand <david@redhat.com>
> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
But, the "enable" param is hideous. I would rather have map and unmap variants
(and just did the same split for page poisoning) and this seems to be a good
opportunity. If David didn't propose it already, I'm surprised ;)
> ---
> include/linux/mm.h | 10 ++++++++++
> mm/memory_hotplug.c | 3 +--
> mm/page_alloc.c | 6 ++----
> mm/slab.c | 8 +++-----
> 4 files changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index ef360fe70aaf..1fc0609056dc 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2936,12 +2936,22 @@ kernel_map_pages(struct page *page, int numpages, int enable)
> {
> __kernel_map_pages(page, numpages, enable);
> }
> +
> +static inline void debug_pagealloc_map_pages(struct page *page,
> + int numpages, int enable)
> +{
> + if (debug_pagealloc_enabled_static())
> + __kernel_map_pages(page, numpages, enable);
> +}
> +
> #ifdef CONFIG_HIBERNATION
> extern bool kernel_page_present(struct page *page);
> #endif /* CONFIG_HIBERNATION */
> #else /* CONFIG_DEBUG_PAGEALLOC || CONFIG_ARCH_HAS_SET_DIRECT_MAP */
> static inline void
> kernel_map_pages(struct page *page, int numpages, int enable) {}
> +static inline void debug_pagealloc_map_pages(struct page *page,
> + int numpages, int enable) {}
> #ifdef CONFIG_HIBERNATION
> static inline bool kernel_page_present(struct page *page) { return true; }
> #endif /* CONFIG_HIBERNATION */
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index b44d4c7ba73b..e2b6043a4428 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -614,8 +614,7 @@ void generic_online_page(struct page *page, unsigned int order)
> * so we should map it first. This is better than introducing a special
> * case in page freeing fast path.
> */
> - if (debug_pagealloc_enabled_static())
> - kernel_map_pages(page, 1 << order, 1);
> + debug_pagealloc_map_pages(page, 1 << order, 1);
> __free_pages_core(page, order);
> totalram_pages_add(1UL << order);
> #ifdef CONFIG_HIGHMEM
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 23f5066bd4a5..9a66a1ff9193 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1272,8 +1272,7 @@ static __always_inline bool free_pages_prepare(struct page *page,
> */
> arch_free_page(page, order);
>
> - if (debug_pagealloc_enabled_static())
> - kernel_map_pages(page, 1 << order, 0);
> + debug_pagealloc_map_pages(page, 1 << order, 0);
>
> kasan_free_nondeferred_pages(page, order);
>
> @@ -2270,8 +2269,7 @@ inline void post_alloc_hook(struct page *page, unsigned int order,
> set_page_refcounted(page);
>
> arch_alloc_page(page, order);
> - if (debug_pagealloc_enabled_static())
> - kernel_map_pages(page, 1 << order, 1);
> + debug_pagealloc_map_pages(page, 1 << order, 1);
> kasan_alloc_pages(page, order);
> kernel_poison_pages(page, 1 << order, 1);
> set_page_owner(page, order, gfp_flags);
> diff --git a/mm/slab.c b/mm/slab.c
> index b1113561b98b..340db0ce74c4 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -1431,10 +1431,8 @@ static bool is_debug_pagealloc_cache(struct kmem_cache *cachep)
> #ifdef CONFIG_DEBUG_PAGEALLOC
> static void slab_kernel_map(struct kmem_cache *cachep, void *objp, int map)
> {
> - if (!is_debug_pagealloc_cache(cachep))
> - return;
> -
> - kernel_map_pages(virt_to_page(objp), cachep->size / PAGE_SIZE, map);
> + debug_pagealloc_map_pages(virt_to_page(objp),
> + cachep->size / PAGE_SIZE, map);
> }
>
> #else
> @@ -2062,7 +2060,7 @@ int __kmem_cache_create(struct kmem_cache *cachep, slab_flags_t flags)
>
> #if DEBUG
> /*
> - * If we're going to use the generic kernel_map_pages()
> + * If we're going to use the generic debug_pagealloc_map_pages()
> * poisoning, then it's going to smash the contents of
> * the redzone and userword anyhow, so switch them off.
> */
>
^ permalink raw reply
* Re: [PATCH v4 2/4] PM: hibernate: make direct map manipulations more explicit
From: Vlastimil Babka @ 2020-11-04 17:40 UTC (permalink / raw)
To: Mike Rapoport, Andrew Morton
Cc: Rafael J . Wysocki, David Hildenbrand, Peter Zijlstra,
Dave Hansen, linux-mm, Paul Mackerras, Pavel Machek,
H. Peter Anvin, sparclinux, Christoph Lameter, Will Deacon,
linux-riscv, linux-s390, x86, Mike Rapoport,
Christian Borntraeger, Ingo Molnar, Catalin Marinas, Len Brown,
Albert Ou, Vasily Gorbik, linux-pm, Heiko Carstens,
David Rientjes, Borislav Petkov, Andy Lutomirski, Paul Walmsley,
Kirill A. Shutemov, Thomas Gleixner, linux-arm-kernel,
Rafael J. Wysocki, linux-kernel, Pekka Enberg, Palmer Dabbelt,
Joonsoo Kim, Edgecombe, Rick P, linuxppc-dev, David S. Miller,
Kirill A . Shutemov
In-Reply-To: <20201103162057.22916-3-rppt@kernel.org>
On 11/3/20 5:20 PM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a page may be
> not present in the direct map and has to be explicitly mapped before it
> could be copied.
>
> Introduce hibernate_map_page() that will explicitly use
> set_direct_map_{default,invalid}_noflush() for ARCH_HAS_SET_DIRECT_MAP case
> and debug_pagealloc_map_pages() for DEBUG_PAGEALLOC case.
>
> The remapping of the pages in safe_copy_page() presumes that it only
> changes protection bits in an existing PTE and so it is safe to ignore
> return value of set_direct_map_{default,invalid}_noflush().
>
> Still, add a pr_warn() so that future changes in set_memory APIs will not
> silently break hibernation.
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Reviewed-by: David Hildenbrand <david@redhat.com>
> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
The bool param is a bit more acceptable here, being a private API. But if
debug_pagealloc_map_pages() becomes split, then it might be easier to split this
one too...
> ---
> include/linux/mm.h | 12 ------------
> kernel/power/snapshot.c | 32 ++++++++++++++++++++++++++++++--
> 2 files changed, 30 insertions(+), 14 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 1fc0609056dc..14e397f3752c 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2927,16 +2927,6 @@ static inline bool debug_pagealloc_enabled_static(void)
> #if defined(CONFIG_DEBUG_PAGEALLOC) || defined(CONFIG_ARCH_HAS_SET_DIRECT_MAP)
> extern void __kernel_map_pages(struct page *page, int numpages, int enable);
>
> -/*
> - * When called in DEBUG_PAGEALLOC context, the call should most likely be
> - * guarded by debug_pagealloc_enabled() or debug_pagealloc_enabled_static()
> - */
> -static inline void
> -kernel_map_pages(struct page *page, int numpages, int enable)
> -{
> - __kernel_map_pages(page, numpages, enable);
> -}
> -
> static inline void debug_pagealloc_map_pages(struct page *page,
> int numpages, int enable)
> {
> @@ -2948,8 +2938,6 @@ static inline void debug_pagealloc_map_pages(struct page *page,
> extern bool kernel_page_present(struct page *page);
> #endif /* CONFIG_HIBERNATION */
> #else /* CONFIG_DEBUG_PAGEALLOC || CONFIG_ARCH_HAS_SET_DIRECT_MAP */
> -static inline void
> -kernel_map_pages(struct page *page, int numpages, int enable) {}
> static inline void debug_pagealloc_map_pages(struct page *page,
> int numpages, int enable) {}
> #ifdef CONFIG_HIBERNATION
> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> index 46b1804c1ddf..57d54b9d84bb 100644
> --- a/kernel/power/snapshot.c
> +++ b/kernel/power/snapshot.c
> @@ -76,6 +76,34 @@ static inline void hibernate_restore_protect_page(void *page_address) {}
> static inline void hibernate_restore_unprotect_page(void *page_address) {}
> #endif /* CONFIG_STRICT_KERNEL_RWX && CONFIG_ARCH_HAS_SET_MEMORY */
>
> +static inline void hibernate_map_page(struct page *page, int enable)
> +{
> + if (IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP)) {
> + unsigned long addr = (unsigned long)page_address(page);
> + int ret;
> +
> + /*
> + * This should not fail because remapping a page here means
> + * that we only update protection bits in an existing PTE.
> + * It is still worth to have a warning here if something
> + * changes and this will no longer be the case.
> + */
> + if (enable)
> + ret = set_direct_map_default_noflush(page);
> + else
> + ret = set_direct_map_invalid_noflush(page);
> +
> + if (ret) {
> + pr_warn_once("Failed to remap page\n");
> + return;
> + }
> +
> + flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> + } else {
> + debug_pagealloc_map_pages(page, 1, enable);
> + }
> +}
> +
> static int swsusp_page_is_free(struct page *);
> static void swsusp_set_page_forbidden(struct page *);
> static void swsusp_unset_page_forbidden(struct page *);
> @@ -1355,9 +1383,9 @@ static void safe_copy_page(void *dst, struct page *s_page)
> if (kernel_page_present(s_page)) {
> do_copy_page(dst, page_address(s_page));
> } else {
> - kernel_map_pages(s_page, 1, 1);
> + hibernate_map_page(s_page, 1);
> do_copy_page(dst, page_address(s_page));
> - kernel_map_pages(s_page, 1, 0);
> + hibernate_map_page(s_page, 0);
> }
> }
>
>
^ 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