Re: [PATCH 2/2] MAINTAINERS: Make cxl obsolete

[Christophe Leroy]

Le 09/04/2024 à 06:37, Michael Ellerman a écrit :
> Andrew Donnellan  writes:
>> The cxl driver is no longer actively maintained and we intend to remove it
>> in a future kernel release. Change its status to obsolete, and update the
>> sysfs ABI documentation accordingly.
>>
>> Signed-off-by: Andrew Donnellan 
>> ---
>>   Documentation/ABI/{testing => obsolete}/sysfs-class-cxl | 3 +++
>>   MAINTAINERS | 4 ++--
>>   2 files changed, 5 insertions(+), 2 deletions(-)
>>   rename Documentation/ABI/{testing => obsolete}/sysfs-class-cxl (99%)
> 
> This is a good start, but I suspect if there are any actual users they
> are not going to be monitoring the status of cxl in the MAINTAINERS file :)
> 
> I think we should probably modify Kconfig so that anyone who's using cxl
> on purpose has some chance to notice before we remove it.
> 
> Something like the patch below. Anyone who has an existing config and
> runs oldconfig will get a prompt, eg:
> 
>Deprecated support for IBM Coherent Accelerators (CXL) (DEPRECATED_CXL) 
> [N/m/y/?] (NEW)
> 
> Folks who just use defconfig etc. won't notice any change which is a
> pity. We could also change the default to n, but that risks breaking
> someone's machine. Maybe we do that in a another releases time.

When I boot one of my boards I see:

[0.641090] mcr3000-hwmon 1800.hwmon: hwmon_device_register() is 
deprecated. Please convert the driver to use 
hwmon_device_register_with_info().

Could we do something similar, write a message at boottime when the CXL 
driver gets probed ?

Christophe

Re: [PATCH] soc: fsl: qe: Add check for platform_driver_register

[Maxim Kochetkov]

09.04.2024 06:08, Chen Ni пишет:

Return platform_driver_register() in order to transfer the error if
it fails.

Fixes: be7ecbd240b2 ("soc: fsl: qe: convert QE interrupt controller to 
platform_device")
Signed-off-by: Chen Ni 


Reviewed-by: Maxim Kochetkov 

Re: [PATCH 2/2] MAINTAINERS: Make cxl obsolete

[Michael Ellerman]

Andrew Donnellan  writes:
> The cxl driver is no longer actively maintained and we intend to remove it
> in a future kernel release. Change its status to obsolete, and update the
> sysfs ABI documentation accordingly.
>
> Signed-off-by: Andrew Donnellan 
> ---
>  Documentation/ABI/{testing => obsolete}/sysfs-class-cxl | 3 +++
>  MAINTAINERS | 4 ++--
>  2 files changed, 5 insertions(+), 2 deletions(-)
>  rename Documentation/ABI/{testing => obsolete}/sysfs-class-cxl (99%)

This is a good start, but I suspect if there are any actual users they
are not going to be monitoring the status of cxl in the MAINTAINERS file :)

I think we should probably modify Kconfig so that anyone who's using cxl
on purpose has some chance to notice before we remove it.

Something like the patch below. Anyone who has an existing config and
runs oldconfig will get a prompt, eg:

  Deprecated support for IBM Coherent Accelerators (CXL) (DEPRECATED_CXL) 
[N/m/y/?] (NEW)

Folks who just use defconfig etc. won't notice any change which is a
pity. We could also change the default to n, but that risks breaking
someone's machine. Maybe we do that in a another releases time.

cheers

diff --git a/drivers/misc/cxl/Kconfig b/drivers/misc/cxl/Kconfig
index 5efc4151bf58..e3fd3fcaf62a 100644
--- a/drivers/misc/cxl/Kconfig
+++ b/drivers/misc/cxl/Kconfig
@@ -9,11 +9,18 @@ config CXL_BASE
select PPC_64S_HASH_MMU
 
 config CXL
-   tristate "Support for IBM Coherent Accelerators (CXL)"
+   def_bool y
+   depends on DEPRECATED_CXL
+
+config DEPRECATED_CXL
+   tristate "Deprecated support for IBM Coherent Accelerators (CXL)"
depends on PPC_POWERNV && PCI_MSI && EEH
select CXL_BASE
default m
help
+ The cxl driver is no longer actively maintained and we intend to
+ remove it in a future kernel release.
+
  Select this option to enable driver support for IBM Coherent
  Accelerators (CXL).  CXL is otherwise known as Coherent Accelerator
  Processor Interface (CAPI).  CAPI allows accelerators in FPGAs to be

[PATCH] soc: fsl: qe: Add check for platform_driver_register

[Chen Ni]

Return platform_driver_register() in order to transfer the error if
it fails.

Fixes: be7ecbd240b2 ("soc: fsl: qe: convert QE interrupt controller to 
platform_device")
Signed-off-by: Chen Ni 
---
 drivers/soc/fsl/qe/qe_ic.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
index bbae3d39c7be..f17de6000ff2 100644
--- a/drivers/soc/fsl/qe/qe_ic.c
+++ b/drivers/soc/fsl/qe/qe_ic.c
@@ -481,7 +481,6 @@ static struct platform_driver qe_ic_driver =
 
 static int __init qe_ic_of_init(void)
 {
-   platform_driver_register(_ic_driver);
-   return 0;
+   return platform_driver_register(_ic_driver);
 }
 subsys_initcall(qe_ic_of_init);
-- 
2.25.1

[PATCH 2/2] MAINTAINERS: Make cxl obsolete

[Andrew Donnellan]

The cxl driver is no longer actively maintained and we intend to remove it
in a future kernel release. Change its status to obsolete, and update the
sysfs ABI documentation accordingly.

Signed-off-by: Andrew Donnellan 
---
 Documentation/ABI/{testing => obsolete}/sysfs-class-cxl | 3 +++
 MAINTAINERS | 4 ++--
 2 files changed, 5 insertions(+), 2 deletions(-)
 rename Documentation/ABI/{testing => obsolete}/sysfs-class-cxl (99%)

diff --git a/Documentation/ABI/testing/sysfs-class-cxl 
b/Documentation/ABI/obsolete/sysfs-class-cxl
similarity index 99%
rename from Documentation/ABI/testing/sysfs-class-cxl
rename to Documentation/ABI/obsolete/sysfs-class-cxl
index cfc48a87706b..8cba1b626985 100644
--- a/Documentation/ABI/testing/sysfs-class-cxl
+++ b/Documentation/ABI/obsolete/sysfs-class-cxl
@@ -1,3 +1,6 @@
+The cxl driver is no longer maintained, and will be removed from the kernel in
+the near future.
+
 Please note that attributes that are shared between devices are stored in
 the directory pointed to by the symlink device/.
 For example, the real path of the attribute /sys/class/cxl/afu0.0s/irqs_max is
diff --git a/MAINTAINERS b/MAINTAINERS
index 34f605498873..5eca2c23fb49 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5770,8 +5770,8 @@ CXL (IBM Coherent Accelerator Processor Interface CAPI) 
DRIVER
 M: Frederic Barrat 
 M: Andrew Donnellan 
 L: linuxppc-dev@lists.ozlabs.org
-S: Supported
-F: Documentation/ABI/testing/sysfs-class-cxl
+S: Obsolete
+F: Documentation/ABI/obsolete/sysfs-class-cxl
 F: Documentation/arch/powerpc/cxl.rst
 F: arch/powerpc/platforms/powernv/pci-cxl.c
 F: drivers/misc/cxl/
-- 
2.44.0

[PATCH 1/2] MAINTAINERS: Make cxlflash obsolete

[Andrew Donnellan]

The cxlflash driver is no longer actively maintained and we intend to
remove it in a future kernel release. Change its status to obsolete.

While we're here, Matthew Ochs no longer works at IBM and is no longer in
a position to access cxlflash hardware, so remove him from the maintainers
list.

Signed-off-by: Andrew Donnellan 
---
 MAINTAINERS | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index aea47e04c3a5..34f605498873 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5780,10 +5780,9 @@ F:   include/uapi/misc/cxl.h
 
 CXLFLASH (IBM Coherent Accelerator Processor Interface CAPI Flash) SCSI DRIVER
 M: Manoj N. Kumar 
-M: Matthew R. Ochs 
 M: Uma Krishnan 
 L: linux-s...@vger.kernel.org
-S: Supported
+S: Obsolete
 F: Documentation/arch/powerpc/cxlflash.rst
 F: drivers/scsi/cxlflash/
 F: include/uapi/scsi/cxlflash_ioctl.h
-- 
2.44.0

[powerpc:fixes-test] BUILD SUCCESS 36ba64b4cbc6145103a0e3586ae7ef595bdef132

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
fixes-test
branch HEAD: 36ba64b4cbc6145103a0e3586ae7ef595bdef132  
selftests/powerpc/papr-vpd: Fix missing variable initialization

elapsed time: 722m

configs tested: 156
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha allnoconfig   gcc  
alphaallyesconfig   gcc  
alpha   defconfig   gcc  
arc  allmodconfig   gcc  
arc   allnoconfig   gcc  
arc  allyesconfig   gcc  
arc defconfig   gcc  
arc   randconfig-001-20240409   gcc  
arc   randconfig-002-20240409   gcc  
arcvdk_hs38_defconfig   gcc  
arm  allmodconfig   gcc  
arm   allnoconfig   clang
arm  allyesconfig   gcc  
arm defconfig   clang
arm   randconfig-001-20240409   gcc  
arm   randconfig-002-20240409   clang
arm   randconfig-003-20240409   clang
arm   randconfig-004-20240409   gcc  
arm   sunxi_defconfig   gcc  
armvt8500_v6_v7_defconfig   gcc  
arm64allmodconfig   clang
arm64 allnoconfig   gcc  
arm64allyesconfig   clang
arm64   defconfig   gcc  
arm64 randconfig-001-20240409   gcc  
arm64 randconfig-002-20240409   gcc  
arm64 randconfig-003-20240409   clang
arm64 randconfig-004-20240409   clang
csky allmodconfig   gcc  
csky  allnoconfig   gcc  
csky allyesconfig   gcc  
cskydefconfig   gcc  
csky  randconfig-001-20240409   gcc  
csky  randconfig-002-20240409   gcc  
hexagon  allmodconfig   clang
hexagon   allnoconfig   clang
hexagon  allyesconfig   clang
hexagon defconfig   clang
hexagon   randconfig-001-20240409   clang
hexagon   randconfig-002-20240409   clang
i386 allmodconfig   gcc  
i386  allnoconfig   gcc  
i386 allyesconfig   gcc  
i386 buildonly-randconfig-001-20240409   clang
i386 buildonly-randconfig-002-20240409   clang
i386 buildonly-randconfig-003-20240409   gcc  
i386 buildonly-randconfig-004-20240409   clang
i386 buildonly-randconfig-005-20240409   gcc  
i386 buildonly-randconfig-006-20240409   gcc  
i386defconfig   clang
i386  randconfig-001-20240409   clang
i386  randconfig-002-20240409   gcc  
i386  randconfig-003-20240409   clang
i386  randconfig-004-20240409   gcc  
i386  randconfig-005-20240409   gcc  
i386  randconfig-006-20240409   clang
i386  randconfig-011-20240409   gcc  
i386  randconfig-012-20240409   clang
i386  randconfig-013-20240409   clang
i386  randconfig-014-20240409   clang
i386  randconfig-015-20240409   gcc  
i386  randconfig-016-20240409   clang
loongarchallmodconfig   gcc  
loongarch allnoconfig   gcc  
loongarch   defconfig   gcc  
loongarch randconfig-001-20240409   gcc  
loongarch randconfig-002-20240409   gcc  
m68k allmodconfig   gcc  
m68k  allnoconfig   gcc  
m68k allyesconfig   gcc  
m68kdefconfig   gcc  
microblaze   allmodconfig   gcc  
microblazeallnoconfig   gcc  
microblaze   allyesconfig   gcc  
microblaze  defconfig   gcc  
microblaze  mmu_defconfig   gcc  
mips  allnoconfig   gcc  
mips allyesconfig   gcc  
mips   bmips_be_defconfig   gcc  
mips cu1830-neo_defconfig   gcc  
nios2allmodconfig   gcc  
nios2 allnoconfig   gcc  
nios2allyesconfig   gcc  
nios2   defconfig   gcc  
nios2 randconfig-001-20240409   gcc  
nios2  

[powerpc:next] BUILD SUCCESS 8884fc918f6aee220f9b41806974508bd0213aca

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
next
branch HEAD: 8884fc918f6aee220f9b41806974508bd0213aca  powerpc: Fix fatal 
warnings flag for LLVM's integrated assembler

elapsed time: 721m

configs tested: 119
configs skipped: 125

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha allnoconfig   gcc  
alphaallyesconfig   gcc  
alpha   defconfig   gcc  
arc   allnoconfig   gcc  
arc defconfig   gcc  
arc   randconfig-001-20240409   gcc  
arc   randconfig-002-20240409   gcc  
arcvdk_hs38_defconfig   gcc  
arm   randconfig-001-20240409   gcc  
arm   randconfig-004-20240409   gcc  
arm   sunxi_defconfig   gcc  
armvt8500_v6_v7_defconfig   gcc  
arm64allmodconfig   clang
arm64 allnoconfig   gcc  
arm64allyesconfig   clang
arm64   defconfig   gcc  
arm64 randconfig-001-20240409   gcc  
arm64 randconfig-002-20240409   gcc  
csky  allnoconfig   gcc  
cskydefconfig   gcc  
csky  randconfig-001-20240409   gcc  
csky  randconfig-002-20240409   gcc  
i386 allmodconfig   gcc  
i386  allnoconfig   gcc  
i386 allyesconfig   gcc  
i386 buildonly-randconfig-001-20240409   clang
i386 buildonly-randconfig-002-20240409   clang
i386 buildonly-randconfig-004-20240409   clang
i386  randconfig-001-20240409   clang
i386  randconfig-003-20240409   clang
i386  randconfig-006-20240409   clang
i386  randconfig-012-20240409   clang
i386  randconfig-013-20240409   clang
i386  randconfig-014-20240409   clang
i386  randconfig-016-20240409   clang
loongarchallmodconfig   gcc  
loongarch allnoconfig   gcc  
loongarch   defconfig   gcc  
loongarch randconfig-001-20240409   gcc  
loongarch randconfig-002-20240409   gcc  
m68k allmodconfig   gcc  
m68k  allnoconfig   gcc  
m68k allyesconfig   gcc  
m68kdefconfig   gcc  
microblaze   allmodconfig   gcc  
microblazeallnoconfig   gcc  
microblaze   allyesconfig   gcc  
microblaze  defconfig   gcc  
microblaze  mmu_defconfig   gcc  
mips  allnoconfig   gcc  
mips allyesconfig   gcc  
mips   bmips_be_defconfig   gcc  
mips cu1830-neo_defconfig   gcc  
nios2allmodconfig   gcc  
nios2 allnoconfig   gcc  
nios2allyesconfig   gcc  
nios2   defconfig   gcc  
nios2 randconfig-001-20240409   gcc  
nios2 randconfig-002-20240409   gcc  
openrisc  allnoconfig   gcc  
openrisc allyesconfig   gcc  
openriscdefconfig   gcc  
openrisc   virt_defconfig   gcc  
parisc   allmodconfig   gcc  
pariscallnoconfig   gcc  
parisc   allyesconfig   gcc  
parisc  defconfig   gcc  
pariscrandconfig-001-20240409   gcc  
pariscrandconfig-002-20240409   gcc  
parisc64defconfig   gcc  
powerpc  allmodconfig   gcc  
powerpc   allnoconfig   gcc  
powerpc  allyesconfig   clang
powerpc  iss476-smp_defconfig   gcc  
powerpc ps3_defconfig   gcc  
powerpc   randconfig-002-20240409   gcc  
powerpc  storcenter_defconfig   gcc  
powerpc64 randconfig-001-20240409   gcc  
powerpc64 randconfig-003-20240409   gcc  
riscvallmodconfig   clang
riscv allnoconfig   gcc  
riscvallyesconfig   clang
riscv   defconfig   clang
riscv randconfig-002-20240409   gcc  
s390  allnoconfig   clang
s390 

Re: [PATCH] powerpc/pseries: remove returning ENODEV when uevent is triggered

[Lidong Zhong]

Hi Michael,

Could you share your opinion about this patch please?

Thanks,
Lidong

On Sat, Mar 23, 2024 at 4:47 PM Lidong Zhong  wrote:

> We have noticed the following nuisance messages during boot
>
> [7.120610][ T1060] vio vio: uevent: failed to send synthetic uevent
> [7.122281][ T1060] vio 4000: uevent: failed to send synthetic uevent
> [7.122304][ T1060] vio 4001: uevent: failed to send synthetic uevent
> [7.122324][ T1060] vio 4002: uevent: failed to send synthetic uevent
> [7.122345][ T1060] vio 4004: uevent: failed to send synthetic uevent
>
> It's caused by either vio_register_device_node() failed to set
> dev->of_node or
> the missing "compatible" property. Try return as much information as
> possible
> instead of a failure. The above annoying errors can also be removed
> after the patch applied.
>
> Signed-off-by: Lidong Zhong 
> ---
>  arch/powerpc/platforms/pseries/vio.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/vio.c
> b/arch/powerpc/platforms/pseries/vio.c
> index 90ff85c879bf..62961715ca24 100644
> --- a/arch/powerpc/platforms/pseries/vio.c
> +++ b/arch/powerpc/platforms/pseries/vio.c
> @@ -1593,12 +1593,13 @@ static int vio_hotplug(const struct device *dev,
> struct kobj_uevent_env *env)
>
> dn = dev->of_node;
> if (!dn)
> -   return -ENODEV;
> +   goto out;
> cp = of_get_property(dn, "compatible", NULL);
> if (!cp)
> -   return -ENODEV;
> -
> -   add_uevent_var(env, "MODALIAS=vio:T%sS%s", vio_dev->type, cp);
> +   add_uevent_var(env, "MODALIAS=vio:T%s", vio_dev->type);
> +else
> +   add_uevent_var(env, "MODALIAS=vio:T%sS%s", vio_dev->type,
> cp);
> +out:
> return 0;
>  }
>
> --
> 2.35.3
>
>

-- 
Regards,
Lidong Zhong

Re: [kvm-unit-tests PATCH v8 06/35] gitlab-ci: Run migration selftest on s390x and powerpc

[Nico Boehr]

Quoting Nicholas Piggin (2024-04-05 10:35:07)
> The migration harness is complicated and easy to break so CI will
> be helpful.
> 
> Signed-off-by: Nicholas Piggin 
> ---
>  .gitlab-ci.yml  | 32 +++-
>  s390x/unittests.cfg |  8 
>  2 files changed, 31 insertions(+), 9 deletions(-)
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index ff34b1f50..60b3cdfd2 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
[...]
> @@ -135,7 +147,7 @@ build-riscv64:
>  build-s390x:
>   extends: .outoftree_template
>   script:
> - - dnf install -y qemu-system-s390x gcc-s390x-linux-gnu
> + - dnf install -y qemu-system-s390x gcc-s390x-linux-gnu nmap-ncat
>   - mkdir build
>   - cd build
>   - ../configure --arch=s390x --cross-prefix=s390x-linux-gnu-
> @@ -161,6 +173,8 @@ build-s390x:
>sclp-1g
>sclp-3g
>selftest-setup
> +  selftest-migration-kvm

We're running under TCG in the Gitlab CI. I'm a little bit confused why
we're running a KVM-only test here.

Re: [kvm-unit-tests PATCH v8 13/35] doc: start documentation directory with unittests.cfg doc

[Nico Boehr]

Quoting Nicholas Piggin (2024-04-05 10:35:14)
> Consolidate unittests.cfg documentation in one place.
> 
> Suggested-by: Andrew Jones 
> Signed-off-by: Nicholas Piggin 
> ---
>  arm/unittests.cfg | 26 ++---
>  docs/unittests.txt| 89 +++
>  powerpc/unittests.cfg | 25 ++--
>  riscv/unittests.cfg   | 26 ++---
>  s390x/unittests.cfg   | 18 ++---
>  x86/unittests.cfg | 26 ++---
>  6 files changed, 107 insertions(+), 103 deletions(-)
>  create mode 100644 docs/unittests.txt

This is a nice improvement, thanks!

Reviewed-by: Nico Boehr 

Re: [kvm-unit-tests PATCH v8 03/35] migration: Add a migrate_skip command

[Nico Boehr]

Quoting Nicholas Piggin (2024-04-05 10:35:04)
[...]
> diff --git a/scripts/arch-run.bash b/scripts/arch-run.bash
> index 39419d4e2..4a1aab48d 100644
> --- a/scripts/arch-run.bash
> +++ b/scripts/arch-run.bash
[...]
> @@ -179,8 +189,11 @@ run_migration ()
> # Wait for test exit or further migration messages.
> if ! seen_migrate_msg ${src_out} ;  then
> sleep 0.1
> -   else
> +   elif grep -q "Now migrate the VM" < ${src_out} ; then
> do_migration || return $?
> +   elif [ $skip_migration -eq 0 ] && grep -q "Skipped VM 
> migration" < ${src_out} ; then
> +   echo > ${src_infifo} # Resume src and carry on.
> +   break;

If I understand the code correctly, this simply makes the test PASS when
migration is skipped, am I wrong?

If so, can we set ret=77 here so we get a nice SKIP?

Re: [kvm-unit-tests PATCH v8 04/35] (arm|s390): Use migrate_skip in test cases

[Nico Boehr]

Quoting Nicholas Piggin (2024-04-05 10:35:05)
> Have tests use the new migrate_skip command in skip paths, rather than
> calling migrate_once to prevent harness reporting an error.
> 
> s390x/migration.c adds a new command that looks like it was missing
> previously.
> 
> Reviewed-by: Thomas Huth 
> Signed-off-by: Nicholas Piggin 

Thanks for finding the missing skip!

Reviewed-by: Nico Boehr 

Re: [PATCH v3] NUMA: Early use of cpu_to_node() returns 0 instead of the correct node id

[Lameter, Christopher]

On Wed, 27 Mar 2024, Andrew Morton wrote:


In order to fix the bug, the patch introduces early_numa_node_init()
which is called after smp_prepare_boot_cpu() in start_kernel.
early_numa_node_init will initialize the "numa_node" as soon as
the early_cpu_to_node() is ready, before the cpu_to_node() is called
at the first time.


What are the userspace-visible runtime effects of this bug?


Performance is reduced since there is increase in off node accesses.

Re: [PATCH v3 06/15] net: kunit: Suppress lock warning noise at end of dev_addr_lists tests

[Guenter Roeck]

On Wed, Apr 03, 2024 at 06:34:12PM -0700, Jakub Kicinski wrote:
> On Wed,  3 Apr 2024 06:19:27 -0700 Guenter Roeck wrote:
> > dev_addr_lists_test generates lock warning noise at the end of tests
> > if lock debugging is enabled. There are two sets of warnings.
> > 
> > WARNING: CPU: 0 PID: 689 at kernel/locking/mutex.c:923 
> > __mutex_unlock_slowpath.constprop.0+0x13c/0x368
> > DEBUG_LOCKS_WARN_ON(__owner_task(owner) != __get_current())
> > 
> > WARNING: kunit_try_catch/1336 still has locks held!
> > 
> > KUnit test cleanup is not guaranteed to run in the same thread as the test
> > itself. For this test, this means that rtnl_lock() and rtnl_unlock() may
> > be called from different threads. This triggers the warnings.
> > Suppress the warnings because they are irrelevant for the test and just
> > confusing and distracting.
> > 
> > The first warning can be suppressed by using START_SUPPRESSED_WARNING()
> > and END_SUPPRESSED_WARNING() around the call to rtnl_unlock(). To suppress
> > the second warning, it is necessary to set debug_locks_silent while the
> > rtnl lock is held.
> 
> Is it okay if I move the locking into the tests, instead?
> It's only 4 lines more and no magic required, seems to work fine.

I don't think it is that simple. Unit tests run in a kernel thread
and exit immediately if a test fails. While the unit test code _looks_
sequential, that isn't really the case. Every instance of KUNIT_ASSERT_x
or KUNIT_FAIL() results in immediate kernel thread termination. If
that happens, any rtnl_unlock() in the failed function would not be
executed. I am not aware of an equivalent of atexit() for kernel threads
which would fix the problem. My understanding is that the kunit system
doesn't support an equivalent either, but at least sometimes executes
the exit function in a different thread context.

Guenter

Re: [PATCH -next 1/3 v2] powerpc: boot: Fix kernel-doc param for partial_decompress

[Randy Dunlap]

On 4/8/24 1:39 AM, Yang Li wrote:
> Fix the kernel-doc annotation for the 'skip' parameter in the
> partial_decompress() function by adding a missing underscore and colon.
> 
> Signed-off-by: Yang Li 

Reviewed-by: Randy Dunlap 

Thanks.

> ---
>  arch/powerpc/boot/decompress.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/boot/decompress.c b/arch/powerpc/boot/decompress.c
> index 977eb15a6d17..6835cb53f034 100644
> --- a/arch/powerpc/boot/decompress.c
> +++ b/arch/powerpc/boot/decompress.c
> @@ -101,7 +101,7 @@ static void print_err(char *s)
>   * @input_size:  length of the input buffer
>   * @outbuf:  output buffer
>   * @output_size: length of the output buffer
> - * @skip number of output bytes to ignore
> + * @_skip:   number of output bytes to ignore
>   *
>   * This function takes compressed data from inbuf, decompresses and write it 
> to
>   * outbuf. Once output_size bytes are written to the output buffer, or the

-- 
#Randy

Re: [PATCH -next 3/3 v2] powerpc/rtas: Add kernel-doc comments to smp_startup_cpu()

[Randy Dunlap]

On 4/7/24 10:31 PM, Yang Li wrote:
> This commit adds kernel-doc style comments with complete parameter
> descriptions for the function smp_startup_cpu().
> 
> Signed-off-by: Yang Li 

Acked-by: Randy Dunlap 

Thanks.

> ---
>  arch/powerpc/platforms/cell/smp.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/powerpc/platforms/cell/smp.c 
> b/arch/powerpc/platforms/cell/smp.c
> index 30394c6f8894..fee638fd8970 100644
> --- a/arch/powerpc/platforms/cell/smp.c
> +++ b/arch/powerpc/platforms/cell/smp.c
> @@ -54,6 +54,7 @@ static cpumask_t of_spin_map;
>  
>  /**
>   * smp_startup_cpu() - start the given cpu
> + * @lcpu: Logical CPU ID of the CPU to be started.
>   *
>   * At boot time, there is nothing to do for primary threads which were
>   * started from Open Firmware.  For anything else, call RTAS with the

-- 
#Randy

Re: [PATCH -next 2/3 v2] powerpc: Fix kernel-doc comments in fsl_gtm.c

[Randy Dunlap]

On 4/7/24 10:31 PM, Yang Li wrote:
> Fix some function names in kernel-doc comments.
> 
> Signed-off-by: Yang Li 

Reviewed-by: Randy Dunlap 

Thanks.

> ---
>  arch/powerpc/sysdev/fsl_gtm.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/sysdev/fsl_gtm.c b/arch/powerpc/sysdev/fsl_gtm.c
> index 39186ad6b3c3..3dabc9621810 100644
> --- a/arch/powerpc/sysdev/fsl_gtm.c
> +++ b/arch/powerpc/sysdev/fsl_gtm.c
> @@ -77,7 +77,7 @@ struct gtm {
>  static LIST_HEAD(gtms);
>  
>  /**
> - * gtm_get_timer - request GTM timer to use it with the rest of GTM API
> + * gtm_get_timer16 - request GTM timer to use it with the rest of GTM API
>   * Context:  non-IRQ
>   *
>   * This function reserves GTM timer for later use. It returns gtm_timer
> @@ -110,7 +110,7 @@ struct gtm_timer *gtm_get_timer16(void)
>  EXPORT_SYMBOL(gtm_get_timer16);
>  
>  /**
> - * gtm_get_specific_timer - request specific GTM timer
> + * gtm_get_specific_timer16 - request specific GTM timer
>   * @gtm: specific GTM, pass here GTM's device_node->data
>   * @timer:   specific timer number, Timer1 is 0.
>   * Context:  non-IRQ
> @@ -260,7 +260,7 @@ int gtm_set_timer16(struct gtm_timer *tmr, unsigned long 
> usec, bool reload)
>  EXPORT_SYMBOL(gtm_set_timer16);
>  
>  /**
> - * gtm_set_exact_utimer16 - (re)set 16 bits timer
> + * gtm_set_exact_timer16 - (re)set 16 bits timer
>   * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
>   * @usec:timer interval in microseconds
>   * @reload:  if set, the timer will reset upon expiry rather than

-- 
#Randy

Re: [PATCH 0/2] Deduplicate bin_attribute simple read() callbacks

[Rafael J. Wysocki]

On Sat, Apr 6, 2024 at 3:52 PM Lukas Wunner  wrote:
>
> For my upcoming PCI device authentication v2 patches, I have the need
> to expose a simple buffer in virtual memory as a bin_attribute.
>
> It turns out we've duplicated the ->read() callback for such simple
> buffers a fair number of times across the tree.
>
> So instead of reinventing the wheel, I decided to introduce a common
> helper and eliminate all duplications I could find.
>
> I'm open to a bikeshedding discussion on the sysfs_bin_attr_simple_read()
> name. ;)
>
> Lukas Wunner (2):
>   sysfs: Add sysfs_bin_attr_simple_read() helper
>   treewide: Use sysfs_bin_attr_simple_read() helper
>
>  arch/powerpc/platforms/powernv/opal.c  | 10 +---
>  drivers/acpi/bgrt.c|  9 +---
>  drivers/firmware/dmi_scan.c| 12 ++
>  drivers/firmware/efi/rci2-table.c  | 10 +---
>  drivers/gpu/drm/i915/gvt/firmware.c| 26 +
>  .../intel/int340x_thermal/int3400_thermal.c|  9 +---
>  fs/sysfs/file.c| 27 
> ++
>  include/linux/sysfs.h  | 15 
>  init/initramfs.c   | 10 +---
>  kernel/module/sysfs.c  | 13 +--
>  10 files changed, 56 insertions(+), 85 deletions(-)
>
> --

For the series

Acked-by: Rafael J. Wysocki 

Re: [PATCH v4 07/10] cpu/SMT: Allow enabling partial SMT states via sysfs

[Michal Suchánek]

Hello,

On Wed, Jul 05, 2023 at 04:51:40PM +0200, Laurent Dufour wrote:
> From: Michael Ellerman 
> 
> Add support to the /sys/devices/system/cpu/smt/control interface for
> enabling a specified number of SMT threads per core, including partial
> SMT states where not all threads are brought online.
> 
> The current interface accepts "on" and "off", to enable either 1 or all
> SMT threads per core.
> 
> This commit allows writing an integer, between 1 and the number of SMT
> threads supported by the machine. Writing 1 is a synonym for "off", 2 or
> more enables SMT with the specified number of threads.
> 
> When reading the file, if all threads are online "on" is returned, to
> avoid changing behaviour for existing users. If some other number of
> threads is online then the integer value is returned.
> 
> Architectures like x86 only supporting 1 thread or all threads, should not
> define CONFIG_SMT_NUM_THREADS_DYNAMIC. Architecture supporting partial SMT
> states, like PowerPC, should define it.

This causes a regression:
https://groups.google.com/g/powerpc-utils-devel/c/wrwVzAAnRlI/m/5KJSoqP4BAAJ

The userspace code only changes the SMT mode of online CPUs (at lest one
thread is online) and does not touch offline CPUs.

Using this new interface offlined CPUs are onlined when SMT value is
set.

Would you look into special-casing the offline CPUs?

Thanks

Michal

> 
> Signed-off-by: Michael Ellerman 
> [ldufour: slightly reword the commit's description]
> [ldufour: remove switch() in __store_smt_control()]
> Reported-by: kernel test robot 
> Closes: 
> https://lore.kernel.org/oe-kbuild-all/202306282340.ihqm0fla-...@intel.com/
> [ldufour: fix build issue in control_show()]
> Signed-off-by: Laurent Dufour 
> ---
>  .../ABI/testing/sysfs-devices-system-cpu  |  1 +
>  kernel/cpu.c  | 60 ++-
>  2 files changed, 45 insertions(+), 16 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu 
> b/Documentation/ABI/testing/sysfs-devices-system-cpu
> index ecd585ca2d50..6dba65fb1956 100644
> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> @@ -555,6 +555,7 @@ Description:  Control Symmetric Multi Threading (SMT)
> 
> =
>"on" SMT is enabled
>"off"SMT is disabled
> +  ""SMT is enabled with N threads per 
> core.
>"forceoff"   SMT is force disabled. Cannot be 
> changed.
>"notsupported"   SMT is not supported by the CPU
>"notimplemented" SMT runtime toggling is not
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 9a8d0685e055..7e8f1b044772 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -2876,11 +2876,19 @@ static const struct attribute_group 
> cpuhp_cpu_root_attr_group = {
>  
>  #ifdef CONFIG_HOTPLUG_SMT
>  
> +static bool cpu_smt_num_threads_valid(unsigned int threads)
> +{
> + if (IS_ENABLED(CONFIG_SMT_NUM_THREADS_DYNAMIC))
> + return threads >= 1 && threads <= cpu_smt_max_threads;
> + return threads == 1 || threads == cpu_smt_max_threads;
> +}
> +
>  static ssize_t
>  __store_smt_control(struct device *dev, struct device_attribute *attr,
>   const char *buf, size_t count)
>  {
> - int ctrlval, ret;
> + int ctrlval, ret, num_threads, orig_threads;
> + bool force_off;
>  
>   if (cpu_smt_control == CPU_SMT_FORCE_DISABLED)
>   return -EPERM;
> @@ -2888,30 +2896,39 @@ __store_smt_control(struct device *dev, struct 
> device_attribute *attr,
>   if (cpu_smt_control == CPU_SMT_NOT_SUPPORTED)
>   return -ENODEV;
>  
> - if (sysfs_streq(buf, "on"))
> + if (sysfs_streq(buf, "on")) {
>   ctrlval = CPU_SMT_ENABLED;
> - else if (sysfs_streq(buf, "off"))
> + num_threads = cpu_smt_max_threads;
> + } else if (sysfs_streq(buf, "off")) {
>   ctrlval = CPU_SMT_DISABLED;
> - else if (sysfs_streq(buf, "forceoff"))
> + num_threads = 1;
> + } else if (sysfs_streq(buf, "forceoff")) {
>   ctrlval = CPU_SMT_FORCE_DISABLED;
> - else
> + num_threads = 1;
> + } else if (kstrtoint(buf, 10, _threads) == 0) {
> + if (num_threads == 1)
> + ctrlval = CPU_SMT_DISABLED;
> + else if (cpu_smt_num_threads_valid(num_threads))
> + ctrlval = CPU_SMT_ENABLED;
> + else
> + return -EINVAL;
> + } else {
>   return -EINVAL;
> + }
>  
>   ret = lock_device_hotplug_sysfs();
>   if (ret)
>   return ret;
>  
> - if (ctrlval != cpu_smt_control) {
> - switch (ctrlval) {
> - case CPU_SMT_ENABLED:
> -

[PATCH] powerpc/pseries: Enforce hcall result buffer validity and size

[Nathan Lynch via B4 Relay]

From: Nathan Lynch 

plpar_hcall(), plpar_hcall9(), and related functions expect callers to
provide valid result buffers of certain minimum size. Currently this
is communicated only through comments in the code and the compiler has
no idea.

For example, if I write a bug like this:

  long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE
  plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...);

This compiles with no diagnostics emitted, but likely results in stack
corruption at runtime when plpar_hcall9() stores results past the end
of the array. (To be clear this is a contrived example and I have not
found a real instance yet.)

To make this class of error less likely, we can use explicitly-sized
array parameters instead of pointers in the declarations for the hcall
APIs. When compiled with -Warray-bounds[1], the code above now
provokes a diagnostic like this:

error: array argument is too small;
is of size 32, callee requires at least 72 [-Werror,-Warray-bounds]
   60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf,
  | ^   ~~

[1] Enabled for LLVM builds but not GCC for now. See commit
0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and
related changes.

Signed-off-by: Nathan Lynch 
---
 arch/powerpc/include/asm/hvcall.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/hvcall.h 
b/arch/powerpc/include/asm/hvcall.h
index a41e542ba94d..39cd1ca4ccb9 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -524,7 +524,7 @@ long plpar_hcall_norets_notrace(unsigned long opcode, ...);
  * Used for all but the craziest of phyp interfaces (see plpar_hcall9)
  */
 #define PLPAR_HCALL_BUFSIZE 4
-long plpar_hcall(unsigned long opcode, unsigned long *retbuf, ...);
+long plpar_hcall(unsigned long opcode, unsigned long retbuf[static 
PLPAR_HCALL_BUFSIZE], ...);
 
 /**
  * plpar_hcall_raw: - Make a hypervisor call without calculating hcall stats
@@ -538,7 +538,7 @@ long plpar_hcall(unsigned long opcode, unsigned long 
*retbuf, ...);
  * plpar_hcall, but plpar_hcall_raw works in real mode and does not
  * calculate hypervisor call statistics.
  */
-long plpar_hcall_raw(unsigned long opcode, unsigned long *retbuf, ...);
+long plpar_hcall_raw(unsigned long opcode, unsigned long retbuf[static 
PLPAR_HCALL_BUFSIZE], ...);
 
 /**
  * plpar_hcall9: - Make a pseries hypervisor call with up to 9 return arguments
@@ -549,8 +549,8 @@ long plpar_hcall_raw(unsigned long opcode, unsigned long 
*retbuf, ...);
  * PLPAR_HCALL9_BUFSIZE to size the return argument buffer.
  */
 #define PLPAR_HCALL9_BUFSIZE 9
-long plpar_hcall9(unsigned long opcode, unsigned long *retbuf, ...);
-long plpar_hcall9_raw(unsigned long opcode, unsigned long *retbuf, ...);
+long plpar_hcall9(unsigned long opcode, unsigned long retbuf[static 
PLPAR_HCALL9_BUFSIZE], ...);
+long plpar_hcall9_raw(unsigned long opcode, unsigned long retbuf[static 
PLPAR_HCALL9_BUFSIZE], ...);
 
 /* pseries hcall tracing */
 extern struct static_key hcall_tracepoint_key;

---
base-commit: bfe51886ca544956eb4ff924d1937ac01d0ca9c8
change-id: 20240408-pseries-hvcall-retbuf-c47c4d70d847

Best regards,
-- 
Nathan Lynch 

Re: [PATCH 1/4] KVM: delete .change_pte MMU notifier callback

[Peter Xu]

On Fri, Apr 05, 2024 at 07:58:12AM -0400, Paolo Bonzini wrote:
> The .change_pte() MMU notifier callback was intended as an
> optimization. The original point of it was that KSM could tell KVM to flip
> its secondary PTE to a new location without having to first zap it. At
> the time there was also an .invalidate_page() callback; both of them were
> *not* bracketed by calls to mmu_notifier_invalidate_range_{start,end}(),
> and .invalidate_page() also doubled as a fallback implementation of
> .change_pte().
> 
> Later on, however, both callbacks were changed to occur within an
> invalidate_range_start/end() block.
> 
> In the case of .change_pte(), commit 6bdb913f0a70 ("mm: wrap calls to
> set_pte_at_notify with invalidate_range_start and invalidate_range_end",
> 2012-10-09) did so to remove the fallback from .invalidate_page() to
> .change_pte() and allow sleepable .invalidate_page() hooks.
> 
> This however made KVM's usage of the .change_pte() callback completely
> moot, because KVM unmaps the sPTEs during .invalidate_range_start()
> and therefore .change_pte() has no hope of finding a sPTE to change.
> Drop the generic KVM code that dispatches to kvm_set_spte_gfn(), as
> well as all the architecture specific implementations.

Paolo,

I may miss a bunch of details here (as I still remember some change_pte
patches previously on the list..), however not sure whether we considered
enable it?  Asked because I remember Andrea used to have a custom tree
maintaining that part:

https://github.com/aagit/aa/commit/c761078df7a77d13ddfaeebe56a0f4bc128b1968

Maybe it can't be enabled for some reason that I overlooked in the current
tree, or we just decided to not to?

Thanks,

-- 
Peter Xu

Re: [PATCH 2/2] treewide: Use sysfs_bin_attr_simple_read() helper

[Zhi Wang]

On Sat, 6 Apr 2024 15:52:02 +0200
Lukas Wunner  wrote:

> Deduplicate ->read() callbacks of bin_attributes which are backed by a
> simple buffer in memory:
> 
> Use the newly introduced sysfs_bin_attr_simple_read() helper instead,
> either by referencing it directly or by declaring such bin_attributes
> with BIN_ATTR_SIMPLE_RO() or BIN_ATTR_SIMPLE_ADMIN_RO().
> 
> Aside from a reduction of LoC, this shaves off a few bytes from
> vmlinux (304 bytes on an x86_64 allyesconfig).
> 
> No functional change intended.
> 

As for GVT, looks good to me.

Acked-by: Zhi Wang 

> Signed-off-by: Lukas Wunner 
> ---
>  arch/powerpc/platforms/powernv/opal.c  | 10 +
>  drivers/acpi/bgrt.c|  9 +---
>  drivers/firmware/dmi_scan.c| 12 ++
>  drivers/firmware/efi/rci2-table.c  | 10 +
>  drivers/gpu/drm/i915/gvt/firmware.c| 26
> +- .../intel/int340x_thermal/int3400_thermal.c
> |  9 +--- init/initramfs.c
> | 10 + kernel/module/sysfs.c  |
> 13 +-- 8 files changed, 14 insertions(+), 85 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/powernv/opal.c
> b/arch/powerpc/platforms/powernv/opal.c index 45dd77e..5d0f35b 100644
> --- a/arch/powerpc/platforms/powernv/opal.c
> +++ b/arch/powerpc/platforms/powernv/opal.c
> @@ -792,14 +792,6 @@ static int __init opal_sysfs_init(void)
>   return 0;
>  }
>  
> -static ssize_t export_attr_read(struct file *fp, struct kobject
> *kobj,
> - struct bin_attribute *bin_attr, char
> *buf,
> - loff_t off, size_t count)
> -{
> - return memory_read_from_buffer(buf, count, ,
> bin_attr->private,
> -bin_attr->size);
> -}
> -
>  static int opal_add_one_export(struct kobject *parent, const char
> *export_name, struct device_node *np, const char *prop_name)
>  {
> @@ -826,7 +818,7 @@ static int opal_add_one_export(struct kobject
> *parent, const char *export_name, sysfs_bin_attr_init(attr);
>   attr->attr.name = name;
>   attr->attr.mode = 0400;
> - attr->read = export_attr_read;
> + attr->read = sysfs_bin_attr_simple_read;
>   attr->private = __va(vals[0]);
>   attr->size = vals[1];
>  
> diff --git a/drivers/acpi/bgrt.c b/drivers/acpi/bgrt.c
> index e4fb9e2..d1d9c92 100644
> --- a/drivers/acpi/bgrt.c
> +++ b/drivers/acpi/bgrt.c
> @@ -29,14 +29,7 @@
>  BGRT_SHOW(xoffset, image_offset_x);
>  BGRT_SHOW(yoffset, image_offset_y);
>  
> -static ssize_t image_read(struct file *file, struct kobject *kobj,
> -struct bin_attribute *attr, char *buf, loff_t off,
> size_t count) -{
> - memcpy(buf, attr->private + off, count);
> - return count;
> -}
> -
> -static BIN_ATTR_RO(image, 0);/* size gets filled in later */
> +static BIN_ATTR_SIMPLE_RO(image);
>  
>  static struct attribute *bgrt_attributes[] = {
>   _attr_version.attr,
> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index 015c95a..3d0f773 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -746,16 +746,8 @@ static void __init dmi_scan_machine(void)
>   pr_info("DMI not present or invalid.\n");
>  }
>  
> -static ssize_t raw_table_read(struct file *file, struct kobject
> *kobj,
> -   struct bin_attribute *attr, char *buf,
> -   loff_t pos, size_t count)
> -{
> - memcpy(buf, attr->private + pos, count);
> - return count;
> -}
> -
> -static BIN_ATTR(smbios_entry_point, S_IRUSR, raw_table_read, NULL,
> 0); -static BIN_ATTR(DMI, S_IRUSR, raw_table_read, NULL, 0);
> +static BIN_ATTR_SIMPLE_ADMIN_RO(smbios_entry_point);
> +static BIN_ATTR_SIMPLE_ADMIN_RO(DMI);
>  
>  static int __init dmi_init(void)
>  {
> diff --git a/drivers/firmware/efi/rci2-table.c
> b/drivers/firmware/efi/rci2-table.c index de1a9a1..4fd45d6 100644
> --- a/drivers/firmware/efi/rci2-table.c
> +++ b/drivers/firmware/efi/rci2-table.c
> @@ -40,15 +40,7 @@ struct rci2_table_global_hdr {
>  static u32 rci2_table_len;
>  unsigned long rci2_table_phys __ro_after_init =
> EFI_INVALID_TABLE_ADDR; 
> -static ssize_t raw_table_read(struct file *file, struct kobject
> *kobj,
> -   struct bin_attribute *attr, char *buf,
> -   loff_t pos, size_t count)
> -{
> - memcpy(buf, attr->private + pos, count);
> - return count;
> -}
> -
> -static BIN_ATTR(rci2, S_IRUSR, raw_table_read, NULL, 0);
> +static BIN_ATTR_SIMPLE_ADMIN_RO(rci2);
>  
>  static u16 checksum(void)
>  {
> diff --git a/drivers/gpu/drm/i915/gvt/firmware.c
> b/drivers/gpu/drm/i915/gvt/firmware.c index 4dd52ac..5e66a26 100644
> --- a/drivers/gpu/drm/i915/gvt/firmware.c
> +++ b/drivers/gpu/drm/i915/gvt/firmware.c
> @@ -50,21 +50,7 @@ struct gvt_firmware_header {
>  
>  #define dev_to_drm_minor(d) dev_get_drvdata((d))
>  
> -static 

Re: [FSL P50x0] Kernel 6.9-rc1 compiling issue

[Michael Ellerman]

Christophe Leroy  writes:
> Hi Christian, hi Hari,
>
> Le 04/04/2024 à 19:44, Christian Zigotzky a écrit :
>> Shall we use CONFIG_CRASH_DUMP to get int crashing_cpu = -1;?
>> 
>> Further information: 
>> https://lists.ozlabs.org/pipermail/linuxppc-dev/2024-March/269985.html 
>> 
>
> Looking at problematic commit 5c4233cc0920 ("powerpc/kdump: Split 
> KEXEC_CORE and CRASH_DUMP dependency"), my feeling is that the change 
> should be as follows.
>
> Hari, can you confirm ?
>
> diff --git a/arch/powerpc/platforms/85xx/smp.c 
> b/arch/powerpc/platforms/85xx/smp.c
> index 40aa58206888..3209fc92ac19 100644
> --- a/arch/powerpc/platforms/85xx/smp.c
> +++ b/arch/powerpc/platforms/85xx/smp.c
> @@ -362,7 +362,7 @@ struct smp_ops_t smp_85xx_ops = {
>   #endif
>   };
>
> -#ifdef CONFIG_KEXEC_CORE
> +#ifdef CONFIG_CRASH_DUMP
>   #ifdef CONFIG_PPC32
>   atomic_t kexec_down_cpus = ATOMIC_INIT(0);
>
> @@ -465,7 +465,7 @@ static void mpc85xx_smp_machine_kexec(struct kimage 
> *image)
>
>   default_machine_kexec(image);
>   }
> -#endif /* CONFIG_KEXEC_CORE */
> +#endif /* CONFIG_CRASH_DUMP */

That doesn't look right to me.

I think it needs something like below.

cheers

diff --git a/arch/powerpc/platforms/85xx/smp.c 
b/arch/powerpc/platforms/85xx/smp.c
index 40aa58206888..276060c993a0 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -398,6 +398,7 @@ static void mpc85xx_smp_kexec_cpu_down(int crash_shutdown, 
int secondary)
hard_irq_disable();
mpic_teardown_this_cpu(secondary);
 
+#ifdef CONFIG_CRASH_DUMP
if (cpu == crashing_cpu && cpu_thread_in_core(cpu) != 0) {
/*
 * We enter the crash kernel on whatever cpu crashed,
@@ -406,9 +407,11 @@ static void mpc85xx_smp_kexec_cpu_down(int crash_shutdown, 
int secondary)
 */
disable_threadbit = 1;
disable_cpu = cpu_first_thread_sibling(cpu);
-   } else if (sibling != crashing_cpu &&
-  cpu_thread_in_core(cpu) == 0 &&
-  cpu_thread_in_core(sibling) != 0) {
+   } else if (sibling == crashing_cpu)
+   return;
+#endif
+   if (cpu_thread_in_core(cpu) == 0 &&
+   cpu_thread_in_core(sibling) != 0) {
disable_threadbit = 2;
disable_cpu = sibling;
}

Re: [PATCH 1/4] KVM: delete .change_pte MMU notifier callback

[Michael Ellerman]

Paolo Bonzini  writes:
> The .change_pte() MMU notifier callback was intended as an
> optimization. The original point of it was that KSM could tell KVM to flip
> its secondary PTE to a new location without having to first zap it. At
> the time there was also an .invalidate_page() callback; both of them were
> *not* bracketed by calls to mmu_notifier_invalidate_range_{start,end}(),
> and .invalidate_page() also doubled as a fallback implementation of
> .change_pte().
>
> Later on, however, both callbacks were changed to occur within an
> invalidate_range_start/end() block.
>
> In the case of .change_pte(), commit 6bdb913f0a70 ("mm: wrap calls to
> set_pte_at_notify with invalidate_range_start and invalidate_range_end",
> 2012-10-09) did so to remove the fallback from .invalidate_page() to
> .change_pte() and allow sleepable .invalidate_page() hooks.
>
> This however made KVM's usage of the .change_pte() callback completely
> moot, because KVM unmaps the sPTEs during .invalidate_range_start()
> and therefore .change_pte() has no hope of finding a sPTE to change.
> Drop the generic KVM code that dispatches to kvm_set_spte_gfn(), as
> well as all the architecture specific implementations.
>
> Signed-off-by: Paolo Bonzini 
> ---
>  arch/arm64/kvm/mmu.c  | 34 -
>  arch/loongarch/include/asm/kvm_host.h |  1 -
>  arch/loongarch/kvm/mmu.c  | 32 
>  arch/mips/kvm/mmu.c   | 30 ---
>  arch/powerpc/include/asm/kvm_ppc.h|  1 -
>  arch/powerpc/kvm/book3s.c |  5 ---
>  arch/powerpc/kvm/book3s.h |  1 -
>  arch/powerpc/kvm/book3s_64_mmu_hv.c   | 12 --
>  arch/powerpc/kvm/book3s_hv.c  |  1 -
>  arch/powerpc/kvm/book3s_pr.c  |  7 
>  arch/powerpc/kvm/e500_mmu_host.c  |  6 ---

LGTM.

Acked-by: Michael Ellerman  (powerpc)

cheers

Re: [PATCH 2/2] treewide: Use sysfs_bin_attr_simple_read() helper

[Michael Ellerman]

Lukas Wunner  writes:
> Deduplicate ->read() callbacks of bin_attributes which are backed by a
> simple buffer in memory:
>
> Use the newly introduced sysfs_bin_attr_simple_read() helper instead,
> either by referencing it directly or by declaring such bin_attributes
> with BIN_ATTR_SIMPLE_RO() or BIN_ATTR_SIMPLE_ADMIN_RO().
>
> Aside from a reduction of LoC, this shaves off a few bytes from vmlinux
> (304 bytes on an x86_64 allyesconfig).
>
> No functional change intended.
>
> Signed-off-by: Lukas Wunner 
> ---
>  arch/powerpc/platforms/powernv/opal.c  | 10 +
>  drivers/acpi/bgrt.c|  9 +---
>  drivers/firmware/dmi_scan.c| 12 ++
>  drivers/firmware/efi/rci2-table.c  | 10 +
>  drivers/gpu/drm/i915/gvt/firmware.c| 26 
> +-
>  .../intel/int340x_thermal/int3400_thermal.c|  9 +---
>  init/initramfs.c   | 10 +
>  kernel/module/sysfs.c  | 13 +--
>  8 files changed, 14 insertions(+), 85 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/opal.c 
> b/arch/powerpc/platforms/powernv/opal.c
> index 45dd77e..5d0f35b 100644
> --- a/arch/powerpc/platforms/powernv/opal.c
> +++ b/arch/powerpc/platforms/powernv/opal.c
> @@ -792,14 +792,6 @@ static int __init opal_sysfs_init(void)
>   return 0;
>  }
>  
> -static ssize_t export_attr_read(struct file *fp, struct kobject *kobj,
> - struct bin_attribute *bin_attr, char *buf,
> - loff_t off, size_t count)
> -{
> - return memory_read_from_buffer(buf, count, , bin_attr->private,
> -bin_attr->size);
> -}
> -
>  static int opal_add_one_export(struct kobject *parent, const char 
> *export_name,
>  struct device_node *np, const char *prop_name)
>  {
> @@ -826,7 +818,7 @@ static int opal_add_one_export(struct kobject *parent, 
> const char *export_name,
>   sysfs_bin_attr_init(attr);
>   attr->attr.name = name;
>   attr->attr.mode = 0400;
> - attr->read = export_attr_read;
> + attr->read = sysfs_bin_attr_simple_read;
>   attr->private = __va(vals[0]);
>   attr->size = vals[1];

I gave it a quick boot and checked I could still read the attributes,
everything seems fine.

Acked-by: Michael Ellerman  (powerpc)

cheers

Re: [PATCH v2] Add static_key_feature_checks_initialized flag

[Michael Ellerman]

Nicholas Miehlbradt  writes:
> JUMP_LABEL_FEATURE_CHECK_DEBUG used static_key_intialized to determine
> whether {cpu,mmu}_has_feature() is used before static keys were
> initialized. However, {cpu,mmu}_has_feature() should not be used before
> setup_feature_keys() is called but static_key_initialized is set well
> before this by the call to jump_label_init() in early_init_devtree().
> This creates a window in which JUMP_LABEL_FEATURE_CHECK_DEBUG will not
> detect misuse and report errors. Add a flag specifically to indicate
> when {cpu,mmu}_has_feature() is safe to use.

I'm not sure it warrants a Fixes: tag, but it was commit
ca829e05d3d4 ("powerpc/64: Init jump labels before parse_early_param()")
which added the earlier call to jump_label_init() and created the window
where the debug checks don't fire.

cheers

Re: [PATCH 7/9] s390: Convert from tasklet to BH workqueue

[Harald Freudenberger]

On 2024-03-27 17:03, Allen Pais wrote:
The only generic interface to execute asynchronously in the BH context 
is

tasklet; however, it's marked deprecated and has some design flaws. To
replace tasklets, BH workqueue support was recently added. A BH 
workqueue
behaves similarly to regular workqueues except that the queued work 
items

are executed in the BH context.

This patch converts drivers/infiniband/* from tasklet to BH workqueue.

Based on the work done by Tejun Heo 
Branch: https://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git 
for-6.10


Note: Not tested. Please test/review.

Signed-off-by: Allen Pais 
---
...
 drivers/s390/crypto/ap_bus.c   | 24 +++---
 drivers/s390/crypto/ap_bus.h   |  2 +-
 drivers/s390/crypto/zcrypt_msgtype50.c |  2 +-
 drivers/s390/crypto/zcrypt_msgtype6.c  |  4 +--
...


Applied and tested the s390 AP bus and zcrypt part of the patch.
Works fine, a sniff test did not show any problems.
Thanks for your work.

Reviewed-by: Harald Freudenberger 

Re: [PATCH 7/9] s390: Convert from tasklet to BH workqueue

[Heiko Carstens]

On Wed, Mar 27, 2024 at 04:03:12PM +, Allen Pais wrote:
> The only generic interface to execute asynchronously in the BH context is
> tasklet; however, it's marked deprecated and has some design flaws. To
> replace tasklets, BH workqueue support was recently added. A BH workqueue
> behaves similarly to regular workqueues except that the queued work items
> are executed in the BH context.
> 
> This patch converts drivers/infiniband/* from tasklet to BH workqueue.
> 
> Based on the work done by Tejun Heo 
> Branch: https://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-6.10

I guess this dependency is a hard requirement due to commit 134874e2eee9
("workqueue: Allow cancel_work_sync() and disable_work() from atomic contexts
on BH work items")?

> ---
>  drivers/s390/block/dasd.c  | 42 
>  drivers/s390/block/dasd_int.h  | 10 +++---
>  drivers/s390/char/con3270.c| 27 
>  drivers/s390/crypto/ap_bus.c   | 24 +++---
>  drivers/s390/crypto/ap_bus.h   |  2 +-
>  drivers/s390/crypto/zcrypt_msgtype50.c |  2 +-
>  drivers/s390/crypto/zcrypt_msgtype6.c  |  4 +--
>  drivers/s390/net/ctcm_fsms.c   |  4 +--
>  drivers/s390/net/ctcm_main.c   | 15 -
>  drivers/s390/net/ctcm_main.h   |  5 +--
>  drivers/s390/net/ctcm_mpc.c| 12 +++
>  drivers/s390/net/ctcm_mpc.h|  7 ++--
>  drivers/s390/net/lcs.c | 26 +++
>  drivers/s390/net/lcs.h |  2 +-
>  drivers/s390/net/qeth_core_main.c  |  2 +-
>  drivers/s390/scsi/zfcp_qdio.c  | 45 +-
>  drivers/s390/scsi/zfcp_qdio.h  |  9 +++---
>  17 files changed, 117 insertions(+), 121 deletions(-)

I'm asking since this patch comes with multiple compile errors. Probably due
to lack of cross compiler tool chain on your side.

If the above wouldn't be a hard dependency I'd say we could take those parts
of your patch which are fine into the s390 tree for 6.10, fix the rest, and
schedule that as well for 6.10 via the s390 tree.

[PATCH v3] serial/pmac_zilog: Remove flawed mitigation for rx irq flood

[Finn Thain]

The mitigation was intended to stop the irq completely. That may be
better than a hard lock-up but it turns out that you get a crash anyway
if you're using pmac_zilog as a serial console:

ttyPZ0: pmz: rx irq flood !
BUG: spinlock recursion on CPU#0, swapper/0

That's because the pr_err() call in pmz_receive_chars() results in
pmz_console_write() attempting to lock a spinlock already locked in
pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal
BUG splat. The spinlock in question is the one in struct uart_port.

Even when it's not fatal, the serial port rx function ceases to work.
Also, the iteration limit doesn't play nicely with QEMU, as can be
seen in the bug report linked below.

A web search for other reports of the error message "pmz: rx irq flood"
didn't produce anything. So I don't think this code is needed any more.
Remove it.

Cc: Benjamin Herrenschmidt 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Christophe Leroy 
Cc: "Aneesh Kumar K.V" 
Cc: "Naveen N. Rao" 
Cc: Andy Shevchenko 
Cc: sta...@kernel.org
Cc: linux-m...@lists.linux-m68k.org
Link: https://github.com/vivier/qemu-m68k/issues/44
Link: https://lore.kernel.org/all/1078874617.9746.36.camel@gaston/
Acked-by: Michael Ellerman  (powerpc)
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Finn Thain 
---
Changed since v1:
 - Reworked commit log according to comments from Andy Shevchenko.

Changed since v2:
 - Added Acked-by and Cc tags.
---
 drivers/tty/serial/pmac_zilog.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
index c8bf08c19c64..77691fbbf779 100644
--- a/drivers/tty/serial/pmac_zilog.c
+++ b/drivers/tty/serial/pmac_zilog.c
@@ -210,7 +210,6 @@ static bool pmz_receive_chars(struct uart_pmac_port *uap)
 {
struct tty_port *port;
unsigned char ch, r1, drop, flag;
-   int loops = 0;
 
/* Sanity check, make sure the old bug is no longer happening */
if (uap->port.state == NULL) {
@@ -291,24 +290,11 @@ static bool pmz_receive_chars(struct uart_pmac_port *uap)
if (r1 & Rx_OVR)
tty_insert_flip_char(port, 0, TTY_OVERRUN);
next_char:
-   /* We can get stuck in an infinite loop getting char 0 when the
-* line is in a wrong HW state, we break that here.
-* When that happens, I disable the receive side of the driver.
-* Note that what I've been experiencing is a real irq loop 
where
-* I'm getting flooded regardless of the actual port speed.
-* Something strange is going on with the HW
-*/
-   if ((++loops) > 1000)
-   goto flood;
ch = read_zsreg(uap, R0);
if (!(ch & Rx_CH_AV))
break;
}
 
-   return true;
- flood:
-   pmz_interrupt_control(uap, 0);
-   pmz_error("pmz: rx irq flood !\n");
return true;
 }
 
-- 
2.39.3

Re: [PATCH 14/64] i2c: cpm: reword according to newest specification

[Wolfram Sang]

> > out_8(>i2c_reg->i2mod, 0x00);
> > -   out_8(>i2c_reg->i2com, I2COM_MASTER);  /* Master mode */
> > +   out_8(>i2c_reg->i2com, I2COM_MASTER);  /* Host mode */
> 
> I2COM_MASTER might be coming from the datasheet.

Maybe we can just drop the comment? The value we write is pretty
self-explaining.



signature.asc
Description: PGP signature

Re: [PATCH 0/2] Deduplicate bin_attribute simple read() callbacks

[Ard Biesheuvel]

On Sat, 6 Apr 2024 at 15:52, Lukas Wunner  wrote:
>
> For my upcoming PCI device authentication v2 patches, I have the need
> to expose a simple buffer in virtual memory as a bin_attribute.
>
> It turns out we've duplicated the ->read() callback for such simple
> buffers a fair number of times across the tree.
>
> So instead of reinventing the wheel, I decided to introduce a common
> helper and eliminate all duplications I could find.
>
> I'm open to a bikeshedding discussion on the sysfs_bin_attr_simple_read()
> name. ;)
>
> Lukas Wunner (2):
>   sysfs: Add sysfs_bin_attr_simple_read() helper
>   treewide: Use sysfs_bin_attr_simple_read() helper
>

Acked-by: Ard Biesheuvel 

>  arch/powerpc/platforms/powernv/opal.c  | 10 +---
>  drivers/acpi/bgrt.c|  9 +---
>  drivers/firmware/dmi_scan.c| 12 ++
>  drivers/firmware/efi/rci2-table.c  | 10 +---
>  drivers/gpu/drm/i915/gvt/firmware.c| 26 +
>  .../intel/int340x_thermal/int3400_thermal.c|  9 +---
>  fs/sysfs/file.c| 27 
> ++
>  include/linux/sysfs.h  | 15 
>  init/initramfs.c   | 10 +---
>  kernel/module/sysfs.c  | 13 +--
>  10 files changed, 56 insertions(+), 85 deletions(-)
>
> --
> 2.43.0
>

[PATCH -next 1/3 v2] powerpc: boot: Fix kernel-doc param for partial_decompress

[Yang Li]

Fix the kernel-doc annotation for the 'skip' parameter in the
partial_decompress() function by adding a missing underscore and colon.

Signed-off-by: Yang Li 
---
 arch/powerpc/boot/decompress.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/decompress.c b/arch/powerpc/boot/decompress.c
index 977eb15a6d17..6835cb53f034 100644
--- a/arch/powerpc/boot/decompress.c
+++ b/arch/powerpc/boot/decompress.c
@@ -101,7 +101,7 @@ static void print_err(char *s)
  * @input_size:  length of the input buffer
  * @outbuf:  output buffer
  * @output_size: length of the output buffer
- * @skip number of output bytes to ignore
+ * @_skip:   number of output bytes to ignore
  *
  * This function takes compressed data from inbuf, decompresses and write it to
  * outbuf. Once output_size bytes are written to the output buffer, or the
-- 
2.20.1.7.g153144c

Re: [PATCH] serial/pmac_zilog: Remove flawed mitigation for rx irq flood

[Geert Uytterhoeven]

Hi Jiri,

On Mon, Apr 8, 2024 at 7:37 AM Jiri Slaby  wrote:
> On 08. 04. 24, 7:32, Jiri Slaby wrote:
> > On 08. 04. 24, 7:29, Michael Ellerman wrote:
> >> Many maintainers won't drop Cc: tags if they are there in the submitted
> >> patch. So I agree with Andy that we should encourage folks not to add
> >> them in the first place.
> >
> > But fix the docs first.
> >
> > I am personally not biased to any variant (as in: I don't care where CCs
> > live in a patch).
>
> OTOH, as a submitter, it's a major PITA to carry CCs in notes (to have
> those under the --- line). Esp. when I have patches in a queue for years.

(Good to discover I'm not the only one carrying Very Old Patches ;-)

> How do people handle that? (Like rebases on current kernel.)

Keep them under the --- line in the actual commits, just like your
changelog? All of that is retained when rebasing.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Zhang Wei also unreachable working

[Uwe Kleine-König]

On Fri, Apr 05, 2024 at 09:20:41AM +0200, Uwe Kleine-König wrote:
> -M:   Li Yang 
>  M:   Zhang Wei 

This address of Zhang Wei doesn't seem to work either.

zh-kernel.org doesn't have an MX in DNS, the host behind its A entry
doesn't react to pings and connection attempts to tcp port 25 time out.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [PATCH 4/4] mm: replace set_pte_at_notify() with just set_pte_at()

[David Hildenbrand]

On 05.04.24 13:58, Paolo Bonzini wrote:

With the demise of the .change_pte() MMU notifier callback, there is no
notification happening in set_pte_at_notify().  It is a synonym of
set_pte_at() and can be replaced with it.

Signed-off-by: Paolo Bonzini 
---


A real joy seeing that gone

Reviewed-by: David Hildenbrand 

--
Cheers,

David / dhildenb

Re: [PATCH 3/4] mmu_notifier: remove the .change_pte() callback

[David Hildenbrand]

On 05.04.24 13:58, Paolo Bonzini wrote:

The scope of set_pte_at_notify() has reduced more and more through the
years.  Initially, it was meant for when the change to the PTE was
not bracketed by mmu_notifier_invalidate_range_{start,end}().  However,
that has not been so for over ten years.  During all this period
the only implementation of .change_pte() was KVM and it
had no actual functionality, because it was called after
mmu_notifier_invalidate_range_start() zapped the secondary PTE.

Now that this (nonfunctional) user of the .change_pte() callback is
gone, the whole callback can be removed.  For now, leave in place
set_pte_at_notify() even though it is just a synonym for set_pte_at().

Signed-off-by: Paolo Bonzini 
---


Reviewed-by: David Hildenbrand 

--
Cheers,

David / dhildenb

Re: [PATCH 1/4] KVM: delete .change_pte MMU notifier callback

[maobibo]

On 2024/4/5 下午7:58, Paolo Bonzini wrote:

The .change_pte() MMU notifier callback was intended as an
optimization. The original point of it was that KSM could tell KVM to flip
its secondary PTE to a new location without having to first zap it. At
the time there was also an .invalidate_page() callback; both of them were
*not* bracketed by calls to mmu_notifier_invalidate_range_{start,end}(),
and .invalidate_page() also doubled as a fallback implementation of
change_pte().

Later on, however, both callbacks were changed to occur within an
invalidate_range_start/end() block.

In the case of .change_pte(), commit 6bdb913f0a70 ("mm: wrap calls to
set_pte_at_notify with invalidate_range_start and invalidate_range_end",
2012-10-09) did so to remove the fallback from .invalidate_page() to
change_pte() and allow sleepable .invalidate_page() hooks.

This however made KVM's usage of the .change_pte() callback completely
moot, because KVM unmaps the sPTEs during .invalidate_range_start()
and therefore .change_pte() has no hope of finding a sPTE to change.
Drop the generic KVM code that dispatches to kvm_set_spte_gfn(), as
well as all the architecture specific implementations.

Signed-off-by: Paolo Bonzini 
---
  arch/arm64/kvm/mmu.c  | 34 -
  arch/loongarch/include/asm/kvm_host.h |  1 -
  arch/loongarch/kvm/mmu.c  | 32 
  arch/mips/kvm/mmu.c   | 30 ---
  arch/powerpc/include/asm/kvm_ppc.h|  1 -
  arch/powerpc/kvm/book3s.c |  5 ---
  arch/powerpc/kvm/book3s.h |  1 -
  arch/powerpc/kvm/book3s_64_mmu_hv.c   | 12 --
  arch/powerpc/kvm/book3s_hv.c  |  1 -
  arch/powerpc/kvm/book3s_pr.c  |  7 
  arch/powerpc/kvm/e500_mmu_host.c  |  6 ---
  arch/riscv/kvm/mmu.c  | 20 --
  arch/x86/kvm/mmu/mmu.c| 54 +--
  arch/x86/kvm/mmu/spte.c   | 16 
  arch/x86/kvm/mmu/spte.h   |  2 -
  arch/x86/kvm/mmu/tdp_mmu.c| 46 ---
  arch/x86/kvm/mmu/tdp_mmu.h|  1 -
  include/linux/kvm_host.h  |  2 -
  include/trace/events/kvm.h| 15 
  virt/kvm/kvm_main.c   | 43 -
  20 files changed, 2 insertions(+), 327 deletions(-)

diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index dc04bc767865..ff17849be9f4 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1768,40 +1768,6 @@ bool kvm_unmap_gfn_range(struct kvm *kvm, struct 
kvm_gfn_range *range)
return false;
  }
  
-bool kvm_set_spte_gfn(struct kvm *kvm, struct kvm_gfn_range *range)

-{
-   kvm_pfn_t pfn = pte_pfn(range->arg.pte);
-
-   if (!kvm->arch.mmu.pgt)
-   return false;
-
-   WARN_ON(range->end - range->start != 1);
-
-   /*
-* If the page isn't tagged, defer to user_mem_abort() for sanitising
-* the MTE tags. The S2 pte should have been unmapped by
-* mmu_notifier_invalidate_range_end().
-*/
-   if (kvm_has_mte(kvm) && !page_mte_tagged(pfn_to_page(pfn)))
-   return false;
-
-   /*
-* We've moved a page around, probably through CoW, so let's treat
-* it just like a translation fault and the map handler will clean
-* the cache to the PoC.
-*
-* The MMU notifiers will have unmapped a huge PMD before calling
-* ->change_pte() (which in turn calls kvm_set_spte_gfn()) and
-* therefore we never need to clear out a huge PMD through this
-* calling path and a memcache is not required.
-*/
-   kvm_pgtable_stage2_map(kvm->arch.mmu.pgt, range->start << PAGE_SHIFT,
-  PAGE_SIZE, __pfn_to_phys(pfn),
-  KVM_PGTABLE_PROT_R, NULL, 0);
-
-   return false;
-}
-
  bool kvm_age_gfn(struct kvm *kvm, struct kvm_gfn_range *range)
  {
u64 size = (range->end - range->start) << PAGE_SHIFT;
diff --git a/arch/loongarch/include/asm/kvm_host.h 
b/arch/loongarch/include/asm/kvm_host.h
index 2d62f7b0d377..69305441f40d 100644
--- a/arch/loongarch/include/asm/kvm_host.h
+++ b/arch/loongarch/include/asm/kvm_host.h
@@ -203,7 +203,6 @@ void kvm_flush_tlb_all(void);
  void kvm_flush_tlb_gpa(struct kvm_vcpu *vcpu, unsigned long gpa);
  int kvm_handle_mm_fault(struct kvm_vcpu *vcpu, unsigned long badv, bool 
write);
  
-void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);

  int kvm_unmap_hva_range(struct kvm *kvm, unsigned long start, unsigned long 
end, bool blockable);
  int kvm_age_hva(struct kvm *kvm, unsigned long start, unsigned long end);
  int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
diff --git a/arch/loongarch/kvm/mmu.c b/arch/loongarch/kvm/mmu.c
index a556cff35740..98883aa23ab8 100644
--- a/arch/loongarch/kvm/mmu.c
+++ b/arch/loongarch/kvm/mmu.c
@@ -494,38 +494,6 @@ bool kvm_unmap_gfn_range(struct 

Re: [PATCH 2/4] KVM: remove unused argument of kvm_handle_hva_range()

[Philippe Mathieu-Daudé]

On 5/4/24 13:58, Paolo Bonzini wrote:

The only user was kvm_mmu_notifier_change_pte(), which is now gone.

Signed-off-by: Paolo Bonzini 
---
  virt/kvm/kvm_main.c | 7 +--
  1 file changed, 1 insertion(+), 6 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 4/4] mm: replace set_pte_at_notify() with just set_pte_at()

[Philippe Mathieu-Daudé]

On 5/4/24 13:58, Paolo Bonzini wrote:

With the demise of the .change_pte() MMU notifier callback, there is no
notification happening in set_pte_at_notify().  It is a synonym of
set_pte_at() and can be replaced with it.

Signed-off-by: Paolo Bonzini 
---
  include/linux/mmu_notifier.h | 2 --
  kernel/events/uprobes.c  | 5 ++---
  mm/ksm.c | 4 ++--
  mm/memory.c  | 7 +--
  mm/migrate_device.c  | 8 ++--
  5 files changed, 7 insertions(+), 19 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé