Re: [PATCH] kallsyms: Fix scheduling with interrupts disabled in self-test

2023-01-13 Thread Petr Mladek
On Thu 2023-01-12 10:24:43, Luis Chamberlain wrote: > On Thu, Jan 12, 2023 at 08:54:26PM +1000, Nicholas Piggin wrote: > > kallsyms_on_each* may schedule so must not be called with interrupts > > disabled. The iteration function could disable interrupts, but this > > also changes lookup_symbol() to

Re: lockref scalability on x86-64 vs cpu_relax

2023-01-13 Thread Will Deacon
On Fri, Jan 13, 2023 at 02:12:50AM +0100, Mateusz Guzik wrote: > On 1/13/23, Linus Torvalds wrote: > > Side note on your access() changes - if it turns out that you can > > remove all the cred games, we should possibly then revert my old > > commit d7852fbd0f04 ("access: avoid the RCU grace period

Re: lockref scalability on x86-64 vs cpu_relax

2023-01-13 Thread Peter Zijlstra
On Thu, Jan 12, 2023 at 06:13:16PM -0600, Linus Torvalds wrote: > On Thu, Jan 12, 2023 at 5:36 PM Mateusz Guzik wrote: > > > > To my understanding on said architecture failed cmpxchg still grants you > > exclusive access to the cacheline, making immediate retry preferable > > when trying to inc/de

[PATCH v3 00/10] Add the PowerQUICC audio support using the QMC

2023-01-13 Thread Herve Codina
Hi, This series adds support for audio using the QMC controller available in some Freescale PowerQUICC SoCs. This series contains three parts in order to show the different blocks hierarchy and their usage in this support. The first one is related to TSA (Time Slot Assigner). The TSA handles the

[PATCH v3 02/10] soc: fsl: cpm1: Add support for TSA

2023-01-13 Thread Herve Codina
The TSA (Time Slot Assigner) purpose is to route some TDM time-slots to other internal serial controllers. It is available in some PowerQUICC SoC such as the MPC885 or MPC866. It is also available on some Quicc Engine SoCs. This current version support CPM1 SoCs only and some enhancement are need

[PATCH v3 01/10] dt-bindings: soc: fsl: cpm_qe: Add TSA controller

2023-01-13 Thread Herve Codina
Add support for the time slot assigner (TSA) available in some PowerQUICC SoC such as MPC885 or MPC866. Signed-off-by: Herve Codina --- .../bindings/soc/fsl/cpm_qe/fsl,tsa.yaml | 260 ++ include/dt-bindings/soc/fsl,tsa.h | 13 + 2 files changed, 273 insertions(+

[PATCH v3 03/10] MAINTAINERS: add the Freescale TSA controller entry

2023-01-13 Thread Herve Codina
After contributing the driver, add myself as the maintainer for the Freescale TSA controller. Signed-off-by: Herve Codina --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7f86d02cb427..6a0605ebf8a0 100644 --- a/MAINTAINERS +++ b/MAINTAI

[PATCH v3 04/10] powerpc/8xx: Use a larger CPM1 command check mask

2023-01-13 Thread Herve Codina
The CPM1 command mask is defined for use with the standard CPM1 command register as described in the user's manual: 0 |13|47|8 11|12 14| 15| RST|- |OPCODE|CH_NUM| -|FLG| In the QMC extension the CPM1 command register is redefined (QMC supplement user's manue

[PATCH v3 05/10] dt-bindings: soc: fsl: cpm_qe: Add QMC controller

2023-01-13 Thread Herve Codina
Add support for the QMC (QUICC Multichannel Controller) available in some PowerQUICC SoC such as MPC885 or MPC866. Signed-off-by: Herve Codina --- .../bindings/soc/fsl/cpm_qe/fsl,qmc.yaml | 164 ++ 1 file changed, 164 insertions(+) create mode 100644 Documentation/devicetr

[PATCH v3 06/10] soc: fsl: cmp1: Add support for QMC

2023-01-13 Thread Herve Codina
The QMC (QUICC Multichannel Controller) emulates up to 64 channels within one serial controller using the same TDM physical interface routed from the TSA. It is available in some PowerQUICC SoC such as the MPC885 or MPC866. It is also available on some Quicc Engine SoCs. This current version supp

[PATCH v3 07/10] MAINTAINERS: add the Freescale QMC controller entry

2023-01-13 Thread Herve Codina
After contributing the driver, add myself as the maintainer for the Freescale QMC controller. Signed-off-by: Herve Codina --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6a0605ebf8a0..9a574892b9b1 100644 --- a/MAINTAINERS +++ b/MAINTAIN

[PATCH v3 08/10] dt-bindings: sound: Add support for QMC audio

2023-01-13 Thread Herve Codina
The QMC (QUICC mutichannel controller) is a controller present in some PowerQUICC SoC such as MPC885. The QMC audio is an ASoC component that uses the QMC controller to transfer the audio data. Signed-off-by: Herve Codina --- .../bindings/sound/fsl,qmc-audio.yaml | 117 ++

[PATCH v3 09/10] ASoC: fsl: Add support for QMC audio

2023-01-13 Thread Herve Codina
The QMC audio is an ASoC component which provides DAIs that use the QMC (QUICC Multichannel Controller) to transfer the audio data. It provides as many DAIs as the number of QMC channels it references. Signed-off-by: Herve Codina --- sound/soc/fsl/Kconfig | 9 + sound/soc/fsl/Makefile

[PATCH v3 10/10] MAINTAINERS: add the Freescale QMC audio entry

2023-01-13 Thread Herve Codina
After contributing the component, add myself as the maintainer for the Freescale QMC audio ASoC component. Signed-off-by: Herve Codina --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9a574892b9b1..9dcfadec5aa3 100644 --- a/MAINTAINERS +

Re: [PATCH v3 11/13] tty/serial: Call ->dtr_rts() parameter active consistently

2023-01-13 Thread Ulf Hansson
On Wed, 11 Jan 2023 at 15:24, Ilpo Järvinen wrote: > > Convert various parameter names for ->dtr_rts() and related functions > from onoff, on, and raise to active. > > Reviewed-by: Jiri Slaby > Signed-off-by: Ilpo Järvinen Acked-by: Ulf Hansson # For MMC Kind regards Uffe > --- > drivers/ch

Re: [PATCH v3 07/13] tty: Convert ->dtr_rts() to take bool argument

2023-01-13 Thread Ulf Hansson
On Wed, 11 Jan 2023 at 15:24, Ilpo Järvinen wrote: > > Convert the raise/on parameter in ->dtr_rts() to bool through the > callchain. The parameter is used like bool. In USB serial, there > remains a few implicit bool -> larger type conversions because some > devices use u8 in their control messag

RE: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)

2023-01-13 Thread Luck, Tony
>> Is it time yet for: >> >> $ git rm -r arch/ia64 >> > Can I take that as an ack on [0]? The EFI subsystem has evolved > substantially over the years, and there is really no way to do any > IA64 testing beyond build testing, so from that perspective, dropping > it entirely would be welcomed. > >

[PATCH mm-unstable v1 01/26] mm/debug_vm_pgtable: more pte_swp_exclusive() sanity checks

2023-01-13 Thread David Hildenbrand
We want to implement __HAVE_ARCH_PTE_SWP_EXCLUSIVE on all architectures. Let's extend our sanity checks, especially testing that our PTE bit does not affect: * is_swap_pte() -> pte_present() and pte_none() * the swap entry + type * pte_swp_soft_dirty() Especially, the pfn_pte() is dodgy when the s

[PATCH mm-unstable v1 02/26] alpha/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the type. Generic MM currently only uses 5 bits for the type (MAX_SWAPFILES_SHIFT), so the stolen bit is effectively unused. While at it, mask the type in mk_swap_pte() as well. Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: Ma

[PATCH mm-unstable v1 03/26] arc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by using bit 5, which is yet unused. The only important parts seems to be to not use _PAGE_PRESENT (bit 9). Cc: Vineet Gupta Signed-off-by: David Hildenbrand --- arch/arc/include/asm/pgtable-bits-arcv2.h | 27 --- 1 file changed, 2

[PATCH mm-unstable v1 04/26] arm/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the offset. This reduces the maximum swap space per file to 64 GiB (was 128 GiB). While at it drop the PTE_TYPE_FAULT from __swp_entry_to_pte() which is defined to be 0 and is rather confusing because we should be dealing with "L

[PATCH mm-unstable v1 05/26] csky/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the offset. This reduces the maximum swap space per file to 16 GiB (was 32 GiB). We might actually be able to reuse one of the other software bits (_PAGE_READ / PAGE_WRITE) instead, because we only have to keep pte_present(), pte

[PATCH mm-unstable v1 06/26] hexagon/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the offset. This reduces the maximum swap space per file to 16 GiB (was 32 GiB). While at it, mask the type in __swp_entry(). Cc: Brian Cain Signed-off-by: David Hildenbrand --- arch/hexagon/include/asm/pgtable.h | 37 +++

[PATCH mm-unstable v1 07/26] ia64/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the type. Generic MM currently only uses 5 bits for the type (MAX_SWAPFILES_SHIFT), so the stolen bit is effectively unused. While at it, also mask the type in __swp_entry(). Signed-off-by: David Hildenbrand --- arch/ia64/incl

[PATCH mm-unstable v1 08/26] loongarch/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the type. Generic MM currently only uses 5 bits for the type (MAX_SWAPFILES_SHIFT), so the stolen bit is effectively unused. While at it, also mask the type in mk_swap_pte(). Note that this bit does not conflict with swap PMDs a

[PATCH mm-unstable v1 09/26] m68k/mm: remove dummy __swp definitions for nommu

2023-01-13 Thread David Hildenbrand
The definitions are not required, let's remove them. Cc: Geert Uytterhoeven Cc: Greg Ungerer Signed-off-by: David Hildenbrand --- arch/m68k/include/asm/pgtable_no.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/arch/m68k/include/asm/pgtable_no.h b/arch/m68k/include/asm/pgtable_no.h

[PATCH mm-unstable v1 10/26] m68k/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the type. Generic MM currently only uses 5 bits for the type (MAX_SWAPFILES_SHIFT), so the stolen bit is effectively unused. While at it, make sure for sun3 that the valid bit never gets set by properly masking it off and mask th

[PATCH mm-unstable v1 11/26] microblaze/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the type. Generic MM currently only uses 5 bits for the type (MAX_SWAPFILES_SHIFT), so the stolen bit is effectively unused. The shift by 2 when converting between PTE and arch-specific swap entry makes the swap PTE layout a litt

[PATCH mm-unstable v1 12/26] mips/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE. On 64bit, steal one bit from the type. Generic MM currently only uses 5 bits for the type (MAX_SWAPFILES_SHIFT), so the stolen bit is effectively unused. On 32bit we're able to locate unused bits. As the PTE layout for 32 bit is very confusing, documen

[PATCH mm-unstable v1 13/26] nios2/mm: refactor swap PTE layout

2023-01-13 Thread David Hildenbrand
nios2 disables swap for a good reason: it doesn't even provide sufficient type bits as required by core MM. However, swap entries are nowadays also used for other purposes (migration entries, PTE markers, HWPoison, ...), and accidential use could be problematic. Let's properly use 5 bits for the s

[PATCH mm-unstable v1 14/26] nios2/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by using the yet-unused bit 31. Cc: Thomas Bogendoerfer Signed-off-by: David Hildenbrand --- arch/nios2/include/asm/pgtable-bits.h | 3 +++ arch/nios2/include/asm/pgtable.h | 22 +- 2 files changed, 24 insertions(+), 1 deleti

[PATCH mm-unstable v1 15/26] openrisc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the type. Generic MM currently only uses 5 bits for the type (MAX_SWAPFILES_SHIFT), so the stolen bit is effectively unused. While at it, mask the type in __swp_entry(). Cc: Stefan Kristiansson Cc: Stafford Horne Signed-off-by

[PATCH mm-unstable v1 16/26] parisc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by using the yet-unused _PAGE_ACCESSED location in the swap PTE. Looking at pte_present() and pte_none() checks, there seems to be no actual reason why we cannot use it: we only have to make sure we're not using _PAGE_PRESENT. Reusing this bit avoids hav

[PATCH mm-unstable v1 17/26] powerpc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE on 32bit book3s

2023-01-13 Thread David Hildenbrand
We already implemented support for 64bit book3s in commit bff9beaa2e80 ("powerpc/pgtable: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE for book3s") Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE also in 32bit by reusing yet unused LSB 2 / MSB 29. There seems to be no real reason why that bit cannot be used,

[PATCH mm-unstable v1 18/26] powerpc/nohash/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE on 32bit and 64bit. On 64bit, let's use MSB 56 (LSB 7), located right next to the page type. On 32bit, let's use LSB 2 to avoid stealing one bit from the swap offset. There seems to be no real reason why these bits cannot be used for swap PTEs. The impo

[PATCH mm-unstable v1 19/26] riscv/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the offset. This reduces the maximum swap space per file: on 32bit to 16 GiB (was 32 GiB). Note that this bit does not conflict with swap PMDs and could also be used in swap PMD context later. While at it, mask the type in __swp

[PATCH mm-unstable v1 20/26] sh/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by using bit 6 in the PTE, reducing the swap type in the !CONFIG_X2TLB case to 5 bits. Generic MM currently only uses 5 bits for the type (MAX_SWAPFILES_SHIFT), so the stolen bit is effectively unused. Interrestingly, the swap type in the !CONFIG_X2TLB c

[PATCH mm-unstable v1 21/26] sparc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE on 32bit

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by reusing the SRMMU_DIRTY bit as that seems to be safe to reuse inside a swap PTE. This avoids having to steal one bit from the swap offset. While at it, relocate the swap PTE layout documentation and use the same style now used for most other archs. No

[PATCH mm-unstable v1 22/26] sparc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE on 64bit

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the type. Generic MM currently only uses 5 bits for the type (MAX_SWAPFILES_SHIFT), so the stolen bit was effectively unused. While at it, mask the type in __swp_entry(). Cc: "David S. Miller" Signed-off-by: David Hildenbrand

[PATCH mm-unstable v1 23/26] um/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by using bit 10, which is yet unused for swap PTEs. The pte_mkuptodate() is a bit weird in __pte_to_swp_entry() for a swap PTE ... but it only messes with bit 1 and 2 and there is a comment in set_pte(), so leave these bits alone. While at it, mask the

[PATCH mm-unstable v1 25/26] xtensa/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by using bit 1. This bit should be safe to use for our usecase. Most importantly, we can still distinguish swap PTEs from PAGE_NONE PTEs (see pte_present()) and don't use one of the two reserved attribute masks (1101 and ). Attribute mask 1100 and 11

[PATCH mm-unstable v1 26/26] mm: remove __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread David Hildenbrand
__HAVE_ARCH_PTE_SWP_EXCLUSIVE is now supported by all architectures that support swp PTEs, so let's drop it. Signed-off-by: David Hildenbrand --- arch/alpha/include/asm/pgtable.h | 1 - arch/arc/include/asm/pgtable-bits-arcv2.h| 1 - arch/arm/include/asm/pgtable.h

[PATCH mm-unstable v1 24/26] x86/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE also on 32bit

2023-01-13 Thread David Hildenbrand
Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE just like we already do on x86-64. After deciphering the PTE layout it becomes clear that there are still unused bits for 2-level and 3-level page tables that we should be able to use. Reusing a bit avoids stealing one bit from the swap offset. While at

Re: [PATCH mm-unstable v1 04/26] arm/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-01-13 Thread Russell King (Oracle)
On Fri, Jan 13, 2023 at 06:10:04PM +0100, David Hildenbrand wrote: > Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit from the > offset. This reduces the maximum swap space per file to 64 GiB (was 128 > GiB). > > While at it drop the PTE_TYPE_FAULT from __swp_entry_to_pte() which is

Re: [PATCH] modpost: support arbitrary symbol length in modversion

2023-01-13 Thread Gary Guo
On Thu, 12 Jan 2023 14:40:59 -0700 Lucas De Marchi wrote: > On Wed, Jan 11, 2023 at 04:11:51PM +, Gary Guo wrote: > > > > struct modversion_info { > >-unsigned long crc; > >-char name[MODULE_NAME_LEN]; > >+/* Offset of the next modversion entry in relation to this one. */ > >+

Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)

2023-01-13 Thread Jessica Clarke
On Fri, Jan 13, 2023 at 08:55:41AM +0100, Ard Biesheuvel wrote: > On Fri, 13 Jan 2023 at 01:31, Luck, Tony wrote: > > > > > Yeah, if it was ia64-only, it's a non-issue these days. It's dead and > > > in pure maintenance mode from a kernel perspective (if even that). > > > > There's not much "simul

RE: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)

2023-01-13 Thread Luck, Tony
> For what it's worth, Debian and Gentoo both have ia64 ports with active > users (6.1 looks like it currently fails to build in Debian due to a > minor packaging issue, but various versions of 6.0 were built and > published, and one of those is running on the one ia64 Debian builder I > personally

Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)

2023-01-13 Thread Jessica Clarke
On 13 Jan 2023, at 21:03, Luck, Tony wrote: > >> For what it's worth, Debian and Gentoo both have ia64 ports with active >> users (6.1 looks like it currently fails to build in Debian due to a >> minor packaging issue, but various versions of 6.0 were built and >> published, and one of those is r

Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)

2023-01-13 Thread John Paul Adrian Glaubitz
Hello Ard! Can I take that as an ack on [0]? The EFI subsystem has evolved substantially over the years, and there is really no way to do any IA64 testing beyond build testing, so from that perspective, dropping it entirely would be welcomed. ia64 is regularly tested in Debian and Gentoo [1][2

RE: [PATCH] lockref: stop doing cpu_relax in the cmpxchg loop

2023-01-13 Thread Luck, Tony
> diff --git a/lib/lockref.c b/lib/lockref.c > index 45e93ece8ba0..2afe4c5d8919 100644 > --- a/lib/lockref.c > +++ b/lib/lockref.c > @@ -23,7 +23,6 @@ > } > \ > if (!--retry)

Re: [PATCH] modpost: support arbitrary symbol length in modversion

2023-01-13 Thread Lucas De Marchi
On Wed, Jan 11, 2023 at 04:11:51PM +, Gary Guo wrote: Currently modversion uses a fixed size array of size (64 - sizeof(long)) to store symbol names, thus placing a hard limit on length of symbols. Rust symbols (which encodes crate and module names) can be quite a bit longer. The length limit

Re: lockref scalability on x86-64 vs cpu_relax

2023-01-13 Thread Mateusz Guzik
On 1/13/23, Linus Torvalds wrote: > Side note on your access() changes - if it turns out that you can > remove all the cred games, we should possibly then revert my old > commit d7852fbd0f04 ("access: avoid the RCU grace period for the > temporary subjective credentials") which avoided the biggest

[PATCH mm-unstable v1 00/26] mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE on all architectures with swap PTEs

2023-01-13 Thread David Hildenbrand
This is the follow-up on [1]: [PATCH v2 0/8] mm: COW fixes part 3: reliable GUP R/W FOLL_GET of anonymous pages After we implemented __HAVE_ARCH_PTE_SWP_EXCLUSIVE on most prominent enterprise architectures, implement __HAVE_ARCH_PTE_SWP_EXCLUSIVE on all remaining architectures that

Re: [PATCH v3 00/51] cpuidle,rcu: Clean up the mess

2023-01-13 Thread Paul E. McKenney
On Thu, Jan 12, 2023 at 08:43:14PM +0100, Peter Zijlstra wrote: > Hi All! > > The (hopefully) final respin of cpuidle vs rcu cleanup patches. Barring any > objections I'll be queueing these patches in tip/sched/core in the next few > days. > > v2: https://lkml.kernel.org/r/20220919095939.761690..

[PATCH] lockref: stop doing cpu_relax in the cmpxchg loop

2023-01-13 Thread Mateusz Guzik
On the x86-64 architecture even a failing cmpxchg grants exclusive access to the cacheline, making it preferable to retry the failed op immediately instead of stalling with the pause instruction. To illustrate the impact, below are benchmark results obtained by running various will-it-scale tests

Re: [PATCH] kallsyms: Fix scheduling with interrupts disabled in self-test

2023-01-13 Thread Luis Chamberlain
On Fri, Jan 13, 2023 at 09:44:35AM +0100, Petr Mladek wrote: > On Thu 2023-01-12 10:24:43, Luis Chamberlain wrote: > > On Thu, Jan 12, 2023 at 08:54:26PM +1000, Nicholas Piggin wrote: > > > kallsyms_on_each* may schedule so must not be called with interrupts > > > disabled. The iteration function c

Re: ia64 removal (was: Re: lockref scalability on x86-64 vs cpu_relax)

2023-01-13 Thread Ard Biesheuvel
On Fri, 13 Jan 2023 at 22:06, John Paul Adrian Glaubitz wrote: > > Hello Ard! > > > Can I take that as an ack on [0]? The EFI subsystem has evolved > > substantially over the years, and there is really no way to do any > > IA64 testing beyond build testing, so from that perspective, dropping > > i

Re: [PATCH] lockref: stop doing cpu_relax in the cmpxchg loop

2023-01-13 Thread Linus Torvalds
On Fri, Jan 13, 2023 at 3:47 PM Luck, Tony wrote: > > The computer necrophiliacs at Debian and Gentoo seem determined > to keep ia64 alive. > > So perhaps this should s/cpu_relax/soemt_relax/ where soemt_relax > is a no-op everywhere except ia64, which can define it as cpu_relax. Heh. I already t

Re: [PATCH net v5] net: wan: Add checks for NULL for utdm in undo_uhdlc_init and unmap_si_regs

2023-01-13 Thread patchwork-bot+netdevbpf
Hello: This patch was applied to netdev/net.git (master) by Jakub Kicinski : On Thu, 12 Jan 2023 10:47:03 +0300 you wrote: > If uhdlc_priv_tsa != 1 then utdm is not initialized. > And if ret != NULL then goto undo_uhdlc_init, where > utdm is dereferenced. Same if dev == NULL. > > Found by Astra

Re: [PATCH net-next 00/10] net: mdio: Continue separating C22 and C45

2023-01-13 Thread patchwork-bot+netdevbpf
Hello: This series was applied to netdev/net-next.git (master) by Jakub Kicinski : On Thu, 12 Jan 2023 16:15:07 +0100 you wrote: > I've picked this older series from Andrew up and rebased it onto > the latest net-next. > > This is the second patch set in the series which separates the C22 > and