[PATCH v2] powerpc/fadump: reset dump area size if fadump memory reserve fails

[Sourabh Jain]

In case fadump_reserve_mem() fails to reserve memory, the
reserve_dump_area_size variable will retain the reserve area size. This
will lead to /sys/kernel/fadump/mem_reserved node displaying an incorrect
memory reserved by fadump.

To fix this problem, reserve dump area size variable is set to 0 if fadump
failed to reserve memory.

Fixes: 8255da95e545 ("powerpc/fadump: release all the memory above boot memory 
size")
Signed-off-by: Sourabh Jain 
Acked-by: Mahesh Salgaonkar 
---
Chnages form V1:
* Reset the dump area size within the error_out path to cover more
  failure cases. Furthermore, the commit description has been modified
  accordingly.
---
 arch/powerpc/kernel/fadump.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index f3166acab09b..5a07d0f9c7f0 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -654,6 +654,7 @@ int __init fadump_reserve_mem(void)
return ret;
 error_out:
fw_dump.fadump_enabled = 0;
+   fw_dump.reserve_dump_area_size = 0;
return 0;
 }
 
-- 
2.41.0

Re: [PATCH 1/2] tools/perf/tests: perf all metrics test fails when perf_event access is restricted

[Athira Rajeev]

> On 15-Jun-2023, at 1:08 PM, Athira Rajeev  wrote:
> 
> Perf all metrics test fails as below when perf_event access
> is restricted.
> 
>./perf test -v "perf all metrics test"
>Metric 'Memory_RD_BW_Chip' not printed in:
>Error:
>Access to performance monitoring and observability operations is limited.
>Enforced MAC policy settings (SELinux) can limit access to performance
>—
>access to performance monitoring and observability operations for processes
>without CAP_PERFMON, CAP_SYS_PTRACE or CAP_SYS_ADMIN Linux capability.
>—
>test child finished with -1
> end 
>perf all metrics test: FAILED!


Hi,

Looking for review comments on this patch.

Thanks
> 
> The perf all metrics test picks the input events from
> "perf list --raw-dump metrics" and runs "perf stat -M "$m""
> for each of the metrics in the list. It fails here for some
> of the metrics which needs access, since it collects system
> wide resource details/statistics. Fix the testcase to skip
> those metric events.
> 
> Signed-off-by: Athira Rajeev 
> ---
> tools/perf/tests/shell/stat_all_metrics.sh | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/tests/shell/stat_all_metrics.sh 
> b/tools/perf/tests/shell/stat_all_metrics.sh
> index 54774525e18a..14b96484a359 100755
> --- a/tools/perf/tests/shell/stat_all_metrics.sh
> +++ b/tools/perf/tests/shell/stat_all_metrics.sh
> @@ -6,7 +6,9 @@ err=0
> for m in $(perf list --raw-dump metrics); do
>   echo "Testing $m"
>   result=$(perf stat -M "$m" true 2>&1)
> -  if [[ "$result" =~ ${m:0:50} ]] || [[ "$result" =~ "" ]]
> +  # Skip if there is no access to perf_events monitoring
> +  # and observability operations
> +  if [[ "$result" =~ ${m:0:50} ]] || [[ "$result" =~ "" ]] || 
> [[ "$result" =~ "Access to performance monitoring and observability 
> operations is limited" ]]
>   then
> continue
>   fi
> -- 
> 2.31.1
> 

Re: [PATCH 2/2] tools/perf/tests: perf all metricgroups test fails when perf_event access is restricted

[Athira Rajeev]

> On 15-Jun-2023, at 1:08 PM, Athira Rajeev  wrote:
> 
> Perf all metricgroups test fails as below when perf_event access
> is restricted.
> 
>./perf test -v "perf all metricgroups test"
>Testing Memory_BW
>Error:
>Access to performance monitoring and observability operations is limited.
>Enforced MAC policy settings (SELinux) can limit access to performance
>—
>access to performance monitoring and observability operations for processes
>without CAP_PERFMON, CAP_SYS_PTRACE or CAP_SYS_ADMIN Linux capability.
>—
>test child finished with -1
> end 
>perf all metricgroups test: FAILED!
> 
> Fix the testcase to skip those metric events which needs perf_event access
> explicitly. The exit code of the testcase is based on return code of
> the perf stat command ( enabled by set -e option ). Hence save the
> exit status in a variable and use that to decide success or fail for the
> testcase.
> 
> Signed-off-by: Athira Rajeev 
> ---
> tools/perf/tests/shell/stat_all_metricgroups.sh | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/perf/tests/shell/stat_all_metricgroups.sh 
> b/tools/perf/tests/shell/stat_all_metricgroups.sh
> index cb35e488809a..fa86b562676a 100755
> --- a/tools/perf/tests/shell/stat_all_metricgroups.sh
> +++ b/tools/perf/tests/shell/stat_all_metricgroups.sh
> @@ -2,11 +2,19 @@
> # perf all metricgroups test
> # SPDX-License-Identifier: GPL-2.0
> 
> -set -e
> -
> for m in $(perf list --raw-dump metricgroups); do
>   echo "Testing $m"
> -  perf stat -M "$m" -a true
> +  result=$(perf stat -M "$m" -a true 2>&1)
> +  rc=$?
> +  # Skip if there is no access to perf_events monitoring
> +  # Otherwise exit based on the return code of perf comamnd.
> +  if [[ "$result" =~ "Access to performance monitoring and observability 
> operations is limited" ]]
> +  then
> +  continue
> +  else
> +  [ $rc -ne 0 ] && exit $rc
> +  fi
> +
> done

Hi,

Looking for review comments on this patch.

Thanks
Athira
> 
> exit 0
> -- 
> 2.31.1
> 

[PATCH] tools/perf/tests: Fix objdump in Object code reading test to look for all sections

[Athira Rajeev]

Object code reading test fails intermittently with below logs:

   Reading object code for memory address: 0xc00801dd34fc
   File is: /lib/modules/6.3.0-rc7+/kernel/fs/xfs/xfs.ko
   On file address is: 0x11359c
   Objdump command is: objdump -z -d --start-address=0x1134fc 
--stop-address=0x11357c /lib/modules/6.3.0-rc7+/kernel/fs/xfs/xfs.ko
   objdump read too few bytes: 128
   test child finished with -1
    end 
   Object code reading: FAILED!

This issue happens ramdomly depending on the sample ip
captured during the test run. In some cases, the same ip falls
in the xfs module. The test does an objdump on the xfs.ko file and
compares it with the dump from the dso that perf captures. But
since the range of ip address falls in debug info section, it fails
to find the address range with objdump. Fix the objdump option so
as to disasseble all sections to check the address range.

Signed-off-by: Athira Rajeev 
---
 tools/perf/tests/code-reading.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index ed3815163d1b..02132478856a 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -184,7 +184,7 @@ static int read_via_objdump(const char *filename, u64 addr, 
void *buf,
FILE *f;
int ret;
 
-   fmt = "%s -z -d --start-address=0x%"PRIx64" --stop-address=0x%"PRIx64" 
%s";
+   fmt = "%s -z -D --start-address=0x%"PRIx64" --stop-address=0x%"PRIx64" 
%s";
ret = snprintf(cmd, sizeof(cmd), fmt, "objdump", addr, addr + len,
   filename);
if (ret <= 0 || (size_t)ret >= sizeof(cmd))
-- 
2.35.3

[PATCH] tools/perf/tests: Fix Basic BPF llvm compile to check for libbpf support

[Athira Rajeev]

Basic BPF llvm compile fails in systems with libbpf
that doesn't support BTF. Log shows below information.

libbpf: BTF is required, but is missing or corrupted.
Failed to parse test case 'Basic BPF llvm compile'
test child finished with -2
 end 

Here BPF llvm compile fails due to missing BTF support.
Fix the llvm test to skip the test incase BTF support is
missing.

Signed-off-by: Athira Rajeev 
---
 tools/perf/tests/llvm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/perf/tests/llvm.c b/tools/perf/tests/llvm.c
index 0bc25a56cfef..4c73c9eab0bb 100644
--- a/tools/perf/tests/llvm.c
+++ b/tools/perf/tests/llvm.c
@@ -4,6 +4,7 @@
 #include 
 #include "tests.h"
 #include "debug.h"
+#include 
 
 #ifdef HAVE_LIBBPF_SUPPORT
 #include 
@@ -14,8 +15,12 @@ static int test__bpf_parsing(void *obj_buf, size_t 
obj_buf_sz)
struct bpf_object *obj;
 
obj = bpf_object__open_mem(obj_buf, obj_buf_sz, NULL);
-   if (libbpf_get_error(obj))
+   if (libbpf_get_error(obj)) {
+   /* Skip if there is no BTF support */
+   if (errno == ENOENT)
+   return TEST_SKIP;
return TEST_FAIL;
+   }
bpf_object__close(obj);
return TEST_OK;
 }
-- 
2.27.0

Re: [PATCH 1/6] media: v4l2: Add audio capture and output support

[Shengjiu Wang]

On Tue, Jul 4, 2023 at 1:59 AM Mark Brown  wrote:

> On Mon, Jul 03, 2023 at 03:12:55PM +0200, Hans Verkuil wrote:
>
> > My main concern is that these cross-subsystem drivers are a pain to
> > maintain. So there have to be good reasons to do this.
>
> > Also it is kind of weird to have to use the V4L2 API in userspace to
> > deal with a specific audio conversion. Quite unexpected.
>
> > But in the end, that's a decision I can't make.
>
> > So I wait for that feedback. Note that if the decision is made that this
> > can use V4L2, then there is quite a lot more that needs to be done:
> > documentation, new compliance tests, etc. It's adding a new API, and that
> > comes with additional work...
>
> Absolutely, I agree with all of this - my impression was that the target
> here would be bypass of audio streams to/from a v4l2 device, without
> bouncing through an application layer.  If it's purely for audio usage
> with no other tie to v4l2 then involving v4l2 does just seem like
> complication.
>

This audio use case is using the v4l2 application layer. in the user space
I need to call below v4l2 ioctls to implement the feature:
VIDIOC_QUERYCAP
VIDIOC_TRY_FMT
VIDIOC_S_FMT
VIDIOC_REQBUFS
VIDIOC_QUERYBUF
VIDIOC_STREAMON
VIDIOC_QBUF
VIDIOC_DQBUF
VIDIOC_STREAMOFF

why the driver was put in the ALSA, because previously we implemented
the ASRC M2P (memory to peripheral) in ALSA,  so I think it is better to
add M2M driver in ALSA.  The hardware IP is the same. The compatible
string is the same.

Best regards
Wang Shengjiu

Re: [PATCH 1/6] media: v4l2: Add audio capture and output support

[Shengjiu Wang]

On Mon, Jul 3, 2023 at 9:25 PM Takashi Iwai  wrote:

> On Mon, 03 Jul 2023 15:12:55 +0200,
> Hans Verkuil wrote:
> >
> > On 03/07/2023 14:53, Mark Brown wrote:
> > > On Mon, Jul 03, 2023 at 02:07:10PM +0200, Takashi Iwai wrote:
> > >> Shengjiu Wang wrote:
> > >
> > >>> There is no such memory to memory interface defined in ALSA.  Seems
> > >>> ALSA is not designed for M2M cases.
> > >
> > >> There is no restriction to implement memory-to-memory capture in ALSA
> > >> framework.  It'd be a matter of the setup of PCM capture source, and
> > >> you can create a corresponding kcontrol element to switch the mode or
> > >> assign a dedicated PCM substream, for example.  It's just that there
> > >> was little demand for that.
> > >
> > > Yeah, it's not a terrible idea.  We might use it more if we ever get
> > > better support for DSP audio, routing between the DSP and external
> > > devices if driven from the CPU would be a memory to memory thing.
> > >
> > >> I'm not much against adding the audio capture feature to V4L2,
> > >> though, if it really makes sense.  But creating a crafted /dev/audio*
> > >> doesn't look like a great idea to me, at least.
> > >
> > > I've still not looked at the code at all.
> >
> > My main concern is that these cross-subsystem drivers are a pain to
> > maintain. So there have to be good reasons to do this.
> >
> > Also it is kind of weird to have to use the V4L2 API in userspace to
> > deal with a specific audio conversion. Quite unexpected.
> >
> > But in the end, that's a decision I can't make.
> >
> > So I wait for that feedback. Note that if the decision is made that this
> > can use V4L2, then there is quite a lot more that needs to be done:
> > documentation, new compliance tests, etc. It's adding a new API, and that
> > comes with additional work...
>
> All agreed.  Especially in this case, it doesn't have to be in V4L2
> API, as it seems.
>
> (Though, the support of audio on V4L2 might be useful if it's closely
> tied with the a stream.  But that's another story.)
>

audio is a stream,  for this m2m audio case, V4L2 is the best choice
I found.

I know there is API change for V4L2,  but V4L2 is a good framework
for memory to memory,  I think it is worth to do this change.

if implement this M2M case in ALSA,  we may need to create a sound
card and open it twice for playback and capture,  it is complicated
to do this,  and I am not sure if there is any other issue besides these.
I can't find an example in the ALSA framework for this case.

best regards
wang shengjiu

>
>
> thanks,
>
> Takashi
>

[powerpc:merge] BUILD SUCCESS 039164657b85340b3318de642aa98ac2f0b99ad7

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
merge
branch HEAD: 039164657b85340b3318de642aa98ac2f0b99ad7  Automatic merge of 
'master' into merge (2023-07-03 13:50)

elapsed time: 721m

configs tested: 138
configs skipped: 11

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

tested configs:
alphaallyesconfig   gcc  
alpha   defconfig   gcc  
alpharandconfig-r023-20230703   gcc  
arc  allyesconfig   gcc  
arc defconfig   gcc  
arc  randconfig-r001-20230703   gcc  
arc  randconfig-r012-20230703   gcc  
arc  randconfig-r016-20230703   gcc  
arc  randconfig-r035-20230703   gcc  
arc  randconfig-r043-20230703   gcc  
arm  allmodconfig   gcc  
arm  allyesconfig   gcc  
arm defconfig   gcc  
arm  ep93xx_defconfig   clang
armkeystone_defconfig   gcc  
arm   multi_v4t_defconfig   gcc  
arm  randconfig-r012-20230703   gcc  
arm  randconfig-r026-20230703   gcc  
arm  randconfig-r034-20230703   clang
arm  randconfig-r046-20230703   gcc  
arm   spitz_defconfig   clang
arm64allyesconfig   gcc  
arm64   defconfig   gcc  
arm64randconfig-r005-20230703   gcc  
arm64randconfig-r016-20230703   clang
cskydefconfig   gcc  
csky randconfig-r001-20230703   gcc  
csky randconfig-r004-20230703   gcc  
csky randconfig-r006-20230703   gcc  
csky randconfig-r014-20230703   gcc  
csky randconfig-r022-20230703   gcc  
csky randconfig-r025-20230703   gcc  
csky randconfig-r033-20230703   gcc  
hexagon  randconfig-r004-20230703   clang
hexagon  randconfig-r041-20230703   clang
hexagon  randconfig-r045-20230703   clang
i386 allyesconfig   clang
i386 allyesconfig   gcc  
i386 buildonly-randconfig-r004-20230703   gcc  
i386 buildonly-randconfig-r005-20230703   gcc  
i386 buildonly-randconfig-r006-20230703   gcc  
i386  debian-10.3   gcc  
i386defconfig   gcc  
i386 randconfig-i001-20230703   gcc  
i386 randconfig-i002-20230703   gcc  
i386 randconfig-i003-20230703   gcc  
i386 randconfig-i004-20230703   gcc  
i386 randconfig-i005-20230703   gcc  
i386 randconfig-i006-20230703   gcc  
i386 randconfig-i011-20230703   clang
i386 randconfig-i012-20230703   clang
i386 randconfig-i013-20230703   clang
i386 randconfig-i014-20230703   clang
i386 randconfig-i015-20230703   clang
i386 randconfig-i016-20230703   clang
i386 randconfig-r002-20230703   gcc  
i386 randconfig-r024-20230703   clang
loongarchallmodconfig   gcc  
loongarch allnoconfig   gcc  
loongarch   defconfig   gcc  
m68k allmodconfig   gcc  
m68k allyesconfig   gcc  
m68kdefconfig   gcc  
m68km5307c3_defconfig   gcc  
m68k randconfig-r002-20230703   gcc  
m68k randconfig-r021-20230703   gcc  
m68kstmark2_defconfig   gcc  
microblaze  defconfig   gcc  
microblaze   randconfig-r022-20230703   gcc  
mips allmodconfig   gcc  
mips allyesconfig   gcc  
mipsbcm63xx_defconfig   clang
mips cu1830-neo_defconfig   clang
nios2   defconfig   gcc  
parisc   allyesconfig   gcc  
parisc  defconfig   gcc  
parisc   randconfig-r003-20230703   gcc  
parisc   randconfig-r036-20230703   gcc  
parisc64defconfig   gcc  
powerpc  allmodconfig   gcc  
powerpc   allnoconfig   gcc  
powerpc   ebony_defconfig   clang
powerpc  pmac32_defconfig   clang
powerpc  ppc64e_defconfig   clang
riscvallmodconfig   gcc  
riscv

[powerpc:next] BUILD SUCCESS abaa02fc944f2f9f2c2e1925ddaceaf35c48528c

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
next
branch HEAD: abaa02fc944f2f9f2c2e1925ddaceaf35c48528c  powerpc: dts: 
turris1x.dts: Fix PCIe MEM size for pci2 node

elapsed time: 721m

configs tested: 92
configs skipped: 135

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

tested configs:
alphaallyesconfig   gcc  
alpha   defconfig   gcc  
arc  allyesconfig   gcc  
arc defconfig   gcc  
arm  allmodconfig   gcc  
arm  allyesconfig   gcc  
arm defconfig   clang
arm defconfig   gcc  
arm  ep93xx_defconfig   clang
arm lpc32xx_defconfig   clang
arm64allyesconfig   gcc  
arm64   defconfig   gcc  
arm64randconfig-r033-20230703   gcc  
cskydefconfig   gcc  
csky randconfig-r033-20230703   gcc  
hexagon  randconfig-r041-20230703   clang
hexagon  randconfig-r045-20230703   clang
i386 allyesconfig   gcc  
i386 buildonly-randconfig-r004-20230703   gcc  
i386 buildonly-randconfig-r005-20230703   gcc  
i386 buildonly-randconfig-r006-20230703   gcc  
i386  debian-10.3   gcc  
i386defconfig   gcc  
i386 randconfig-i001-20230703   gcc  
i386 randconfig-i002-20230703   gcc  
i386 randconfig-i003-20230703   gcc  
i386 randconfig-i004-20230703   gcc  
i386 randconfig-i005-20230703   gcc  
i386 randconfig-i006-20230703   gcc  
i386 randconfig-i011-20230703   clang
i386 randconfig-i012-20230703   clang
i386 randconfig-i013-20230703   clang
i386 randconfig-i014-20230703   clang
i386 randconfig-i015-20230703   clang
i386 randconfig-i016-20230703   clang
i386 randconfig-r035-20230703   gcc  
loongarchallmodconfig   gcc  
loongarch allnoconfig   gcc  
loongarch   defconfig   gcc  
loongarchrandconfig-r025-20230703   gcc  
m68k allmodconfig   gcc  
m68k allyesconfig   gcc  
m68kdefconfig   gcc  
mips allmodconfig   gcc  
mips allyesconfig   gcc  
mips cu1830-neo_defconfig   clang
mips randconfig-r001-20230703   clang
nios2   defconfig   gcc  
nios2randconfig-r024-20230703   gcc  
parisc   allyesconfig   gcc  
parisc  defconfig   gcc  
parisc64defconfig   gcc  
powerpc  allmodconfig   gcc  
powerpc   allnoconfig   gcc  
powerpc  mpc866_ads_defconfig   clang
powerpc  randconfig-r005-20230703   gcc  
powerpc  randconfig-r032-20230703   gcc  
riscvallmodconfig   gcc  
riscv allnoconfig   gcc  
riscvallyesconfig   gcc  
riscv   defconfig   gcc  
riscvrandconfig-r042-20230703   clang
riscv  rv32_defconfig   gcc  
s390 allmodconfig   gcc  
s390 allyesconfig   gcc  
s390defconfig   gcc  
s390 randconfig-r034-20230703   gcc  
s390 randconfig-r035-20230703   gcc  
s390 randconfig-r044-20230703   clang
sh   allmodconfig   gcc  
sparcallyesconfig   gcc  
sparc   defconfig   gcc  
sparc64  randconfig-r023-20230703   gcc  
sparc64  randconfig-r036-20230703   gcc  
um   allmodconfig   clang
umallnoconfig   clang
um   allyesconfig   clang
um   randconfig-r021-20230703   gcc  
x86_64   allyesconfig   gcc  
x86_64   buildonly-randconfig-r001-20230703   gcc  
x86_64   buildonly-randconfig-r002-20230703   gcc  
x86_64   buildonly-randconfig-r003-20230703   gcc  
x86_64  defconfig   gcc  
x86_64  kexec   gcc  
x86_64   randconfig-r015-20230703   clang
x86_64

Re: [PATCH v2 07/12] s390: add pte_free_defer() for pgtables sharing page

[Jason Gunthorpe]

On Mon, Jul 03, 2023 at 01:00:13PM +0200, Claudio Imbrenda wrote:
> On Fri, 30 Jun 2023 12:22:43 -0700 (PDT)
> Hugh Dickins  wrote:
> 
> [...]
> 
> > That's something I would have expected to be handled already via
> > mmu_notifiers, rather than buried inside the page table freeing.
> > 
> > If s390 is the only architecture to go that way, and could instead do
> > it via mmu_notifiers, then I think that will be more easily supported
> > in the long term.
> 
> I am very well aware of that, and in fact I've been working on
> exactly that for some time already. But it's a very complex minefield
> and therefore I'm proceeding *very* carefully. It will take quite some
> time before anything comes out.

Yes +1 on this please, creating your own arch cross connect with kvm
in the page table freers is really horrible..

Jason

Re: [PATCH 1/6] media: v4l2: Add audio capture and output support

[Shengjiu Wang]

Hi Sakari

On Fri, Jun 30, 2023 at 6:05 PM Sakari Ailus  wrote:

> Hi Shengjiu,
>
> On Thu, Jun 29, 2023 at 09:37:48AM +0800, Shengjiu Wang wrote:
> > Audio signal processing has the requirement for memory to
> > memory similar as Video.
> >
> > This patch is to add this support in v4l2 framework, defined
> > new buffer type V4L2_BUF_TYPE_AUDIO_CAPTURE and
> > V4L2_BUF_TYPE_AUDIO_OUTPUT, defined new format v4l2_audio_format
> > for audio case usage.
>
> Why are you proposing to add this to V4L2 framework instead of doing this
> within ALSA?
>
> Also cc Hans and Jacopo.


There is no such memory to memory interface defined in ALSA.  Seems
ALSA is not designed for M2M cases.

V4L2 is designed for video, radio, image, sdr, meta...,   so I think audio
can be
naturally added to the support scope.

Thanks.

Best regards
Shengjiu Wang

>


> >
> > The created audio device is named "/dev/audioX".
> >
> > Signed-off-by: Shengjiu Wang 
> > ---
> >  .../media/common/videobuf2/videobuf2-v4l2.c   |  4 ++
> >  drivers/media/v4l2-core/v4l2-dev.c| 17 ++
> >  drivers/media/v4l2-core/v4l2-ioctl.c  | 52 +++
> >  include/media/v4l2-dev.h  |  2 +
> >  include/media/v4l2-ioctl.h| 34 
> >  include/uapi/linux/videodev2.h| 19 +++
> >  6 files changed, 128 insertions(+)
> >
> > diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> > index c7a54d82a55e..12f2be2773a2 100644
> > --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> > +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> > @@ -785,6 +785,10 @@ int vb2_create_bufs(struct vb2_queue *q, struct
> v4l2_create_buffers *create)
> >   case V4L2_BUF_TYPE_META_OUTPUT:
> >   requested_sizes[0] = f->fmt.meta.buffersize;
> >   break;
> > + case V4L2_BUF_TYPE_AUDIO_CAPTURE:
> > + case V4L2_BUF_TYPE_AUDIO_OUTPUT:
> > + requested_sizes[0] = f->fmt.audio.buffersize;
> > + break;
> >   default:
> >   return -EINVAL;
> >   }
> > diff --git a/drivers/media/v4l2-core/v4l2-dev.c
> b/drivers/media/v4l2-core/v4l2-dev.c
> > index f81279492682..67484f4c6eaf 100644
> > --- a/drivers/media/v4l2-core/v4l2-dev.c
> > +++ b/drivers/media/v4l2-core/v4l2-dev.c
> > @@ -553,6 +553,7 @@ static void determine_valid_ioctls(struct
> video_device *vdev)
> >   bool is_tch = vdev->vfl_type == VFL_TYPE_TOUCH;
> >   bool is_meta = vdev->vfl_type == VFL_TYPE_VIDEO &&
> >  (vdev->device_caps & meta_caps);
> > + bool is_audio = vdev->vfl_type == VFL_TYPE_AUDIO;
> >   bool is_rx = vdev->vfl_dir != VFL_DIR_TX;
> >   bool is_tx = vdev->vfl_dir != VFL_DIR_RX;
> >   bool is_io_mc = vdev->device_caps & V4L2_CAP_IO_MC;
> > @@ -664,6 +665,19 @@ static void determine_valid_ioctls(struct
> video_device *vdev)
> >   SET_VALID_IOCTL(ops, VIDIOC_S_FMT, vidioc_s_fmt_meta_out);
> >   SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT,
> vidioc_try_fmt_meta_out);
> >   }
> > + if (is_audio && is_rx) {
> > + /* audio capture specific ioctls */
> > + SET_VALID_IOCTL(ops, VIDIOC_ENUM_FMT,
> vidioc_enum_fmt_audio_cap);
> > + SET_VALID_IOCTL(ops, VIDIOC_G_FMT, vidioc_g_fmt_audio_cap);
> > + SET_VALID_IOCTL(ops, VIDIOC_S_FMT, vidioc_s_fmt_audio_cap);
> > + SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT,
> vidioc_try_fmt_audio_cap);
> > + } else if (is_audio && is_tx) {
> > + /* audio output specific ioctls */
> > + SET_VALID_IOCTL(ops, VIDIOC_ENUM_FMT,
> vidioc_enum_fmt_audio_out);
> > + SET_VALID_IOCTL(ops, VIDIOC_G_FMT, vidioc_g_fmt_audio_out);
> > + SET_VALID_IOCTL(ops, VIDIOC_S_FMT, vidioc_s_fmt_audio_out);
> > + SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT,
> vidioc_try_fmt_audio_out);
> > + }
> >   if (is_vbi) {
> >   /* vbi specific ioctls */
> >   if ((is_rx && (ops->vidioc_g_fmt_vbi_cap ||
> > @@ -927,6 +941,9 @@ int __video_register_device(struct video_device
> *vdev,
> >   case VFL_TYPE_TOUCH:
> >   name_base = "v4l-touch";
> >   break;
> > + case VFL_TYPE_AUDIO:
> > + name_base = "audio";
> > + break;
> >   default:
> >   pr_err("%s called with unknown type: %d\n",
> >  __func__, type);
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> > index a858acea6547..26bc4b0d8ef0 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -188,6 +188,8 @@ const char *v4l2_type_names[] = {
> >   [V4L2_BUF_TYPE_SDR_OUTPUT] = "sdr-out",
> >   [V4L2_BUF_TYPE_META_CAPTURE]   = "meta-cap",
> >   [V4L2_BUF_TYPE_META_OUTPUT]= "meta-out",
> > + [V4L2_BUF_TYPE_AUDIO_CAPTURE]  

Re: Fwd: Memory corruption in multithreaded user space program while calling fork

[Greg KH]

On Mon, Jul 03, 2023 at 11:27:19AM -0700, Suren Baghdasaryan wrote:
> On Mon, Jul 3, 2023 at 11:08 AM Suren Baghdasaryan  wrote:
> >
> > On Mon, Jul 3, 2023 at 2:53 AM Linux regression tracking (Thorsten
> > Leemhuis)  wrote:
> > >
> > > On 02.07.23 14:27, Bagas Sanjaya wrote:
> > > > I notice a regression report on Bugzilla [1]. Quoting from it:
> > > >
> > > >> After upgrading to kernel version 6.4.0 from 6.3.9, I noticed frequent 
> > > >> but random crashes in a user space program.  After a lot of reduction, 
> > > >> I have come up with the following reproducer program:
> > > > [...]
> > > >> After tuning the various parameters for my computer, exit code 2, 
> > > >> which indicates that memory corruption was detected, occurs 
> > > >> approximately 99% of the time.  Exit code 1, which occurs 
> > > >> approximately 1% of the time, means it ran out of statically-allocated 
> > > >> memory before reproducing the issue, and increasing the memory usage 
> > > >> any more only leads to diminishing returns.  There is also something 
> > > >> like a 0.1% chance that it segfaults due to memory corruption 
> > > >> elsewhere than in the statically-allocated buffer.
> > > >>
> > > >> With this reproducer in hand, I was able to perform the following 
> > > >> bisection:
> > > > [...]
> > > >
> > > > See Bugzilla for the full thread.
> > >
> > > Additional details from
> > > https://bugzilla.kernel.org/show_bug.cgi?id=217624#c5 :
> > >
> > > ```
> > > I can confirm that v6.4 with 0bff0aaea03e2a3ed6bfa302155cca8a432a1829
> > > reverted no longer causes any memory corruption with either my
> > > reproducer or the original program.
> > > ```
> > >
> > > FWIW: 0bff0aaea03 ("x86/mm: try VMA lock-based page fault handling
> > > first") [merged for v6.4-rc1, authored by Suren Baghdasaryan [already 
> > > CCed]]
> > >
> > > That's the same commit that causes build problems with go:
> > >
> > > https://lore.kernel.org/all/dbdef34c-3a07-5951-e1ae-e9c6e3cdf...@kernel.org/
> >
> > Thanks! I'll investigate this later today. After discussing with
> > Andrew, we would like to disable CONFIG_PER_VMA_LOCK by default until
> > the issue is fixed. I'll post a patch shortly.
> 
> Posted at: 
> https://lore.kernel.org/all/20230703182150.2193578-1-sur...@google.com/

As that change fixes something in 6.4, why not cc: stable on it as well?

thanks,

greg k-h

Re: [PATCH] powerpc: powermac: Use of_get_cpu_hwid() to read CPU node 'reg'

[Christophe JAILLET]

Le 03/07/2023 à 07:26, Michael Ellerman a écrit :

On Sun, 19 Mar 2023 09:59:31 -0500, Rob Herring wrote:

Replace open coded reading of CPU nodes' "reg" properties with
of_get_cpu_hwid() dedicated for this purpose.




Applied to powerpc/next.

[1/1] powerpc: powermac: Use of_get_cpu_hwid() to read CPU node 'reg'
   https://git.kernel.org/powerpc/c/bc1cf75027585f8d87f94e464ee5909acf885a8c

cheers



Hi,

I guess, that it does not really matter, but shouldn't the 
of_node_put() be *after* the "reset_io = *rst;" statements to be 
absolutely safe?



(This change is in my backlog and I have apparently never proposed it)

CJ

Re: Fwd: Memory corruption in multithreaded user space program while calling fork

[Suren Baghdasaryan]

On Mon, Jul 3, 2023 at 11:08 AM Suren Baghdasaryan  wrote:
>
> On Mon, Jul 3, 2023 at 2:53 AM Linux regression tracking (Thorsten
> Leemhuis)  wrote:
> >
> > On 02.07.23 14:27, Bagas Sanjaya wrote:
> > > I notice a regression report on Bugzilla [1]. Quoting from it:
> > >
> > >> After upgrading to kernel version 6.4.0 from 6.3.9, I noticed frequent 
> > >> but random crashes in a user space program.  After a lot of reduction, I 
> > >> have come up with the following reproducer program:
> > > [...]
> > >> After tuning the various parameters for my computer, exit code 2, which 
> > >> indicates that memory corruption was detected, occurs approximately 99% 
> > >> of the time.  Exit code 1, which occurs approximately 1% of the time, 
> > >> means it ran out of statically-allocated memory before reproducing the 
> > >> issue, and increasing the memory usage any more only leads to 
> > >> diminishing returns.  There is also something like a 0.1% chance that it 
> > >> segfaults due to memory corruption elsewhere than in the 
> > >> statically-allocated buffer.
> > >>
> > >> With this reproducer in hand, I was able to perform the following 
> > >> bisection:
> > > [...]
> > >
> > > See Bugzilla for the full thread.
> >
> > Additional details from
> > https://bugzilla.kernel.org/show_bug.cgi?id=217624#c5 :
> >
> > ```
> > I can confirm that v6.4 with 0bff0aaea03e2a3ed6bfa302155cca8a432a1829
> > reverted no longer causes any memory corruption with either my
> > reproducer or the original program.
> > ```
> >
> > FWIW: 0bff0aaea03 ("x86/mm: try VMA lock-based page fault handling
> > first") [merged for v6.4-rc1, authored by Suren Baghdasaryan [already CCed]]
> >
> > That's the same commit that causes build problems with go:
> >
> > https://lore.kernel.org/all/dbdef34c-3a07-5951-e1ae-e9c6e3cdf...@kernel.org/
>
> Thanks! I'll investigate this later today. After discussing with
> Andrew, we would like to disable CONFIG_PER_VMA_LOCK by default until
> the issue is fixed. I'll post a patch shortly.

Posted at: 
https://lore.kernel.org/all/20230703182150.2193578-1-sur...@google.com/

>
> >
> > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > --
> > Everything you wanna know about Linux kernel regression tracking:
> > https://linux-regtracking.leemhuis.info/about/#tldr
> > If I did something stupid, please tell me, as explained on that page.
> >
> > #regzbot introduced: 0bff0aaea03e2a3

Re: Fwd: Memory corruption in multithreaded user space program while calling fork

[Suren Baghdasaryan]

On Mon, Jul 3, 2023 at 2:53 AM Linux regression tracking (Thorsten
Leemhuis)  wrote:
>
> On 02.07.23 14:27, Bagas Sanjaya wrote:
> > I notice a regression report on Bugzilla [1]. Quoting from it:
> >
> >> After upgrading to kernel version 6.4.0 from 6.3.9, I noticed frequent but 
> >> random crashes in a user space program.  After a lot of reduction, I have 
> >> come up with the following reproducer program:
> > [...]
> >> After tuning the various parameters for my computer, exit code 2, which 
> >> indicates that memory corruption was detected, occurs approximately 99% of 
> >> the time.  Exit code 1, which occurs approximately 1% of the time, means 
> >> it ran out of statically-allocated memory before reproducing the issue, 
> >> and increasing the memory usage any more only leads to diminishing 
> >> returns.  There is also something like a 0.1% chance that it segfaults due 
> >> to memory corruption elsewhere than in the statically-allocated buffer.
> >>
> >> With this reproducer in hand, I was able to perform the following 
> >> bisection:
> > [...]
> >
> > See Bugzilla for the full thread.
>
> Additional details from
> https://bugzilla.kernel.org/show_bug.cgi?id=217624#c5 :
>
> ```
> I can confirm that v6.4 with 0bff0aaea03e2a3ed6bfa302155cca8a432a1829
> reverted no longer causes any memory corruption with either my
> reproducer or the original program.
> ```
>
> FWIW: 0bff0aaea03 ("x86/mm: try VMA lock-based page fault handling
> first") [merged for v6.4-rc1, authored by Suren Baghdasaryan [already CCed]]
>
> That's the same commit that causes build problems with go:
>
> https://lore.kernel.org/all/dbdef34c-3a07-5951-e1ae-e9c6e3cdf...@kernel.org/

Thanks! I'll investigate this later today. After discussing with
Andrew, we would like to disable CONFIG_PER_VMA_LOCK by default until
the issue is fixed. I'll post a patch shortly.

>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
>
> #regzbot introduced: 0bff0aaea03e2a3

Re: [PATCH 1/6] media: v4l2: Add audio capture and output support

[Mark Brown]

On Mon, Jul 03, 2023 at 03:12:55PM +0200, Hans Verkuil wrote:

> My main concern is that these cross-subsystem drivers are a pain to
> maintain. So there have to be good reasons to do this.

> Also it is kind of weird to have to use the V4L2 API in userspace to
> deal with a specific audio conversion. Quite unexpected.

> But in the end, that's a decision I can't make.

> So I wait for that feedback. Note that if the decision is made that this
> can use V4L2, then there is quite a lot more that needs to be done:
> documentation, new compliance tests, etc. It's adding a new API, and that
> comes with additional work...

Absolutely, I agree with all of this - my impression was that the target
here would be bypass of audio streams to/from a v4l2 device, without
bouncing through an application layer.  If it's purely for audio usage
with no other tie to v4l2 then involving v4l2 does just seem like
complication.


signature.asc
Description: PGP signature

Re: [PATCH] powerpc: powermac: Use of_get_cpu_hwid() to read CPU node 'reg'

[Marion & Christophe JAILLET]

Le 03/07/2023 à 19:01, Christophe JAILLET a écrit :

Le 03/07/2023 à 07:26, Michael Ellerman a écrit :

On Sun, 19 Mar 2023 09:59:31 -0500, Rob Herring wrote:

Replace open coded reading of CPU nodes' "reg" properties with
of_get_cpu_hwid() dedicated for this purpose.




Applied to powerpc/next.

[1/1] powerpc: powermac: Use of_get_cpu_hwid() to read CPU node 'reg'
   
https://git.kernel.org/powerpc/c/bc1cf75027585f8d87f94e464ee5909acf885a8c


cheers



Hi,

I guess, that it does not really matter, but shouldn't the of_node_put() 
be *after* the "reset_io = *rst;" statements to be absolutely safe?



(This change is in my backlog and I have apparently never proposed it)


Well, in fact is was in:
https://lore.kernel.org/all/f2186955f310494f10990b5c402ada164d7834b8.1619188632.git.christophe.jail...@wanadoo.fr/



CJ

Re: [PATCH v2 07/12] s390: add pte_free_defer() for pgtables sharing page

[Gerald Schaefer]

On Thu, 29 Jun 2023 23:00:07 -0700 (PDT)
Hugh Dickins  wrote:

> On Thu, 29 Jun 2023, Gerald Schaefer wrote:
> > On Thu, 29 Jun 2023 12:22:24 -0300
> > Jason Gunthorpe  wrote:  
> > > On Wed, Jun 28, 2023 at 10:08:08PM -0700, Hugh Dickins wrote:  
> > > > On Wed, 28 Jun 2023, Gerald Schaefer wrote:
> > > > > 
> > > > > As discussed in the other thread, we would rather go with less 
> > > > > complexity,
> > > > > possibly switching to an approach w/o the list and fragment re-use in 
> > > > > the
> > > > > future. For now, as a first step in that direction, we can try with 
> > > > > not
> > > > > adding fragments back only for pte_free_defer(). Here is an adjusted
> > > > > version of your patch, copying most of your pte_free_defer() logic and
> > > > > also description, tested with LTP and all three of your patch series 
> > > > > applied:
> > > > 
> > > > Thanks, Gerald: I don't mind abandoning my 13/12 SLAB_TYPESAFE_BY_RCU
> > > > patch (posted with fewer Cc's to the s390 list last week), and switching
> > > > to your simpler who-cares-if-we-sometimes-don't-make-maximal-use-of-page
> > > > patch.
> > > > 
> > > > But I didn't get deep enough into it today to confirm it - and 
> > > > disappointed
> > > > that you've found it necessary to play with pt_frag_refcount in 
> > > > addition to
> > > > _refcount and HH bits.  No real problem with that, but my instinct says 
> > > > it
> > > > should be simpler.
> > 
> > Yes, I also found it a bit awkward, but it seemed "good and simple enough",
> > to have something to go forward with, while my instinct was in line with 
> > yours.
> >   
> > > 
> > > Is there any reason it should be any different at all from what PPC is
> > > doing?
> > > 
> > > I still think the right thing to do here is make the PPC code common
> > > (with Hugh's proposed RCU modification) and just use it in both
> > > arches  
> > 
> > With the current approach, we would not add back fragments _only_ for
> > the new pte_free_defer() path, while keeping our cleverness for the other
> > paths. Not having a good overview of the negative impact wrt potential
> > memory waste, I would rather take small steps, if possible.
> > 
> > If we later switch to never adding back fragments, of course we should
> > try to be in line with PPC implementation.  
> 
> I find myself half-agreeing with everyone.
> 
> I agree with Gerald that s390 should keep close to what it is already
> doing (except for adding pte_free_defer()): that changing its strategy
> and implementation to be much more like powerpc, is a job for some other
> occasion (and would depend on gathering data about how well each does).
> 
> But I agree with Jason that the powerpc solution we ended up with cut
> out a lot of unnecessary complication: it shifts the RCU delay from
> when pte_free_defer() is called, to when the shared page comes to be
> freed; which may be a lot later, and might not be welcome in a common
> path, but is quite okay for the uncommon pte_free_defer().

Ok, I guess I must admit that I completely ignored the latest progress in
the powerpc thread, and therefore was not up-to-date. Still had the older
approach in mind, where you also checked for pt_frag_refcount to avoid
double call_rcu().

The new approach sounds very reasonable, and I also like your latest
s390 patch from a first glance. Need to get more up-to-date with PageActive
and maybe also powerpc approach, and give this some proper review tomorrow.

> 
> And I agree with Alexander that pte_free_lower() and pte_free_upper()
> are better names than pte_free_now0() and pte_free_now1(): I was going
> to make that change, except all those functions disappear if we follow
> Jason's advice and switch the call_rcu() to when freeing the page.
> 
> (Lower and upper seem unambiguous to me: Gerald, does your confusion
> come just from the way they are shown the wrong way round in the PP AA
> diagram?  I corrected that in my patch, but you reverted it in yours.)

Ah yes, that could well be, and unfortunately I did not notice that you
fixed that in the comment. I only saw that you "fixed" the bit numbering
from 01234567 to 76543210, which I think is wrong on big-endian s390,
and therefore I simply removed that complete hunk.

But thanks a lot for pointing to that! We will certainly want to fix that
comment in a later patch, to reduce some or maybe all of the (at least
my) upper/lower confusion.

Re: [PATCH v2 0/2] send tlb_remove_table_smp_sync IPI only to necessary CPUs

[Peter Zijlstra]

On Thu, Jun 22, 2023 at 09:47:22AM -0300, Marcelo Tosatti wrote:

> > there's patches that cure the thp abuse of this.
> 
> The other case where the IPI can happen is:
> 
> CPU-0   CPU-1
> 
> tlb_remove_table
> tlb_remove_table_sync_one
> IPI
> local_irq_disable
> gup_fast
> local_irq_enable
> 
> 
> So its not only the THP case.

(your CPU-1 thing is wholly irrelevant)

Well, I know, but this case *should* be exceedingly rare. Last time
around I asked why you all were tripping this, you pointed at the THP
case.

The THP case should be fixed along the lines of Jann's original patches.

If you can trip this at any significant rate, then we should probably
look at a better allocation scheme. It means you're really low on
memory.

Re: [PATCH v2 2/2] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to MM CPUs

[Peter Zijlstra]

On Tue, Jun 20, 2023 at 05:46:18PM +0300, Yair Podemsky wrote:
> @@ -191,7 +191,13 @@ static void tlb_remove_table_smp_sync(void *arg)
>   /* Simply deliver the interrupt */
>  }
>  
> -void tlb_remove_table_sync_one(void)
> +#ifdef CONFIG_ARCH_HAS_CPUMASK_BITS
> +#define REMOVE_TABLE_IPI_MASK mm_cpumask(mm)
> +#else
> +#define REMOVE_TABLE_IPI_MASK cpu_online_mask
> +#endif /* CONFIG_ARCH_HAS_CPUMASK_BITS */
> +
> +void tlb_remove_table_sync_one(struct mm_struct *mm)
>  {
>   /*
>* This isn't an RCU grace period and hence the page-tables cannot be
> @@ -200,7 +206,8 @@ void tlb_remove_table_sync_one(void)
>* It is however sufficient for software page-table walkers that rely on
>* IRQ disabling.
>*/
> - smp_call_function(tlb_remove_table_smp_sync, NULL, 1);
> + on_each_cpu_mask(REMOVE_TABLE_IPI_MASK, tlb_remove_table_smp_sync,
> + NULL, true);

Aside from what Dave said about the REMOVE_TABLE_IPI_MASK thing, this
isn't right.

on_each_cpu_mask() includes the current cpu, while smp_call_function()
explicitly does not.

Yes, they all end up in smp_call_function_many_cond(), but the
on_each_cpu*() family will have SCF_RUN_LOCAL set, while the
smp_call_function*() family will not.

Re: [kvm-unit-tests v4 00/12] powerpc: updates, P10, PNV support

[Thomas Huth]

On 08/06/2023 09.58, Nicholas Piggin wrote:

Posting again, a couple of patches were merged and accounted for review
comments from last time.


Sorry for not being very responsive ... it's been a busy month.

Anyway, I've now merged the first 5 patches and the VPA test since they look 
fine to me.


As Joel already wrote, there is an issue with the sprs patch, I also get an 
error with the PIR register on the P8 box that I have access to as soon as I 
apply the "Specify SPRs with data rather than code" patch. It would be good 
to get that problem resolved before merging the remaining patches...


 Thomas

Re: [PATCH 1/6] media: v4l2: Add audio capture and output support

[Takashi Iwai]

On Mon, 03 Jul 2023 15:12:55 +0200,
Hans Verkuil wrote:
> 
> On 03/07/2023 14:53, Mark Brown wrote:
> > On Mon, Jul 03, 2023 at 02:07:10PM +0200, Takashi Iwai wrote:
> >> Shengjiu Wang wrote:
> > 
> >>> There is no such memory to memory interface defined in ALSA.  Seems
> >>> ALSA is not designed for M2M cases.
> > 
> >> There is no restriction to implement memory-to-memory capture in ALSA
> >> framework.  It'd be a matter of the setup of PCM capture source, and
> >> you can create a corresponding kcontrol element to switch the mode or
> >> assign a dedicated PCM substream, for example.  It's just that there
> >> was little demand for that.
> > 
> > Yeah, it's not a terrible idea.  We might use it more if we ever get
> > better support for DSP audio, routing between the DSP and external
> > devices if driven from the CPU would be a memory to memory thing.
> > 
> >> I'm not much against adding the audio capture feature to V4L2,
> >> though, if it really makes sense.  But creating a crafted /dev/audio*
> >> doesn't look like a great idea to me, at least.
> > 
> > I've still not looked at the code at all.
> 
> My main concern is that these cross-subsystem drivers are a pain to
> maintain. So there have to be good reasons to do this.
> 
> Also it is kind of weird to have to use the V4L2 API in userspace to
> deal with a specific audio conversion. Quite unexpected.
> 
> But in the end, that's a decision I can't make.
> 
> So I wait for that feedback. Note that if the decision is made that this
> can use V4L2, then there is quite a lot more that needs to be done:
> documentation, new compliance tests, etc. It's adding a new API, and that
> comes with additional work...

All agreed.  Especially in this case, it doesn't have to be in V4L2
API, as it seems.

(Though, the support of audio on V4L2 might be useful if it's closely
tied with the a stream.  But that's another story.)


thanks,

Takashi

Re: [kvm-unit-tests v4 03/12] powerpc: Abstract H_CEDE calls into a sleep functions

[Thomas Huth]

On 08/06/2023 09.58, Nicholas Piggin wrote:

This consolidates several implementations, and it no longer leaves
MSR[EE] enabled after the decrementer interrupt is handled, but
rather disables it on return.

The handler no longer allows a continuous ticking, but rather dec
has to be re-armed and EE re-enabled (e.g., via H_CEDE hcall) each
time.

Signed-off-by: Nicholas Piggin 
---
  lib/powerpc/asm/handlers.h  |  2 +-
  lib/powerpc/asm/ppc_asm.h   |  1 +
  lib/powerpc/asm/processor.h |  7 ++
  lib/powerpc/handlers.c  | 10 -
  lib/powerpc/processor.c | 43 +
  powerpc/sprs.c  |  6 +-
  powerpc/tm.c| 20 +
  7 files changed, 58 insertions(+), 31 deletions(-)

diff --git a/lib/powerpc/asm/handlers.h b/lib/powerpc/asm/handlers.h
index 64ba727a..e4a0cd45 100644
--- a/lib/powerpc/asm/handlers.h
+++ b/lib/powerpc/asm/handlers.h
@@ -3,6 +3,6 @@
  
  #include 
  
-void dec_except_handler(struct pt_regs *regs, void *data);

+void dec_handler_oneshot(struct pt_regs *regs, void *data);
  
  #endif /* _ASMPOWERPC_HANDLERS_H_ */

diff --git a/lib/powerpc/asm/ppc_asm.h b/lib/powerpc/asm/ppc_asm.h
index 1b85f6bb..6299ff53 100644
--- a/lib/powerpc/asm/ppc_asm.h
+++ b/lib/powerpc/asm/ppc_asm.h
@@ -36,6 +36,7 @@
  #endif /* __BYTE_ORDER__ */
  
  /* Machine State Register definitions: */

+#define MSR_EE_BIT 15  /* External Interrupts Enable */
  #define MSR_SF_BIT63  /* 64-bit mode */
  
  #endif /* _ASMPOWERPC_PPC_ASM_H */

diff --git a/lib/powerpc/asm/processor.h b/lib/powerpc/asm/processor.h
index ac001e18..ebfeff2b 100644
--- a/lib/powerpc/asm/processor.h
+++ b/lib/powerpc/asm/processor.h
@@ -20,6 +20,8 @@ static inline uint64_t get_tb(void)
  
  extern void delay(uint64_t cycles);

  extern void udelay(uint64_t us);
+extern void sleep_tb(uint64_t cycles);
+extern void usleep(uint64_t us);
  
  static inline void mdelay(uint64_t ms)

  {
@@ -27,4 +29,9 @@ static inline void mdelay(uint64_t ms)
udelay(1000);
  }
  
+static inline void msleep(uint64_t ms)

+{
+   usleep(ms * 1000);
+}
+
  #endif /* _ASMPOWERPC_PROCESSOR_H_ */
diff --git a/lib/powerpc/handlers.c b/lib/powerpc/handlers.c
index c8721e0a..296f14ff 100644
--- a/lib/powerpc/handlers.c
+++ b/lib/powerpc/handlers.c
@@ -9,15 +9,13 @@
  #include 
  #include 
  #include 
+#include 
  
  /*

   * Generic handler for decrementer exceptions (0x900)
- * Just reset the decrementer back to the value specified when registering the
- * handler
+ * Return with MSR[EE] disabled.
   */
-void dec_except_handler(struct pt_regs *regs __unused, void *data)
+void dec_handler_oneshot(struct pt_regs *regs, void *data)
  {
-   uint64_t dec = *((uint64_t *) data);
-
-   asm volatile ("mtdec %0" : : "r" (dec));
+   regs->msr &= ~(1UL << MSR_EE_BIT);
  }
diff --git a/lib/powerpc/processor.c b/lib/powerpc/processor.c
index 0550e4fc..aaf45b68 100644
--- a/lib/powerpc/processor.c
+++ b/lib/powerpc/processor.c
@@ -10,6 +10,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 
  
  static struct {

void (*func)(struct pt_regs *, void *data);
@@ -58,3 +60,44 @@ void udelay(uint64_t us)
  {
delay((us * tb_hz) / 100);
  }
+
+void sleep_tb(uint64_t cycles)
+{
+   uint64_t start, end, now;
+
+   start = now = get_tb();
+   end = start + cycles;
+
+   while (end > now) {
+   uint64_t left = end - now;
+
+   /* TODO: Could support large decrementer */
+   if (left > 0x7fff)
+   left = 0x7fff;
+
+   /* DEC won't fire until H_CEDE is called because EE=0 */
+   asm volatile ("mtdec %0" : : "r" (left));
+   handle_exception(0x900, _handler_oneshot, NULL);
+   /*
+* H_CEDE is called with MSR[EE] clear and enables it as part
+* of the hcall, returning with EE enabled. The dec interrupt
+* is then taken immediately and the handler disables EE.
+*
+* If H_CEDE returned for any other interrupt than dec
+* expiring, that is considered an unhandled interrupt and
+* the test case would be stopped.
+*/
+   if (hcall(H_CEDE) != H_SUCCESS) {
+   printf("H_CEDE failed\n");
+   abort();
+   }
+   handle_exception(0x900, NULL, NULL);
+
+   now = get_tb();
+   }
+}
+
+void usleep(uint64_t us)
+{
+   sleep_tb((us * tb_hz) / 100);
+}
diff --git a/powerpc/sprs.c b/powerpc/sprs.c
index 5cc1cd16..ba4ddee4 100644
--- a/powerpc/sprs.c
+++ b/powerpc/sprs.c
@@ -254,7 +254,6 @@ int main(int argc, char **argv)
0x1234567890ABCDEFULL, 0xFEDCBA0987654321ULL,
-1ULL,
};
-   static uint64_t decr = 0x7FFF; /* Max value */
  
  	for 

Re: [PATCH 1/6] media: v4l2: Add audio capture and output support

[Hans Verkuil]

On 03/07/2023 14:53, Mark Brown wrote:
> On Mon, Jul 03, 2023 at 02:07:10PM +0200, Takashi Iwai wrote:
>> Shengjiu Wang wrote:
> 
>>> There is no such memory to memory interface defined in ALSA.  Seems
>>> ALSA is not designed for M2M cases.
> 
>> There is no restriction to implement memory-to-memory capture in ALSA
>> framework.  It'd be a matter of the setup of PCM capture source, and
>> you can create a corresponding kcontrol element to switch the mode or
>> assign a dedicated PCM substream, for example.  It's just that there
>> was little demand for that.
> 
> Yeah, it's not a terrible idea.  We might use it more if we ever get
> better support for DSP audio, routing between the DSP and external
> devices if driven from the CPU would be a memory to memory thing.
> 
>> I'm not much against adding the audio capture feature to V4L2,
>> though, if it really makes sense.  But creating a crafted /dev/audio*
>> doesn't look like a great idea to me, at least.
> 
> I've still not looked at the code at all.

My main concern is that these cross-subsystem drivers are a pain to
maintain. So there have to be good reasons to do this.

Also it is kind of weird to have to use the V4L2 API in userspace to
deal with a specific audio conversion. Quite unexpected.

But in the end, that's a decision I can't make.

So I wait for that feedback. Note that if the decision is made that this
can use V4L2, then there is quite a lot more that needs to be done:
documentation, new compliance tests, etc. It's adding a new API, and that
comes with additional work...

Regards,

Hans

Re: [PATCH 1/6] media: v4l2: Add audio capture and output support

[Mark Brown]

On Mon, Jul 03, 2023 at 02:07:10PM +0200, Takashi Iwai wrote:
> Shengjiu Wang wrote:

> > There is no such memory to memory interface defined in ALSA.  Seems
> > ALSA is not designed for M2M cases.

> There is no restriction to implement memory-to-memory capture in ALSA
> framework.  It'd be a matter of the setup of PCM capture source, and
> you can create a corresponding kcontrol element to switch the mode or
> assign a dedicated PCM substream, for example.  It's just that there
> was little demand for that.

Yeah, it's not a terrible idea.  We might use it more if we ever get
better support for DSP audio, routing between the DSP and external
devices if driven from the CPU would be a memory to memory thing.

> I'm not much against adding the audio capture feature to V4L2,
> though, if it really makes sense.  But creating a crafted /dev/audio*
> doesn't look like a great idea to me, at least.

I've still not looked at the code at all.


signature.asc
Description: PGP signature

Re: [PATCH] powerpc/fadump: reset dump area size variable if memblock reserve fails

[Sourabh Jain]

On 03/07/23 16:59, Michael Ellerman wrote:

Sourabh Jain  writes:

Hello Michael,

Do you have any feedback or comments regarding this patch?

Thanks,
Sourabh

On 08/06/23 14:52, Sourabh Jain wrote:

If the memory reservation process (memblock_reserve) fails to reserve
the memory, the reserve dump variable retains the dump area size.
Consequently, the size of the dump area calculated for reservation
is displayed in /sys/kernel/fadump/mem_reserved.

To resolve this issue, the reserve dump area size variable is set to 0
if the memblock_reserve fails to reserve memory.

Fixes: 8255da95e545 ("powerpc/fadump: release all the memory above boot memory 
size")
Signed-off-by: Sourabh Jain 
Acked-by: Mahesh Salgaonkar 
---
   arch/powerpc/kernel/fadump.c | 1 +
   1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index ea0a073abd96..a8f2c3b2fa1e 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -641,6 +641,7 @@ int __init fadump_reserve_mem(void)
goto error_out;
   
   		if (memblock_reserve(base, size)) {

+   fw_dump.reserve_dump_area_size = 0;
pr_err("Failed to reserve memory!\n");
goto error_out;
}

Shouldn't reserve_dump_area_size be set to zero at error_out, which
already clears fadump_enabled?

return ret;
error_out:
fw_dump.fadump_enabled = 0;
return 0;
}


Otherwise the code immediately above will suffer from the same issue
won't it?

if (fw_dump.ops->fadump_setup_metadata &&
(fw_dump.ops->fadump_setup_metadata(_dump) < 0))
goto error_out;


Agree, resetting fw_dump.reserve_dump_area_size below error_out label is 
better.


Thanks for the review. I will send v2.

Sourabh Jain

Re: [PATCH 1/6] media: v4l2: Add audio capture and output support

[Takashi Iwai]

On Mon, 03 Jul 2023 11:54:22 +0200,
Shengjiu Wang wrote:
> 
> 
> Hi Sakari
> 
> On Fri, Jun 30, 2023 at 6:05 PM Sakari Ailus  wrote:
> 
> Hi Shengjiu,
>
> On Thu, Jun 29, 2023 at 09:37:48AM +0800, Shengjiu Wang wrote:
> > Audio signal processing has the requirement for memory to
> > memory similar as Video.
> >
> > This patch is to add this support in v4l2 framework, defined
> > new buffer type V4L2_BUF_TYPE_AUDIO_CAPTURE and
> > V4L2_BUF_TYPE_AUDIO_OUTPUT, defined new format v4l2_audio_format
> > for audio case usage.
>
> Why are you proposing to add this to V4L2 framework instead of doing this
> within ALSA?
>
> Also cc Hans and Jacopo.
> 
> There is no such memory to memory interface defined in ALSA.  Seems
> ALSA is not designed for M2M cases.

There is no restriction to implement memory-to-memory capture in ALSA
framework.  It'd be a matter of the setup of PCM capture source, and
you can create a corresponding kcontrol element to switch the mode or
assign a dedicated PCM substream, for example.  It's just that there
was little demand for that.

I'm not much against adding the audio capture feature to V4L2,
though, if it really makes sense.  But creating a crafted /dev/audio*
doesn't look like a great idea to me, at least.


thanks,

Takashi

Re: [PATCH v2] powerpc: allow PPC_EARLY_DEBUG_CPM only when SERIAL_CPM=y

[Michael Ellerman]

On Fri, 30 Jun 2023 22:47:12 -0700, Randy Dunlap wrote:
> In a randconfig with CONFIG_SERIAL_CPM=m and
> CONFIG_PPC_EARLY_DEBUG_CPM=y, there is a build error:
> ERROR: modpost: "udbg_putc" [drivers/tty/serial/cpm_uart/cpm_uart.ko] 
> undefined!
> 
> Prevent the build error by allowing PPC_EARLY_DEBUG_CPM only when
> SERIAL_CPM=y.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc: allow PPC_EARLY_DEBUG_CPM only when SERIAL_CPM=y
  https://git.kernel.org/powerpc/c/39f49684036d24af800ff194c33c7b2653c591d7

cheers

Re: [PATCH] powerpc: dts: turris1x.dts: Fix PCIe MEM size for pci2 node

[Michael Ellerman]

On Fri, 05 May 2023 19:28:18 +0200, Pali Rohár wrote:
> Freescale PCIe controllers on their PCIe Root Ports do not have any
> mappable PCI BAR allocate from PCIe MEM.
> 
> Information about 1MB window on BAR0 of PCIe Root Port was misleading
> because Freescale PCIe controllers have at BAR0 position different register
> PEXCSRBAR, and kernel correctly skipts BAR0 for these Freescale PCIe Root
> Ports.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc: dts: turris1x.dts: Fix PCIe MEM size for pci2 node
  https://git.kernel.org/powerpc/c/abaa02fc944f2f9f2c2e1925ddaceaf35c48528c

cheers

Re: [PATCH] powerpc: Include asm/nmi.c in mobility.c for watchdog_hardlockup_set_timeout_pct()

[Michael Ellerman]

On Thu, 29 Jun 2023 12:45:06 -0700, Douglas Anderson wrote:
> The powerpc/platforms/pseries/mobility.c calls
> watchdog_hardlockup_set_timeout_pct(), which is declared in
> . We used to automatically get  included, but
> that changed as of commit 7ca8fe94aa92 ("watchdog/hardlockup: define
> HARDLOCKUP_DETECTOR_ARCH"). Let's add the explicit include.
> 
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc: Include asm/nmi.c in mobility.c for 
watchdog_hardlockup_set_timeout_pct()
  https://git.kernel.org/powerpc/c/6cb44bef35ac11724ef22c5ae4f1bc607e2ef3d8

cheers

Re: [PATCH] powerpc: isa-bridge: Fix ISA mmapping when "ranges" is not present

[Michael Ellerman]

Christian Zigotzky  writes:
> On 03.07.23 07:21, Michael Ellerman wrote:
>> On Fri, 05 May 2023 12:18:17 -0500, Rob Herring wrote:
>>> Commit e4ab08be5b49 ("powerpc/isa-bridge: Remove open coded "ranges"
>>> parsing") broke PASemi Nemo board booting. The issue is the ISA I/O
>>> range was not getting mapped as the logic to handle no "ranges" was
>>> inverted. If phb_io_base_phys is non-zero, then the ISA range defaults
>>> to the first 64K of the PCI I/O space. phb_io_base_phys should only be 0
>>> when looking for a non-PCI ISA region.
>>>
>>> [...]
>> Applied to powerpc/fixes.
>>
>> [1/1] powerpc: isa-bridge: Fix ISA mmapping when "ranges" is not present
>>
>> https://git.kernel.org/powerpc/c/79de36042eecb684e0f748d17ba52f365fde0d65
>>
>> cheers
> Hello Michael,
>
> This patch has already been applied. Link: 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4927cb98f0eeaa5dbeac882e8372f4b16dc62624

Yes, it's actually the same commit. I'm just catching up on sending the
thanks emails. Sorry for the confusion.

cheers

Re: [PATCH] powerpc/fadump: reset dump area size variable if memblock reserve fails

[Michael Ellerman]

Sourabh Jain  writes:
> Hello Michael,
>
> Do you have any feedback or comments regarding this patch?
>
> Thanks,
> Sourabh
>
> On 08/06/23 14:52, Sourabh Jain wrote:
>> If the memory reservation process (memblock_reserve) fails to reserve
>> the memory, the reserve dump variable retains the dump area size.
>> Consequently, the size of the dump area calculated for reservation
>> is displayed in /sys/kernel/fadump/mem_reserved.
>>
>> To resolve this issue, the reserve dump area size variable is set to 0
>> if the memblock_reserve fails to reserve memory.
>>
>> Fixes: 8255da95e545 ("powerpc/fadump: release all the memory above boot 
>> memory size")
>> Signed-off-by: Sourabh Jain 
>> Acked-by: Mahesh Salgaonkar 
>> ---
>>   arch/powerpc/kernel/fadump.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
>> index ea0a073abd96..a8f2c3b2fa1e 100644
>> --- a/arch/powerpc/kernel/fadump.c
>> +++ b/arch/powerpc/kernel/fadump.c
>> @@ -641,6 +641,7 @@ int __init fadump_reserve_mem(void)
>>  goto error_out;
>>   
>>  if (memblock_reserve(base, size)) {
>> +fw_dump.reserve_dump_area_size = 0;
>>  pr_err("Failed to reserve memory!\n");
>>  goto error_out;
>>  }

Shouldn't reserve_dump_area_size be set to zero at error_out, which
already clears fadump_enabled?

return ret;
error_out:
fw_dump.fadump_enabled = 0;
return 0;
}


Otherwise the code immediately above will suffer from the same issue
won't it?

if (fw_dump.ops->fadump_setup_metadata &&
(fw_dump.ops->fadump_setup_metadata(_dump) < 0))
goto error_out;

cheers

Re: [PATCH v2 07/12] s390: add pte_free_defer() for pgtables sharing page

[Claudio Imbrenda]

On Fri, 30 Jun 2023 12:22:43 -0700 (PDT)
Hugh Dickins  wrote:

[...]

> That's something I would have expected to be handled already via
> mmu_notifiers, rather than buried inside the page table freeing.
> 
> If s390 is the only architecture to go that way, and could instead do
> it via mmu_notifiers, then I think that will be more easily supported
> in the long term.

I am very well aware of that, and in fact I've been working on
exactly that for some time already. But it's a very complex minefield
and therefore I'm proceeding *very* carefully. It will take quite some
time before anything comes out.

> 
> But I'm writing from a position of very great ignorance: advising
> KVM on s390 is many dimensions away from what I'm capable of.

fair enough, but in this case it doesn't mean that you are not right :)

> 
> > 
> > the point here is: we need that only for page_table_free_rcu(); all
> > other users of page_table_free() cannot act on guest page tables  
> 
> I might be wrong, but I think that most users of page_table_free()
> are merely freeing a page table which had to be allocated up front,
> but was then found unnecessary (maybe a racing task already inserted
> one): page tables which were never exposed to actual use.

that was my impression as well

> > (because we don't allow THP for KVM guests). and that is why
> > page_table_free() does not do gmap_unlink() currently.  
> 
> But THP collapse does (or did before this series) use it to free a
> page table which had been exposed to use.  The fact that s390 does

that is also my understanding

> not allow THP for KVM guests makes page_table_free(), and this new
> pte_free_defer(), safe for that; but it feels dangerously coincidental.

not really; my guess is that we _intentionally_ did not do anything
there, because we knew we did not need it, knowing well that
we would need it once we would want to support THP for guests.
so not a coincidence, but a conscious decision based, I guess, on
touching as little code as needed.

> 
> It's easy to imagine a future change being made, which would stumble
> over this issue.  I have imagined that pte_free_defer() will be useful
> in future, in the freeing of empty page tables: but s390 may pose a
> problem there - though perhaps no more of a problem than additionally
> needing to pass a virtual address down the stack.

yeah it can always be fixed later if we need to

> 
> >   
> > >   
> > > > 
> > > > or will it be used instead of page_table_free?
> > > 
> > > Not always; but yes, this case of removing a page table used
> > > page_table_free() before; but now, with the lighter locking, needs
> > > to keep the page table valid until the RCU grace period expires.  
> > 
> > so if I understand correctly your code will, sometimes, under some
> > circumstances, replace what page_table_free() does, but it will never
> > replace page_table_free_rcu()?
> > 
> > because in that case there would be no issues   
> 
> Yes, thanks for confirming: we have no issue here at present, but may
> do if use of pte_free_defer() is extended to other contexts in future.
> 
> Would it be appropriate to add a WARN_ON_ONCE around that
> > > > > + if (mm_alloc_pgste(mm)) {  
> in pte_free_defer()?

that's actually not a bad idea. should never happen, but... that's the
whole point of a WARN_ON after all

> 
> I ask that somewhat rhetorically: that block disappears in the later
> version I was working on last night (and will return to shortly), in
> which pte_free_defer() just sets a bit and calls page_table_free().
> 
> But I'd like to understand the possibilities better: does mm_alloc_pgste()
> correspond 1:1 to KVM guest on s390, or does it cover several different
> possibilities of which KVM guest is one, or am I just confused to be
> thinking there's any relationship?

this is... historically complicated (because of course it is)

in theory any process can allocate PGSTEs by having the right bits in
the ELF header (that's how QEMU does it currently). And QEMU will have
PGSTEs allocated even if it does not actually start any guests.

Then we have the vm.allocate_pgste sysctl knob; once enabled, it will
cause all processes to have PGSTEs allocated. This is how we handled
PGSTEs before we switched to ELF header bits.

So in summary: in __practice__ yes, only QEMU will have PGSTEs. But in
theory anything is possible and allowed.

> 
> Thanks,
> Hugh
> 
> >   
> > >   
> > > > 
> > > > this is actually quite important for KVM on s390
> > > 
> > > None of us are wanting to break KVM on s390: your guidance appreciated!
> > > 
> > > Thanks,
> > > Hugh  

Re: [PATCH v4 29/33] x86/mm: try VMA lock-based page fault handling first

[Jiri Slaby]

Cc Jacob Young (from kernel bugzilla)

On 30. 06. 23, 19:40, Suren Baghdasaryan wrote:

On Fri, Jun 30, 2023 at 1:43 AM Jiri Slaby  wrote:


On 30. 06. 23, 10:28, Jiri Slaby wrote:

  > 2348
clone3({flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 child_tid=0x7fcaa5882990, parent_tid=0x7fcaa5882990, exit_signal=0, 
stack=0x7fcaa5082000, stack_size=0x7ffe00, tls=0x7fcaa58826c0} => 
{parent_tid=[2351]}, 88) = 2351
  > 2350  <... clone3 resumed> => {parent_tid=[2372]}, 88) = 2372
  > 2351  <... clone3 resumed> => {parent_tid=[2354]}, 88) = 2354
  > 2351  <... clone3 resumed> => {parent_tid=[2357]}, 88) = 2357
  > 2354  <... clone3 resumed> => {parent_tid=[2355]}, 88) = 2355
  > 2355  <... clone3 resumed> => {parent_tid=[2370]}, 88) = 2370
  > 2370  mmap(NULL, 262144, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 
  > 2370  <... mmap resumed>)   = 0x7fca68249000
  > 2372  <... clone3 resumed> => {parent_tid=[2384]}, 88) = 2384
  > 2384  <... clone3 resumed> => {parent_tid=[2388]}, 88) = 2388
  > 2388  <... clone3 resumed> => {parent_tid=[2392]}, 88) = 2392
  > 2392  <... clone3 resumed> => {parent_tid=[2395]}, 88) = 2395
  > 2395  write(2, "runtime: marked free object in s"..., 36 

I.e. IIUC, all are threads (CLONE_VM) and thread 2370 mapped ANON
0x7fca68249000 - 0x7fca6827 and go in thread 2395 thinks for some
reason 0x7fca6824bec8 in that region is "bad".


Thanks for the analysis Jiri.
Is it possible from these logs to identify whether 2370 finished the
mmap operation before 2395 tried to access 0x7fca6824bec8? That access
has to happen only after mmap finishes mapping the region.


Hi,

it's hard to tell, but I assume so.

For now, forget about this go's overly complicated, hard to reproduce 
case and concentrate on the very nice reduced testcase in:

 https://bugzilla.kernel.org/show_bug.cgi?id=217624
;)

FWIW, I can reproduce using the test case too.

thanks,
--
js
suse labs

Re: [PATCH 1/6] media: v4l2: Add audio capture and output support

[Hans Verkuil]

On 03/07/2023 11:54, Shengjiu Wang wrote:
> Hi Sakari
> 
> On Fri, Jun 30, 2023 at 6:05 PM Sakari Ailus  > wrote:
> 
> Hi Shengjiu,
> 
> On Thu, Jun 29, 2023 at 09:37:48AM +0800, Shengjiu Wang wrote:
> > Audio signal processing has the requirement for memory to
> > memory similar as Video.
> >
> > This patch is to add this support in v4l2 framework, defined
> > new buffer type V4L2_BUF_TYPE_AUDIO_CAPTURE and
> > V4L2_BUF_TYPE_AUDIO_OUTPUT, defined new format v4l2_audio_format
> > for audio case usage.
> 
> Why are you proposing to add this to V4L2 framework instead of doing this
> within ALSA?
> 
> Also cc Hans and Jacopo.
> 
> 
> There is no such memory to memory interface defined in ALSA.  Seems
> ALSA is not designed for M2M cases.
> 
> V4L2 is designed for video, radio, image, sdr, meta...,   so I think audio 
> can be
> naturally added to the support scope.  

While I do not have an objection as such supporting this as part of V4L2, I do
want to know if the ALSA maintainers think it is OK as well before I am going
to spend time on this.

In principle the V4L2 mem2mem framework doesn't really care what type of data
is processed, it is just a matter of adding audio types (or reusing them from 
ALSA,
which is presumably the intention here).

Regards,

Hans

> 
> Thanks.
>  
> Best regards
> Shengjiu Wang
> 
>  
> 
> 
> >
> > The created audio device is named "/dev/audioX".
> >
> > Signed-off-by: Shengjiu Wang  >
> > ---
> >  .../media/common/videobuf2/videobuf2-v4l2.c   |  4 ++
> >  drivers/media/v4l2-core/v4l2-dev.c            | 17 ++
> >  drivers/media/v4l2-core/v4l2-ioctl.c          | 52 +++
> >  include/media/v4l2-dev.h                      |  2 +
> >  include/media/v4l2-ioctl.h                    | 34 
> >  include/uapi/linux/videodev2.h                | 19 +++
> >  6 files changed, 128 insertions(+)
> >
> > diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> > index c7a54d82a55e..12f2be2773a2 100644
> > --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> > +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> > @@ -785,6 +785,10 @@ int vb2_create_bufs(struct vb2_queue *q, struct 
> v4l2_create_buffers *create)
> >       case V4L2_BUF_TYPE_META_OUTPUT:
> >               requested_sizes[0] = f->fmt.meta.buffersize;
> >               break;
> > +     case V4L2_BUF_TYPE_AUDIO_CAPTURE:
> > +     case V4L2_BUF_TYPE_AUDIO_OUTPUT:
> > +             requested_sizes[0] = f->fmt.audio.buffersize;
> > +             break;
> >       default:
> >               return -EINVAL;
> >       }
> > diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
> b/drivers/media/v4l2-core/v4l2-dev.c
> > index f81279492682..67484f4c6eaf 100644
> > --- a/drivers/media/v4l2-core/v4l2-dev.c
> > +++ b/drivers/media/v4l2-core/v4l2-dev.c
> > @@ -553,6 +553,7 @@ static void determine_valid_ioctls(struct 
> video_device *vdev)
> >       bool is_tch = vdev->vfl_type == VFL_TYPE_TOUCH;
> >       bool is_meta = vdev->vfl_type == VFL_TYPE_VIDEO &&
> >                      (vdev->device_caps & meta_caps);
> > +     bool is_audio = vdev->vfl_type == VFL_TYPE_AUDIO;
> >       bool is_rx = vdev->vfl_dir != VFL_DIR_TX;
> >       bool is_tx = vdev->vfl_dir != VFL_DIR_RX;
> >       bool is_io_mc = vdev->device_caps & V4L2_CAP_IO_MC;
> > @@ -664,6 +665,19 @@ static void determine_valid_ioctls(struct 
> video_device *vdev)
> >               SET_VALID_IOCTL(ops, VIDIOC_S_FMT, vidioc_s_fmt_meta_out);
> >               SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT, 
> vidioc_try_fmt_meta_out);
> >       }
> > +     if (is_audio && is_rx) {
> > +             /* audio capture specific ioctls */
> > +             SET_VALID_IOCTL(ops, VIDIOC_ENUM_FMT, 
> vidioc_enum_fmt_audio_cap);
> > +             SET_VALID_IOCTL(ops, VIDIOC_G_FMT, 
> vidioc_g_fmt_audio_cap);
> > +             SET_VALID_IOCTL(ops, VIDIOC_S_FMT, 
> vidioc_s_fmt_audio_cap);
> > +             SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT, 
> vidioc_try_fmt_audio_cap);
> > +     } else if (is_audio && is_tx) {
> > +             /* audio output specific ioctls */
> > +             SET_VALID_IOCTL(ops, VIDIOC_ENUM_FMT, 
> vidioc_enum_fmt_audio_out);
> > +             SET_VALID_IOCTL(ops, VIDIOC_G_FMT, 
> vidioc_g_fmt_audio_out);
> > +             SET_VALID_IOCTL(ops, VIDIOC_S_FMT, 
> vidioc_s_fmt_audio_out);
> > +             SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT, 
> vidioc_try_fmt_audio_out);
> > +     }
> >       if (is_vbi) {
> >               /* vbi specific ioctls */
> >               if ((is_rx && (ops->vidioc_g_fmt_vbi_cap ||
> > @@ -927,6 +941,9 @@ int 

Re: [PATCH v4 29/33] x86/mm: try VMA lock-based page fault handling first

[Linux regression tracking (Thorsten Leemhuis)]

On 29.06.23 16:40, Jiri Slaby wrote:
> On 27. 02. 23, 18:36, Suren Baghdasaryan wrote:
>> Attempt VMA lock-based page fault handling first, and fall back to the
>> existing mmap_lock-based handling if that fails.
>>
>> Signed-off-by: Suren Baghdasaryan 
>> ---
>>   arch/x86/Kconfig    |  1 +
>>   arch/x86/mm/fault.c | 36 
>>   2 files changed, 37 insertions(+)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index a825bf031f49..df21fba77db1 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -27,6 +27,7 @@ config X86_64
>>   # Options that are inherently 64-bit kernel only:
>>   select ARCH_HAS_GIGANTIC_PAGE
>>   select ARCH_SUPPORTS_INT128 if CC_HAS_INT128
>> +    select ARCH_SUPPORTS_PER_VMA_LOCK
>>   select ARCH_USE_CMPXCHG_LOCKREF
>>   select HAVE_ARCH_SOFT_DIRTY
>>   select MODULES_USE_ELF_RELA
>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>> index a498ae1fbe66..e4399983c50c 100644
>> --- a/arch/x86/mm/fault.c
>> +++ b/arch/x86/mm/fault.c
>> @@ -19,6 +19,7 @@
>>   #include     /* faulthandler_disabled()    */
>>   #include     /*
>> efi_crash_gracefully_on_page_fault()*/
>>   #include 
>> +#include     /* find_and_lock_vma() */
>>     #include     /* boot_cpu_has, ...    */
>>   #include     /* dotraplinkage, ...    */
>> @@ -1333,6 +1334,38 @@ void do_user_addr_fault(struct pt_regs *regs,
>>   }
>>   #endif
>>   +#ifdef CONFIG_PER_VMA_LOCK
>> +    if (!(flags & FAULT_FLAG_USER))
>> +    goto lock_mmap;
>> +
>> +    vma = lock_vma_under_rcu(mm, address);
>> +    if (!vma)
>> +    goto lock_mmap;
>> +
>> +    if (unlikely(access_error(error_code, vma))) {
>> +    vma_end_read(vma);
>> +    goto lock_mmap;
>> +    }
>> +    fault = handle_mm_fault(vma, address, flags |
>> FAULT_FLAG_VMA_LOCK, regs);
>> +    vma_end_read(vma);
>> +
>> +    if (!(fault & VM_FAULT_RETRY)) {
>> +    count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
>> +    goto done;
>> +    }
>> +    count_vm_vma_lock_event(VMA_LOCK_RETRY);
> 
> This is apparently not strong enough as it causes go build failures like:

TWIMC & for the record: there is another report about trouble caused by
this change; for details see

https://bugzilla.kernel.org/show_bug.cgi?id=217624

And a "forward to devs and lists" thread about that report:

https://lore.kernel.org/all/facbfec3-837a-51ed-85fa-31021c17d...@gmail.com/

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

> [  409s] strconv
> [  409s] releasep: m=0x579e2000 m->p=0x5781c600 p->m=0x0 p->status=2
> [  409s] fatal error: releasep: invalid p state
> [  409s]
> 
> [  325s] hash/adler32
> [  325s] hash/crc32
> [  325s] cmd/internal/codesign
> [  336s] fatal error: runtime: out of memory
> 
> There are many kinds of similar errors. It happens in 1-3 out of 20
> builds only.
> 
> If I revert the commit on top of 6.4, they all dismiss. Any idea?
> 
> The downstream report:
> https://bugzilla.suse.com/show_bug.cgi?id=1212775
> 
>> +
>> +    /* Quick path to respond to signals */
>> +    if (fault_signal_pending(fault, regs)) {
>> +    if (!user_mode(regs))
>> +    kernelmode_fixup_or_oops(regs, error_code, address,
>> + SIGBUS, BUS_ADRERR,
>> + ARCH_DEFAULT_PKEY);
>> +    return;
>> +    }
>> +lock_mmap:
>> +#endif /* CONFIG_PER_VMA_LOCK */
>> +
>>   /*
>>    * Kernel-mode access to the user address space should only occur
>>    * on well-defined single instructions listed in the exception
>> @@ -1433,6 +1466,9 @@ void do_user_addr_fault(struct pt_regs *regs,
>>   }
>>     mmap_read_unlock(mm);
>> +#ifdef CONFIG_PER_VMA_LOCK
>> +done:
>> +#endif
>>   if (likely(!(fault & VM_FAULT_ERROR)))
>>   return;
>>   
> 
> thanks,

Re: Fwd: Memory corruption in multithreaded user space program while calling fork

[Linux regression tracking (Thorsten Leemhuis)]

On 02.07.23 14:27, Bagas Sanjaya wrote:
> I notice a regression report on Bugzilla [1]. Quoting from it:
> 
>> After upgrading to kernel version 6.4.0 from 6.3.9, I noticed frequent but 
>> random crashes in a user space program.  After a lot of reduction, I have 
>> come up with the following reproducer program:
> [...]
>> After tuning the various parameters for my computer, exit code 2, which 
>> indicates that memory corruption was detected, occurs approximately 99% of 
>> the time.  Exit code 1, which occurs approximately 1% of the time, means it 
>> ran out of statically-allocated memory before reproducing the issue, and 
>> increasing the memory usage any more only leads to diminishing returns.  
>> There is also something like a 0.1% chance that it segfaults due to memory 
>> corruption elsewhere than in the statically-allocated buffer.
>>
>> With this reproducer in hand, I was able to perform the following bisection:
> [...]
>
> See Bugzilla for the full thread.

Additional details from
https://bugzilla.kernel.org/show_bug.cgi?id=217624#c5 :

```
I can confirm that v6.4 with 0bff0aaea03e2a3ed6bfa302155cca8a432a1829
reverted no longer causes any memory corruption with either my
reproducer or the original program.
```

FWIW: 0bff0aaea03 ("x86/mm: try VMA lock-based page fault handling
first") [merged for v6.4-rc1, authored by Suren Baghdasaryan [already CCed]]

That's the same commit that causes build problems with go:

https://lore.kernel.org/all/dbdef34c-3a07-5951-e1ae-e9c6e3cdf...@kernel.org/

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

#regzbot introduced: 0bff0aaea03e2a3

[PATCH v2 6/9] powerpc/kuap: Use MMU_FTR_KUAP on all and refactor disabling kuap

[Christophe Leroy]

All but book3s/64 use a static branch key for disabling kuap.
book3s/64 uses an mmu feature.

Refactor all targets to use MMU_FTR_KUAP like book3s/64.

For PPC32 that implies updating mmu features fixups once KUAP
has been initialised.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/book3s/32/kup.h |  9 -
 arch/powerpc/include/asm/book3s/64/kup.h |  5 -
 arch/powerpc/include/asm/kup.h   | 11 +++
 arch/powerpc/include/asm/nohash/32/kup-8xx.h |  9 -
 arch/powerpc/include/asm/nohash/kup-booke.h  |  8 
 arch/powerpc/kernel/cputable.c   |  4 
 arch/powerpc/mm/book3s32/kuap.c  |  5 +
 arch/powerpc/mm/init_32.c|  2 ++
 arch/powerpc/mm/nohash/kup.c |  6 +-
 9 files changed, 19 insertions(+), 40 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/32/kup.h 
b/arch/powerpc/include/asm/book3s/32/kup.h
index 0da0dea76c47..4ca6122ef0e1 100644
--- a/arch/powerpc/include/asm/book3s/32/kup.h
+++ b/arch/powerpc/include/asm/book3s/32/kup.h
@@ -9,10 +9,6 @@
 
 #ifndef __ASSEMBLY__
 
-#include 
-
-extern struct static_key_false disable_kuap_key;
-
 #ifdef CONFIG_PPC_KUAP
 
 #include 
@@ -20,11 +16,6 @@ extern struct static_key_false disable_kuap_key;
 #define KUAP_NONE  (~0UL)
 #define KUAP_ALL   (~1UL)
 
-static __always_inline bool kuap_is_disabled(void)
-{
-   return static_branch_unlikely(_kuap_key);
-}
-
 static inline void kuap_lock_one(unsigned long addr)
 {
mtsr(mfsr(addr) | SR_KS, addr);
diff --git a/arch/powerpc/include/asm/book3s/64/kup.h 
b/arch/powerpc/include/asm/book3s/64/kup.h
index 72fc4263ed26..a014f4d9a2aa 100644
--- a/arch/powerpc/include/asm/book3s/64/kup.h
+++ b/arch/powerpc/include/asm/book3s/64/kup.h
@@ -230,11 +230,6 @@ static inline u64 current_thread_iamr(void)
 
 #ifdef CONFIG_PPC_KUAP
 
-static __always_inline bool kuap_is_disabled(void)
-{
-   return !mmu_has_feature(MMU_FTR_KUAP);
-}
-
 static inline void kuap_user_restore(struct pt_regs *regs)
 {
bool restore_amr = false, restore_iamr = false;
diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
index 24cde16c4fbe..bab161b609c1 100644
--- a/arch/powerpc/include/asm/kup.h
+++ b/arch/powerpc/include/asm/kup.h
@@ -6,6 +6,12 @@
 #define KUAP_WRITE 2
 #define KUAP_READ_WRITE(KUAP_READ | KUAP_WRITE)
 
+#ifndef __ASSEMBLY__
+#include 
+
+static __always_inline bool kuap_is_disabled(void);
+#endif
+
 #ifdef CONFIG_PPC_BOOK3S_64
 #include 
 #endif
@@ -41,6 +47,11 @@ void setup_kuep(bool disabled);
 
 #ifdef CONFIG_PPC_KUAP
 void setup_kuap(bool disabled);
+
+static __always_inline bool kuap_is_disabled(void)
+{
+   return !mmu_has_feature(MMU_FTR_KUAP);
+}
 #else
 static inline void setup_kuap(bool disabled) { }
 
diff --git a/arch/powerpc/include/asm/nohash/32/kup-8xx.h 
b/arch/powerpc/include/asm/nohash/32/kup-8xx.h
index a372cd822887..d0601859c45a 100644
--- a/arch/powerpc/include/asm/nohash/32/kup-8xx.h
+++ b/arch/powerpc/include/asm/nohash/32/kup-8xx.h
@@ -9,17 +9,8 @@
 
 #ifndef __ASSEMBLY__
 
-#include 
-
 #include 
 
-extern struct static_key_false disable_kuap_key;
-
-static __always_inline bool kuap_is_disabled(void)
-{
-   return static_branch_unlikely(_kuap_key);
-}
-
 static inline void __kuap_save_and_lock(struct pt_regs *regs)
 {
regs->kuap = mfspr(SPRN_MD_AP);
diff --git a/arch/powerpc/include/asm/nohash/kup-booke.h 
b/arch/powerpc/include/asm/nohash/kup-booke.h
index 71182cbe20c3..8e4734c8fef1 100644
--- a/arch/powerpc/include/asm/nohash/kup-booke.h
+++ b/arch/powerpc/include/asm/nohash/kup-booke.h
@@ -13,18 +13,10 @@
 
 #else
 
-#include 
 #include 
 
 #include 
 
-extern struct static_key_false disable_kuap_key;
-
-static __always_inline bool kuap_is_disabled(void)
-{
-   return static_branch_unlikely(_kuap_key);
-}
-
 static inline void __kuap_lock(void)
 {
mtspr(SPRN_PID, 0);
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 8a32bffefa5b..e97a0fd0ae90 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -75,6 +75,10 @@ static struct cpu_spec * __init setup_cpu_spec(unsigned long 
offset,
t->cpu_features |= old.cpu_features & CPU_FTR_PMAO_BUG;
}
 
+   /* Set kuap ON at startup, will be disabled later if cmdline has 
'nosmap' */
+   if (IS_ENABLED(CONFIG_PPC_KUAP) && IS_ENABLED(CONFIG_PPC32))
+   t->mmu_features |= MMU_FTR_KUAP;
+
*PTRRELOC(_cpu_spec) = _cpu_spec;
 
/*
diff --git a/arch/powerpc/mm/book3s32/kuap.c b/arch/powerpc/mm/book3s32/kuap.c
index 28676cabb005..24c1c686e6b9 100644
--- a/arch/powerpc/mm/book3s32/kuap.c
+++ b/arch/powerpc/mm/book3s32/kuap.c
@@ -3,9 +3,6 @@
 #include 
 #include 
 
-struct static_key_false disable_kuap_key;
-EXPORT_SYMBOL(disable_kuap_key);
-
 void kuap_lock_all_ool(void)
 {
kuap_lock_all();
@@ -30,7 +27,7 @@ void 

[PATCH v2 8/9] powerpc/kuap: KUAP enabling/disabling functions must be __always_inline

[Christophe Leroy]

Objtool reports following warnings:

  arch/powerpc/kernel/signal_32.o: warning: objtool:
__prevent_user_access.constprop.0+0x4 (.text+0x4):
redundant UACCESS disable

  arch/powerpc/kernel/signal_32.o: warning: objtool: user_access_begin+0x2c
(.text+0x4c): return with UACCESS enabled

  arch/powerpc/kernel/signal_32.o: warning: objtool: handle_rt_signal32+0x188
(.text+0x360): call to __prevent_user_access.constprop.0() with UACCESS 
enabled

  arch/powerpc/kernel/signal_32.o: warning: objtool: handle_signal32+0x150
(.text+0x4d4): call to __prevent_user_access.constprop.0() with UACCESS 
enabled

This is due to some KUAP enabling/disabling functions being outline
allthough they are marked inline. Use __always_inline instead.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/book3s/32/kup.h | 18 +++
 arch/powerpc/include/asm/book3s/64/kup.h | 23 ++--
 arch/powerpc/include/asm/kup.h   | 16 +++---
 arch/powerpc/include/asm/nohash/32/kup-8xx.h | 20 -
 arch/powerpc/include/asm/nohash/kup-booke.h  | 22 +--
 arch/powerpc/include/asm/uaccess.h   |  6 ++---
 6 files changed, 53 insertions(+), 52 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/32/kup.h 
b/arch/powerpc/include/asm/book3s/32/kup.h
index 5d4f787244d5..f40a210bf1bb 100644
--- a/arch/powerpc/include/asm/book3s/32/kup.h
+++ b/arch/powerpc/include/asm/book3s/32/kup.h
@@ -15,19 +15,19 @@
 
 #define KUAP_NONE  (~0UL)
 
-static inline void uaccess_end_32s(unsigned long addr)
+static __always_inline void uaccess_end_32s(unsigned long addr)
 {
mtsr(mfsr(addr) | SR_KS, addr);
isync();/* Context sync required after mtsr() */
 }
 
-static inline void uaccess_begin_32s(unsigned long addr)
+static __always_inline void uaccess_begin_32s(unsigned long addr)
 {
mtsr(mfsr(addr) & ~SR_KS, addr);
isync();/* Context sync required after mtsr() */
 }
 
-static inline void __kuap_save_and_lock(struct pt_regs *regs)
+static __always_inline void __kuap_save_and_lock(struct pt_regs *regs)
 {
unsigned long kuap = current->thread.kuap;
 
@@ -40,11 +40,11 @@ static inline void __kuap_save_and_lock(struct pt_regs 
*regs)
 }
 #define __kuap_save_and_lock __kuap_save_and_lock
 
-static inline void kuap_user_restore(struct pt_regs *regs)
+static __always_inline void kuap_user_restore(struct pt_regs *regs)
 {
 }
 
-static inline void __kuap_kernel_restore(struct pt_regs *regs, unsigned long 
kuap)
+static __always_inline void __kuap_kernel_restore(struct pt_regs *regs, 
unsigned long kuap)
 {
if (unlikely(kuap != KUAP_NONE)) {
current->thread.kuap = KUAP_NONE;
@@ -59,7 +59,7 @@ static inline void __kuap_kernel_restore(struct pt_regs 
*regs, unsigned long kua
uaccess_begin_32s(regs->kuap);
 }
 
-static inline unsigned long __kuap_get_and_assert_locked(void)
+static __always_inline unsigned long __kuap_get_and_assert_locked(void)
 {
unsigned long kuap = current->thread.kuap;
 
@@ -94,7 +94,7 @@ static __always_inline void __prevent_user_access(unsigned 
long dir)
uaccess_end_32s(kuap);
 }
 
-static inline unsigned long __prevent_user_access_return(void)
+static __always_inline unsigned long __prevent_user_access_return(void)
 {
unsigned long flags = current->thread.kuap;
 
@@ -106,7 +106,7 @@ static inline unsigned long 
__prevent_user_access_return(void)
return flags;
 }
 
-static inline void __restore_user_access(unsigned long flags)
+static __always_inline void __restore_user_access(unsigned long flags)
 {
if (flags != KUAP_NONE) {
current->thread.kuap = flags;
@@ -114,7 +114,7 @@ static inline void __restore_user_access(unsigned long 
flags)
}
 }
 
-static inline bool
+static __always_inline bool
 __bad_kuap_fault(struct pt_regs *regs, unsigned long address, bool is_write)
 {
unsigned long kuap = regs->kuap;
diff --git a/arch/powerpc/include/asm/book3s/64/kup.h 
b/arch/powerpc/include/asm/book3s/64/kup.h
index a014f4d9a2aa..497a7bd31ecc 100644
--- a/arch/powerpc/include/asm/book3s/64/kup.h
+++ b/arch/powerpc/include/asm/book3s/64/kup.h
@@ -213,14 +213,14 @@ extern u64 __ro_after_init default_iamr;
  * access restrictions. Because of this ignore AMR value when accessing
  * userspace via kernel thread.
  */
-static inline u64 current_thread_amr(void)
+static __always_inline u64 current_thread_amr(void)
 {
if (current->thread.regs)
return current->thread.regs->amr;
return default_amr;
 }
 
-static inline u64 current_thread_iamr(void)
+static __always_inline u64 current_thread_iamr(void)
 {
if (current->thread.regs)
return current->thread.regs->iamr;
@@ -230,7 +230,7 @@ static inline u64 current_thread_iamr(void)
 
 #ifdef CONFIG_PPC_KUAP
 
-static inline void kuap_user_restore(struct pt_regs *regs)
+static __always_inline void 

[PATCH v2 4/9] powerpc/features: Add capability to update mmu features later

[Christophe Leroy]

On powerpc32, features fixup is performed very early and that's too
early to read the cmdline and take into account 'nosmap' parameter.

On the other hand, no userspace access is performed that early and
KUAP feature fixup can be performed later.

Add a function to update mmu features. The function is passed a
mask with the features that can be updated.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/feature-fixups.h |  1 +
 arch/powerpc/lib/feature-fixups.c | 31 ---
 2 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/feature-fixups.h 
b/arch/powerpc/include/asm/feature-fixups.h
index ac605fc369c4..77824bd289a3 100644
--- a/arch/powerpc/include/asm/feature-fixups.h
+++ b/arch/powerpc/include/asm/feature-fixups.h
@@ -292,6 +292,7 @@ extern long __start___barrier_nospec_fixup, 
__stop___barrier_nospec_fixup;
 extern long __start__btb_flush_fixup, __stop__btb_flush_fixup;
 
 void apply_feature_fixups(void);
+void update_mmu_feature_fixups(unsigned long mask);
 void setup_feature_keys(void);
 #endif
 
diff --git a/arch/powerpc/lib/feature-fixups.c 
b/arch/powerpc/lib/feature-fixups.c
index 80def1c2afcb..4f82581ca203 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -67,7 +67,8 @@ static int patch_alt_instruction(u32 *src, u32 *dest, u32 
*alt_start, u32 *alt_e
return 0;
 }
 
-static int patch_feature_section(unsigned long value, struct fixup_entry *fcur)
+static int patch_feature_section_mask(unsigned long value, unsigned long mask,
+ struct fixup_entry *fcur)
 {
u32 *start, *end, *alt_start, *alt_end, *src, *dest;
 
@@ -79,7 +80,7 @@ static int patch_feature_section(unsigned long value, struct 
fixup_entry *fcur)
if ((alt_end - alt_start) > (end - start))
return 1;
 
-   if ((value & fcur->mask) == fcur->value)
+   if ((value & fcur->mask & mask) == (fcur->value & mask))
return 0;
 
src = alt_start;
@@ -97,7 +98,8 @@ static int patch_feature_section(unsigned long value, struct 
fixup_entry *fcur)
return 0;
 }
 
-void do_feature_fixups(unsigned long value, void *fixup_start, void *fixup_end)
+static void do_feature_fixups_mask(unsigned long value, unsigned long mask,
+  void *fixup_start, void *fixup_end)
 {
struct fixup_entry *fcur, *fend;
 
@@ -105,7 +107,7 @@ void do_feature_fixups(unsigned long value, void 
*fixup_start, void *fixup_end)
fend = fixup_end;
 
for (; fcur < fend; fcur++) {
-   if (patch_feature_section(value, fcur)) {
+   if (patch_feature_section_mask(value, mask, fcur)) {
WARN_ON(1);
printk("Unable to patch feature section at %p - %p" \
" with %p - %p\n",
@@ -117,6 +119,11 @@ void do_feature_fixups(unsigned long value, void 
*fixup_start, void *fixup_end)
}
 }
 
+void do_feature_fixups(unsigned long value, void *fixup_start, void *fixup_end)
+{
+   do_feature_fixups_mask(value, ~0, fixup_start, fixup_end);
+}
+
 #ifdef CONFIG_PPC_BARRIER_NOSPEC
 static bool is_fixup_addr_valid(void *dest, size_t size)
 {
@@ -651,6 +658,17 @@ void __init apply_feature_fixups(void)
do_final_fixups();
 }
 
+void __init update_mmu_feature_fixups(unsigned long mask)
+{
+   saved_mmu_features &= ~mask;
+   saved_mmu_features |= cur_cpu_spec->mmu_features & mask;
+
+   do_feature_fixups_mask(cur_cpu_spec->mmu_features, mask,
+  PTRRELOC(&__start___mmu_ftr_fixup),
+  PTRRELOC(&__stop___mmu_ftr_fixup));
+   mmu_feature_keys_init();
+}
+
 void __init setup_feature_keys(void)
 {
/*
@@ -683,6 +701,11 @@ late_initcall(check_features);
 #define check(x)   \
if (!(x)) printk("feature-fixups: test failed at line %d\n", __LINE__);
 
+static int patch_feature_section(unsigned long value, struct fixup_entry *fcur)
+{
+   return patch_feature_section_mask(value, ~0, fcur);
+}
+
 /* This must be after the text it fixes up, vmlinux.lds.S enforces that atm */
 static struct fixup_entry fixup;
 
-- 
2.41.0

[PATCH v2 3/9] powerpc/kuap: Fold kuep_is_disabled() into its only user

[Christophe Leroy]

kuep_is_disabled() was introduced by commit 91bb30822a2e ("powerpc/32s:
Refactor update of user segment registers") but then all users but one
were removed by commit 526d4a4c77ae ("powerpc/32s: Do kuep_lock() and
kuep_unlock() in assembly").

Fold kuep_is_disabled() into init_new_context() which is its only user.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/book3s/32/kup.h | 5 -
 arch/powerpc/mm/book3s32/mmu_context.c   | 2 +-
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/32/kup.h 
b/arch/powerpc/include/asm/book3s/32/kup.h
index 466a19cfb4df..0da0dea76c47 100644
--- a/arch/powerpc/include/asm/book3s/32/kup.h
+++ b/arch/powerpc/include/asm/book3s/32/kup.h
@@ -13,11 +13,6 @@
 
 extern struct static_key_false disable_kuap_key;
 
-static __always_inline bool kuep_is_disabled(void)
-{
-   return !IS_ENABLED(CONFIG_PPC_KUEP);
-}
-
 #ifdef CONFIG_PPC_KUAP
 
 #include 
diff --git a/arch/powerpc/mm/book3s32/mmu_context.c 
b/arch/powerpc/mm/book3s32/mmu_context.c
index 269a3eb25a73..1922f9a6b058 100644
--- a/arch/powerpc/mm/book3s32/mmu_context.c
+++ b/arch/powerpc/mm/book3s32/mmu_context.c
@@ -71,7 +71,7 @@ int init_new_context(struct task_struct *t, struct mm_struct 
*mm)
mm->context.id = __init_new_context();
mm->context.sr0 = CTX_TO_VSID(mm->context.id, 0);
 
-   if (!kuep_is_disabled())
+   if (IS_ENABLED(CONFIG_PPC_KUEP))
mm->context.sr0 |= SR_NX;
if (!kuap_is_disabled())
mm->context.sr0 |= SR_KS;
-- 
2.41.0

[PATCH v2 5/9] powerpc/kuap: MMU_FTR_BOOK3S_KUAP becomes MMU_FTR_KUAP

[Christophe Leroy]

In order to reuse MMU_FTR_BOOK3S_KUAP for other targets than BOOK3S,
rename it MMU_FTR_KUAP.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/book3s/64/hash-pkey.h |  2 +-
 arch/powerpc/include/asm/book3s/64/kup.h   | 18 +-
 arch/powerpc/include/asm/mmu.h |  4 ++--
 arch/powerpc/kernel/syscall.c  |  2 +-
 arch/powerpc/mm/book3s64/pkeys.c   |  2 +-
 5 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/hash-pkey.h 
b/arch/powerpc/include/asm/book3s/64/hash-pkey.h
index f1e60d579f6c..6c5564c4fae4 100644
--- a/arch/powerpc/include/asm/book3s/64/hash-pkey.h
+++ b/arch/powerpc/include/asm/book3s/64/hash-pkey.h
@@ -24,7 +24,7 @@ static inline u64 pte_to_hpte_pkey_bits(u64 pteflags, 
unsigned long flags)
((pteflags & H_PTE_PKEY_BIT1) ? HPTE_R_KEY_BIT1 : 0x0UL) |
((pteflags & H_PTE_PKEY_BIT0) ? HPTE_R_KEY_BIT0 : 0x0UL));
 
-   if (mmu_has_feature(MMU_FTR_BOOK3S_KUAP) ||
+   if (mmu_has_feature(MMU_FTR_KUAP) ||
mmu_has_feature(MMU_FTR_BOOK3S_KUEP)) {
if ((pte_pkey == 0) && (flags & HPTE_USE_KERNEL_KEY))
return HASH_DEFAULT_KERNEL_KEY;
diff --git a/arch/powerpc/include/asm/book3s/64/kup.h 
b/arch/powerpc/include/asm/book3s/64/kup.h
index 2a7bd3ecc556..72fc4263ed26 100644
--- a/arch/powerpc/include/asm/book3s/64/kup.h
+++ b/arch/powerpc/include/asm/book3s/64/kup.h
@@ -31,7 +31,7 @@
mfspr   \gpr2, SPRN_AMR
cmpd\gpr1, \gpr2
beq 99f
-   END_MMU_FTR_SECTION_NESTED_IFCLR(MMU_FTR_BOOK3S_KUAP, 68)
+   END_MMU_FTR_SECTION_NESTED_IFCLR(MMU_FTR_KUAP, 68)
 
isync
mtspr   SPRN_AMR, \gpr1
@@ -78,7 +78,7 @@
 * No need to restore IAMR when returning to kernel space.
 */
 100:
-   END_MMU_FTR_SECTION_NESTED_IFSET(MMU_FTR_BOOK3S_KUAP, 67)
+   END_MMU_FTR_SECTION_NESTED_IFSET(MMU_FTR_KUAP, 67)
 #endif
 .endm
 
@@ -91,7 +91,7 @@
LOAD_REG_IMMEDIATE(\gpr2, AMR_KUAP_BLOCKED)
 999:   tdne\gpr1, \gpr2
EMIT_WARN_ENTRY 999b, __FILE__, __LINE__, (BUGFLAG_WARNING | 
BUGFLAG_ONCE)
-   END_MMU_FTR_SECTION_NESTED_IFSET(MMU_FTR_BOOK3S_KUAP, 67)
+   END_MMU_FTR_SECTION_NESTED_IFSET(MMU_FTR_KUAP, 67)
 #endif
 .endm
 #endif
@@ -130,7 +130,7 @@
 */
BEGIN_MMU_FTR_SECTION_NESTED(68)
b   100f  // skip_save_amr
-   END_MMU_FTR_SECTION_NESTED_IFCLR(MMU_FTR_PKEY | MMU_FTR_BOOK3S_KUAP, 68)
+   END_MMU_FTR_SECTION_NESTED_IFCLR(MMU_FTR_PKEY | MMU_FTR_KUAP, 68)
 
/*
 * if pkey is disabled and we are entering from userspace
@@ -166,7 +166,7 @@
mtspr   SPRN_AMR, \gpr2
isync
 102:
-   END_MMU_FTR_SECTION_NESTED_IFSET(MMU_FTR_BOOK3S_KUAP, 69)
+   END_MMU_FTR_SECTION_NESTED_IFSET(MMU_FTR_KUAP, 69)
 
/*
 * if entering from kernel we don't need save IAMR
@@ -232,7 +232,7 @@ static inline u64 current_thread_iamr(void)
 
 static __always_inline bool kuap_is_disabled(void)
 {
-   return !mmu_has_feature(MMU_FTR_BOOK3S_KUAP);
+   return !mmu_has_feature(MMU_FTR_KUAP);
 }
 
 static inline void kuap_user_restore(struct pt_regs *regs)
@@ -243,7 +243,7 @@ static inline void kuap_user_restore(struct pt_regs *regs)
if (!mmu_has_feature(MMU_FTR_PKEY))
return;
 
-   if (!mmu_has_feature(MMU_FTR_BOOK3S_KUAP)) {
+   if (!mmu_has_feature(MMU_FTR_KUAP)) {
amr = mfspr(SPRN_AMR);
if (amr != regs->amr)
restore_amr = true;
@@ -317,7 +317,7 @@ static inline unsigned long get_kuap(void)
 * This has no effect in terms of actually blocking things on hash,
 * so it doesn't break anything.
 */
-   if (!mmu_has_feature(MMU_FTR_BOOK3S_KUAP))
+   if (!mmu_has_feature(MMU_FTR_KUAP))
return AMR_KUAP_BLOCKED;
 
return mfspr(SPRN_AMR);
@@ -325,7 +325,7 @@ static inline unsigned long get_kuap(void)
 
 static __always_inline void set_kuap(unsigned long value)
 {
-   if (!mmu_has_feature(MMU_FTR_BOOK3S_KUAP))
+   if (!mmu_has_feature(MMU_FTR_KUAP))
return;
 
/*
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 94b981152667..82af2e2c5eca 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -33,7 +33,7 @@
  * key 0 controlling userspace addresses on radix
  * Key 3 on hash
  */
-#define MMU_FTR_BOOK3S_KUAPASM_CONST(0x0200)
+#define MMU_FTR_KUAP   ASM_CONST(0x0200)
 
 /*
  * Supports KUEP feature
@@ -188,7 +188,7 @@ enum {
 #endif /* CONFIG_PPC_RADIX_MMU */
 #endif
 #ifdef CONFIG_PPC_KUAP
-   MMU_FTR_BOOK3S_KUAP |
+   MMU_FTR_KUAP |
 #endif /* CONFIG_PPC_KUAP */
 #ifdef CONFIG_PPC_MEM_KEYS
MMU_FTR_PKEY |
diff --git a/arch/powerpc/kernel/syscall.c b/arch/powerpc/kernel/syscall.c
index 

[PATCH v2 7/9] powerpc/kuap: Simplify KUAP lock/unlock on BOOK3S/32

[Christophe Leroy]

On book3s/32 KUAP is performed at segment level. At the moment,
when enabling userspace access, only current segment is modified.
Then if a write is performed on another user segment, a fault is
taken and all other user segments get enabled for userspace
access. This then require special attention when disabling
userspace access.

Having a userspace write access crossing a segment boundary is
unlikely. Having a userspace write access crossing a segment boundary
back and forth is even more unlikely. So, instead of enabling
userspace access on all segments when a write fault occurs, just
change which segment has userspace access enabled in order to
eliminate the case when more than one segment has userspace access
enabled. That simplifies userspace access deactivation.

There is however a corner case which is even more unlikely but has
to be handled anyway: an unaligned access which is crossing a
segment boundary. That would definitely require at least having
userspace access enabled on the two segments. To avoid complicating
the likely case for a so unlikely happening, handle such situation
like an alignment exception and emulate the store.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/book3s/32/kup.h | 71 
 arch/powerpc/include/asm/bug.h   |  1 +
 arch/powerpc/kernel/traps.c  |  2 +-
 arch/powerpc/mm/book3s32/kuap.c  | 15 +
 4 files changed, 26 insertions(+), 63 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/32/kup.h 
b/arch/powerpc/include/asm/book3s/32/kup.h
index 4ca6122ef0e1..5d4f787244d5 100644
--- a/arch/powerpc/include/asm/book3s/32/kup.h
+++ b/arch/powerpc/include/asm/book3s/32/kup.h
@@ -14,55 +14,19 @@
 #include 
 
 #define KUAP_NONE  (~0UL)
-#define KUAP_ALL   (~1UL)
 
-static inline void kuap_lock_one(unsigned long addr)
+static inline void uaccess_end_32s(unsigned long addr)
 {
mtsr(mfsr(addr) | SR_KS, addr);
isync();/* Context sync required after mtsr() */
 }
 
-static inline void kuap_unlock_one(unsigned long addr)
+static inline void uaccess_begin_32s(unsigned long addr)
 {
mtsr(mfsr(addr) & ~SR_KS, addr);
isync();/* Context sync required after mtsr() */
 }
 
-static inline void kuap_lock_all(void)
-{
-   update_user_segments(mfsr(0) | SR_KS);
-   isync();/* Context sync required after mtsr() */
-}
-
-static inline void kuap_unlock_all(void)
-{
-   update_user_segments(mfsr(0) & ~SR_KS);
-   isync();/* Context sync required after mtsr() */
-}
-
-void kuap_lock_all_ool(void);
-void kuap_unlock_all_ool(void);
-
-static inline void kuap_lock_addr(unsigned long addr, bool ool)
-{
-   if (likely(addr != KUAP_ALL))
-   kuap_lock_one(addr);
-   else if (!ool)
-   kuap_lock_all();
-   else
-   kuap_lock_all_ool();
-}
-
-static inline void kuap_unlock(unsigned long addr, bool ool)
-{
-   if (likely(addr != KUAP_ALL))
-   kuap_unlock_one(addr);
-   else if (!ool)
-   kuap_unlock_all();
-   else
-   kuap_unlock_all_ool();
-}
-
 static inline void __kuap_save_and_lock(struct pt_regs *regs)
 {
unsigned long kuap = current->thread.kuap;
@@ -72,7 +36,7 @@ static inline void __kuap_save_and_lock(struct pt_regs *regs)
return;
 
current->thread.kuap = KUAP_NONE;
-   kuap_lock_addr(kuap, false);
+   uaccess_end_32s(kuap);
 }
 #define __kuap_save_and_lock __kuap_save_and_lock
 
@@ -84,7 +48,7 @@ static inline void __kuap_kernel_restore(struct pt_regs 
*regs, unsigned long kua
 {
if (unlikely(kuap != KUAP_NONE)) {
current->thread.kuap = KUAP_NONE;
-   kuap_lock_addr(kuap, false);
+   uaccess_end_32s(kuap);
}
 
if (likely(regs->kuap == KUAP_NONE))
@@ -92,7 +56,7 @@ static inline void __kuap_kernel_restore(struct pt_regs 
*regs, unsigned long kua
 
current->thread.kuap = regs->kuap;
 
-   kuap_unlock(regs->kuap, false);
+   uaccess_begin_32s(regs->kuap);
 }
 
 static inline unsigned long __kuap_get_and_assert_locked(void)
@@ -114,7 +78,7 @@ static __always_inline void __allow_user_access(void __user 
*to, const void __us
return;
 
current->thread.kuap = (__force u32)to;
-   kuap_unlock_one((__force u32)to);
+   uaccess_begin_32s((__force u32)to);
 }
 
 static __always_inline void __prevent_user_access(unsigned long dir)
@@ -127,7 +91,7 @@ static __always_inline void __prevent_user_access(unsigned 
long dir)
return;
 
current->thread.kuap = KUAP_NONE;
-   kuap_lock_addr(kuap, true);
+   uaccess_end_32s(kuap);
 }
 
 static inline unsigned long __prevent_user_access_return(void)
@@ -136,7 +100,7 @@ static inline unsigned long 
__prevent_user_access_return(void)
 
if (flags != KUAP_NONE) {
current->thread.kuap = KUAP_NONE;
-   

[PATCH v2 2/9] powerpc/kuap: Avoid useless jump_label on empty function

[Christophe Leroy]

Disassembly of interrupt_enter_prepare() shows a pointless nop
before the mftb

  c000abf0 :
  c000abf0:   81 23 00 84 lwz r9,132(r3)
  c000abf4:   71 29 40 00 andi.   r9,r9,16384
  c000abf8:   41 82 00 28 beq-c000ac20 

  c000abfc: ===>  60 00 00 00 nop   <
  c000ac00:   7d 0c 42 e6 mftbr8
  c000ac04:   80 e2 00 08 lwz r7,8(r2)
  c000ac08:   81 22 00 28 lwz r9,40(r2)
  c000ac0c:   91 02 00 24 stw r8,36(r2)
  c000ac10:   7d 29 38 50 subfr9,r9,r7
  c000ac14:   7d 29 42 14 add r9,r9,r8
  c000ac18:   91 22 00 08 stw r9,8(r2)
  c000ac1c:   4e 80 00 20 blr
  c000ac20:   60 00 00 00 nop
  c000ac24:   7d 5a c2 a6 mfmd_ap r10
  c000ac28:   3d 20 de 00 lis r9,-8704
  c000ac2c:   91 43 00 b0 stw r10,176(r3)
  c000ac30:   7d 3a c3 a6 mtspr   794,r9
  c000ac34:   4e 80 00 20 blr

That comes from the call to kuap_loc(), allthough __kuap_lock() is an
empty function on the 8xx.

To avoid that, only perform kuap_is_disabled() check when there is
something to do with __kuap_lock().

Do the same with __kuap_save_and_lock() and
__kuap_get_and_assert_locked().

Signed-off-by: Christophe Leroy 
Reviewed-by: Nicholas Piggin 
---
v2: Add back comment about __kupa_lock() not needed on 64s
---
 arch/powerpc/include/asm/book3s/32/kup.h |  6 ++--
 arch/powerpc/include/asm/book3s/64/kup.h | 10 ++
 arch/powerpc/include/asm/kup.h   | 33 +---
 arch/powerpc/include/asm/nohash/32/kup-8xx.h | 11 +++
 arch/powerpc/include/asm/nohash/kup-booke.h  |  8 +++--
 5 files changed, 29 insertions(+), 39 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/32/kup.h 
b/arch/powerpc/include/asm/book3s/32/kup.h
index 678f9c9d89b6..466a19cfb4df 100644
--- a/arch/powerpc/include/asm/book3s/32/kup.h
+++ b/arch/powerpc/include/asm/book3s/32/kup.h
@@ -77,10 +77,6 @@ static inline void kuap_unlock(unsigned long addr, bool ool)
kuap_unlock_all_ool();
 }
 
-static inline void __kuap_lock(void)
-{
-}
-
 static inline void __kuap_save_and_lock(struct pt_regs *regs)
 {
unsigned long kuap = current->thread.kuap;
@@ -92,6 +88,7 @@ static inline void __kuap_save_and_lock(struct pt_regs *regs)
current->thread.kuap = KUAP_NONE;
kuap_lock_addr(kuap, false);
 }
+#define __kuap_save_and_lock __kuap_save_and_lock
 
 static inline void kuap_user_restore(struct pt_regs *regs)
 {
@@ -120,6 +117,7 @@ static inline unsigned long 
__kuap_get_and_assert_locked(void)
 
return kuap;
 }
+#define __kuap_get_and_assert_locked __kuap_get_and_assert_locked
 
 static __always_inline void __allow_user_access(void __user *to, const void 
__user *from,
u32 size, unsigned long dir)
diff --git a/arch/powerpc/include/asm/book3s/64/kup.h 
b/arch/powerpc/include/asm/book3s/64/kup.h
index 84c09e546115..2a7bd3ecc556 100644
--- a/arch/powerpc/include/asm/book3s/64/kup.h
+++ b/arch/powerpc/include/asm/book3s/64/kup.h
@@ -298,15 +298,9 @@ static inline unsigned long 
__kuap_get_and_assert_locked(void)
WARN_ON_ONCE(amr != AMR_KUAP_BLOCKED);
return amr;
 }
+#define __kuap_get_and_assert_locked __kuap_get_and_assert_locked
 
-/* Do nothing, book3s/64 does that in ASM */
-static inline void __kuap_lock(void)
-{
-}
-
-static inline void __kuap_save_and_lock(struct pt_regs *regs)
-{
-}
+/* __kuap_lock() not required, book3s/64 does that in ASM */
 
 /*
  * We support individually allowing read or write, but we don't support nesting
diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
index d751ddd08110..24cde16c4fbe 100644
--- a/arch/powerpc/include/asm/kup.h
+++ b/arch/powerpc/include/asm/kup.h
@@ -52,16 +52,9 @@ __bad_kuap_fault(struct pt_regs *regs, unsigned long 
address, bool is_write)
return false;
 }
 
-static inline void __kuap_lock(void) { }
-static inline void __kuap_save_and_lock(struct pt_regs *regs) { }
 static inline void kuap_user_restore(struct pt_regs *regs) { }
 static inline void __kuap_kernel_restore(struct pt_regs *regs, unsigned long 
amr) { }
 
-static inline unsigned long __kuap_get_and_assert_locked(void)
-{
-   return 0;
-}
-
 /*
  * book3s/64/kup-radix.h defines these functions for the !KUAP case to flush
  * the L1D cache after user accesses. Only include the empty stubs for other
@@ -85,29 +78,24 @@ bad_kuap_fault(struct pt_regs *regs, unsigned long address, 
bool is_write)
return __bad_kuap_fault(regs, address, is_write);
 }
 
-static __always_inline void kuap_assert_locked(void)
-{
-   if (kuap_is_disabled())
-   return;
-
-   if (IS_ENABLED(CONFIG_PPC_KUAP_DEBUG))
-   __kuap_get_and_assert_locked();
-}
-
 static __always_inline void kuap_lock(void)
 {
+#ifdef __kuap_lock
if (kuap_is_disabled())
return;
 

[PATCH v2 1/9] powerpc/kuap: Avoid unnecessary reads of MD_AP

[Christophe Leroy]

A disassembly of interrupt_exit_kernel_prepare() shows a useless read
of MD_AP register. This is shown by r9 being re-used immediately without
doing anything with the value read.

  c000e0e0:   60 00 00 00 nop
  c000e0e4: ===>  7d 3a c2 a6 mfmd_ap r9<
  c000e0e8:   7d 20 00 a6 mfmsr   r9
  c000e0ec:   7c 51 13 a6 mtspr   81,r2
  c000e0f0:   81 3f 00 84 lwz r9,132(r31)
  c000e0f4:   71 29 80 00 andi.   r9,r9,32768

kuap_get_and_assert_locked() is paired with kuap_kernel_restore()
and are only used in interrupt_exit_kernel_prepare(). The value
returned by kuap_get_and_assert_locked() is only used by
kuap_kernel_restore().

On 8xx, kuap_kernel_restore() doesn't use the value read by
kuap_get_and_assert_locked() so modify kuap_get_and_assert_locked()
to not perform the read of MD_AP and return 0 instead.

The same applies on BOOKE.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/nohash/32/kup-8xx.h | 8 ++--
 arch/powerpc/include/asm/nohash/kup-booke.h  | 6 ++
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/include/asm/nohash/32/kup-8xx.h 
b/arch/powerpc/include/asm/nohash/32/kup-8xx.h
index c44d97751723..8579210f2a6a 100644
--- a/arch/powerpc/include/asm/nohash/32/kup-8xx.h
+++ b/arch/powerpc/include/asm/nohash/32/kup-8xx.h
@@ -41,14 +41,10 @@ static inline void __kuap_kernel_restore(struct pt_regs 
*regs, unsigned long kua
 
 static inline unsigned long __kuap_get_and_assert_locked(void)
 {
-   unsigned long kuap;
-
-   kuap = mfspr(SPRN_MD_AP);
-
if (IS_ENABLED(CONFIG_PPC_KUAP_DEBUG))
-   WARN_ON_ONCE(kuap >> 16 != MD_APG_KUAP >> 16);
+   WARN_ON_ONCE(mfspr(SPRN_MD_AP) >> 16 != MD_APG_KUAP >> 16);
 
-   return kuap;
+   return 0;
 }
 
 static inline void __allow_user_access(void __user *to, const void __user 
*from,
diff --git a/arch/powerpc/include/asm/nohash/kup-booke.h 
b/arch/powerpc/include/asm/nohash/kup-booke.h
index 49bb41ed0816..823c5a3a96d8 100644
--- a/arch/powerpc/include/asm/nohash/kup-booke.h
+++ b/arch/powerpc/include/asm/nohash/kup-booke.h
@@ -58,12 +58,10 @@ static inline void __kuap_kernel_restore(struct pt_regs 
*regs, unsigned long kua
 
 static inline unsigned long __kuap_get_and_assert_locked(void)
 {
-   unsigned long kuap = mfspr(SPRN_PID);
-
if (IS_ENABLED(CONFIG_PPC_KUAP_DEBUG))
-   WARN_ON_ONCE(kuap);
+   WARN_ON_ONCE(mfspr(SPRN_PID));
 
-   return kuap;
+   return 0;
 }
 
 static inline void __allow_user_access(void __user *to, const void __user 
*from,
-- 
2.41.0

[PATCH v2 9/9] powerpc/kuap: Use ASM feature fixups instead of static branches

[Christophe Leroy]

To avoid a useless nop on top of every uaccess enable/disable and
make life easier for objtool, replace static branches by ASM feature
fixups that will nop KUAP enabling instructions out in the unlikely
case KUAP is disabled at boottime.

Leave it as is on book3s/64 for now, it will be handled later when
objtool is activated on PPC64.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/book3s/32/kup.h | 34 +++
 arch/powerpc/include/asm/kup.h   | 45 +++-
 arch/powerpc/include/asm/nohash/32/kup-8xx.h | 30 +
 arch/powerpc/include/asm/nohash/kup-booke.h  | 38 ++---
 arch/powerpc/mm/nohash/kup.c |  2 +-
 5 files changed, 75 insertions(+), 74 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/32/kup.h 
b/arch/powerpc/include/asm/book3s/32/kup.h
index f40a210bf1bb..73d02815f52d 100644
--- a/arch/powerpc/include/asm/book3s/32/kup.h
+++ b/arch/powerpc/include/asm/book3s/32/kup.h
@@ -17,14 +17,30 @@
 
 static __always_inline void uaccess_end_32s(unsigned long addr)
 {
-   mtsr(mfsr(addr) | SR_KS, addr);
-   isync();/* Context sync required after mtsr() */
+   unsigned long tmp;
+
+   asm volatile(ASM_MMU_FTR_IFSET(
+   "mfsrin %0, %1;"
+   "oris %0, %0, %2;"
+   "mtsrin %0, %1;"
+   "isync", "", %3)
+   : "="(tmp)
+   : "r"(addr), "i"(SR_KS >> 16), "i"(MMU_FTR_KUAP)
+   : "memory");
 }
 
 static __always_inline void uaccess_begin_32s(unsigned long addr)
 {
-   mtsr(mfsr(addr) & ~SR_KS, addr);
-   isync();/* Context sync required after mtsr() */
+   unsigned long tmp;
+
+   asm volatile(ASM_MMU_FTR_IFSET(
+   "mfsrin %0, %1;"
+   "rlwinm %0, %0, 0, %2;"
+   "mtsrin %0, %1;"
+   "isync", "", %3)
+   : "="(tmp)
+   : "r"(addr), "i"(~SR_KS), "i"(MMU_FTR_KUAP)
+   : "memory");
 }
 
 static __always_inline void __kuap_save_and_lock(struct pt_regs *regs)
@@ -69,8 +85,8 @@ static __always_inline unsigned long 
__kuap_get_and_assert_locked(void)
 }
 #define __kuap_get_and_assert_locked __kuap_get_and_assert_locked
 
-static __always_inline void __allow_user_access(void __user *to, const void 
__user *from,
-   u32 size, unsigned long dir)
+static __always_inline void allow_user_access(void __user *to, const void 
__user *from,
+ u32 size, unsigned long dir)
 {
BUILD_BUG_ON(!__builtin_constant_p(dir));
 
@@ -81,7 +97,7 @@ static __always_inline void __allow_user_access(void __user 
*to, const void __us
uaccess_begin_32s((__force u32)to);
 }
 
-static __always_inline void __prevent_user_access(unsigned long dir)
+static __always_inline void prevent_user_access(unsigned long dir)
 {
u32 kuap = current->thread.kuap;
 
@@ -94,7 +110,7 @@ static __always_inline void __prevent_user_access(unsigned 
long dir)
uaccess_end_32s(kuap);
 }
 
-static __always_inline unsigned long __prevent_user_access_return(void)
+static __always_inline unsigned long prevent_user_access_return(void)
 {
unsigned long flags = current->thread.kuap;
 
@@ -106,7 +122,7 @@ static __always_inline unsigned long 
__prevent_user_access_return(void)
return flags;
 }
 
-static __always_inline void __restore_user_access(unsigned long flags)
+static __always_inline void restore_user_access(unsigned long flags)
 {
if (flags != KUAP_NONE) {
current->thread.kuap = flags;
diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
index 77adb9cd2da5..ad7e8c5aec3f 100644
--- a/arch/powerpc/include/asm/kup.h
+++ b/arch/powerpc/include/asm/kup.h
@@ -72,11 +72,11 @@ static __always_inline void __kuap_kernel_restore(struct 
pt_regs *regs, unsigned
  * platforms.
  */
 #ifndef CONFIG_PPC_BOOK3S_64
-static __always_inline void __allow_user_access(void __user *to, const void 
__user *from,
-   unsigned long size, unsigned 
long dir) { }
-static __always_inline void __prevent_user_access(unsigned long dir) { }
-static __always_inline unsigned long __prevent_user_access_return(void) { 
return 0UL; }
-static __always_inline void __restore_user_access(unsigned long flags) { }
+static __always_inline void allow_user_access(void __user *to, const void 
__user *from,
+ unsigned long size, unsigned long 
dir) { }
+static __always_inline void prevent_user_access(unsigned long dir) { }
+static __always_inline unsigned long prevent_user_access_return(void) { return 
0UL; }
+static __always_inline void restore_user_access(unsigned long flags) { }
 #endif /* CONFIG_PPC_BOOK3S_64 */
 #endif /* CONFIG_PPC_KUAP */
 
@@ -132,41 +132,6 @@ static __always_inline void kuap_assert_locked(void)

[PATCH v2 0/9] Cleanup/Optimise KUAP (v2)

[Christophe Leroy]

This series is cleaning up a bit KUAP in preparation of using objtool
to validate UACCESS.

There are two main changes in this series:

1/ Simplification of KUAP on book3s/32

2/ Using ASM features on 32 bits and booke as suggested by Nic.

Those changes will be required for objtool UACCESS validation, but
even before they are worth it, especially the simplification on 32s.

Christophe Leroy (9):
  powerpc/kuap: Avoid unnecessary reads of MD_AP
  powerpc/kuap: Avoid useless jump_label on empty function
  powerpc/kuap: Fold kuep_is_disabled() into its only user
  powerpc/features: Add capability to update mmu features later
  powerpc/kuap: MMU_FTR_BOOK3S_KUAP becomes MMU_FTR_KUAP
  powerpc/kuap: Use MMU_FTR_KUAP on all and refactor disabling kuap
  powerpc/kuap: Simplify KUAP lock/unlock on BOOK3S/32
  powerpc/kuap: KUAP enabling/disabling functions must be
__always_inline
  powerpc/kuap: Use ASM feature fixups instead of static branches

 arch/powerpc/include/asm/book3s/32/kup.h  | 131 +++---
 .../powerpc/include/asm/book3s/64/hash-pkey.h |   2 +-
 arch/powerpc/include/asm/book3s/64/kup.h  |  54 +++-
 arch/powerpc/include/asm/bug.h|   1 +
 arch/powerpc/include/asm/feature-fixups.h |   1 +
 arch/powerpc/include/asm/kup.h|  91 +---
 arch/powerpc/include/asm/mmu.h|   4 +-
 arch/powerpc/include/asm/nohash/32/kup-8xx.h  |  62 -
 arch/powerpc/include/asm/nohash/kup-booke.h   |  68 -
 arch/powerpc/include/asm/uaccess.h|   6 +-
 arch/powerpc/kernel/cputable.c|   4 +
 arch/powerpc/kernel/syscall.c |   2 +-
 arch/powerpc/kernel/traps.c   |   2 +-
 arch/powerpc/lib/feature-fixups.c |  31 -
 arch/powerpc/mm/book3s32/kuap.c   |  20 +--
 arch/powerpc/mm/book3s32/mmu_context.c|   2 +-
 arch/powerpc/mm/book3s64/pkeys.c  |   2 +-
 arch/powerpc/mm/init_32.c |   2 +
 arch/powerpc/mm/nohash/kup.c  |   8 +-
 19 files changed, 220 insertions(+), 273 deletions(-)

-- 
2.41.0

Re: [PATCH 20/21] ARM: dma-mapping: split out arch_dma_mark_clean() helper

[Geert Uytterhoeven]

Hi Arnd,

On Mon, Mar 27, 2023 at 2:16 PM Arnd Bergmann  wrote:
> From: Arnd Bergmann 
>
> The arm version of the arch_sync_dma_for_cpu() function annotates pages as
> PG_dcache_clean after a DMA, but no other architecture does this here. On
> ia64, the same thing is done in arch_sync_dma_for_cpu(), so it makes sense
> to use the same hook in order to have identical arch_sync_dma_for_cpu()
> semantics as all other architectures.
>
> Splitting this out has multiple effects:
>
>  - for dma-direct, this now gets called after arch_sync_dma_for_cpu()
>for DMA_FROM_DEVICE mappings, but not for DMA_BIDIRECTIONAL. While
>it would not be harmful to keep doing it for bidirectional mappings,
>those are apparently not used in any callers that care about the flag.
>
>  - Since arm has its own dma-iommu abstraction, this now also needs to
>call the same function, so the calls are added there to mirror the
>dma-direct version.
>
>  - Like dma-direct, the dma-iommu version now marks the dcache clean
>for both coherent and noncoherent devices after a DMA, but it only
>does this for DMA_FROM_DEVICE, not DMA_BIDIRECTIONAL.
>
> [ HELP NEEDED: can anyone confirm that it is a correct assumption
>   on arm that a cache-coherent device writing to a page always results
>   in it being in a PG_dcache_clean state like on ia64, or can a device
>   write directly into the dcache?]
>
> Signed-off-by: Arnd Bergmann 

Thanks for your patch, which is now commit 322dbe898f82fd8a
("ARM: dma-mapping: split out arch_dma_mark_clean() helper") in
esmil/jh7100-dmapool.

If CONFIG_ARM_DMA_USE_IOMMU=y, the build fails.

> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c

> @@ -1294,6 +1298,17 @@ static int arm_iommu_map_sg(struct device *dev, struct 
> scatterlist *sg,
> return -EINVAL;
>  }
>
> +static void arm_iommu_sync_dma_for_cpu(phys_addr_t phys, size_t len,
> +  enum dma_data_direction dir,
> +  bool dma_coherent)
> +{
> +   if (!dma_coherent)
> +   arch_sync_dma_for_cpu(phys, s->length, dir);

s/s->length/len/

> +
> +   if (dir == DMA_FROM_DEVICE)
> +   arch_dma_mark_clean(phys, s->length);

Likewise.

> +}
> +
>  /**
>   * arm_iommu_unmap_sg - unmap a set of SG buffers mapped by dma_map_sg
>   * @dev: valid struct device pointer

> @@ -1425,9 +1438,9 @@ static void arm_iommu_unmap_page(struct device *dev, 
> dma_addr_t handle,
> if (!iova)
> return;
>
> -   if (!dev->dma_coherent && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) {
> +   if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))

Missing opening curly brace.

> phys = iommu_iova_to_phys(mapping->domain, handle);
> -   arch_sync_dma_for_cpu(phys, size, dir);
> +   arm_iommu_sync_dma_for_cpu(phys, size, dir, 
> dev->dma_coherent);
> }
>
> iommu_unmap(mapping->domain, iova, len);

With the above fixed, it builds and boots fine (on R-Car M2-W).

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

Re: [PATCH] powerpc/fadump: reset dump area size variable if memblock reserve fails

[Sourabh Jain]

Hello Michael,

Do you have any feedback or comments regarding this patch?

Thanks,
Sourabh

On 08/06/23 14:52, Sourabh Jain wrote:

If the memory reservation process (memblock_reserve) fails to reserve
the memory, the reserve dump variable retains the dump area size.
Consequently, the size of the dump area calculated for reservation
is displayed in /sys/kernel/fadump/mem_reserved.

To resolve this issue, the reserve dump area size variable is set to 0
if the memblock_reserve fails to reserve memory.

Fixes: 8255da95e545 ("powerpc/fadump: release all the memory above boot memory 
size")
Signed-off-by: Sourabh Jain 
Acked-by: Mahesh Salgaonkar 
---
  arch/powerpc/kernel/fadump.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index ea0a073abd96..a8f2c3b2fa1e 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -641,6 +641,7 @@ int __init fadump_reserve_mem(void)
goto error_out;
  
  		if (memblock_reserve(base, size)) {

+   fw_dump.reserve_dump_area_size = 0;
pr_err("Failed to reserve memory!\n");
goto error_out;
}

Re: [PATCH] arch/powerpc: Remove unnecessary endian conversion code in XICS

[Michael Ellerman]

Gautam Menghani  writes:
> Remove an unnecessary piece of code that does an endianness conversion but
> does not use the result. The following warning was reported by Clang's
> static analyzer:
>
> arch/powerpc/sysdev/xics/ics-opal.c:114:2: warning: Value stored to
> 'server' is never read [deadcode.DeadStores]
> server = be16_to_cpu(oserver);
>
> As the result of endianness conversion is never used, delete the line
> and fix the warning.
>
> Signed-off-by: Gautam Menghani 
> ---
>  arch/powerpc/sysdev/xics/ics-opal.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/arch/powerpc/sysdev/xics/ics-opal.c 
> b/arch/powerpc/sysdev/xics/ics-opal.c
> index 6cfbb4fac7fb..5fe73dabab79 100644
> --- a/arch/powerpc/sysdev/xics/ics-opal.c
> +++ b/arch/powerpc/sysdev/xics/ics-opal.c
> @@ -111,7 +111,6 @@ static int ics_opal_set_affinity(struct irq_data *d,
>  __func__, d->irq, hw_irq, rc);
>   return -1;
>   }
> - server = be16_to_cpu(oserver);
>  
>   wanted_server = xics_get_irq_server(d->irq, cpumask, 1);
>   if (wanted_server < 0) {

My first question with a patch like this is always going to be "how did
the code end up like this?"

Has the code changed and this assignment became unused? If so the commit
that did that should be identified.

If the code has always been like this that's also useful to know. Or
something else happened for it to end up this way :)

The second question will be "is there actually a bug here?". ie. should
server actually be used, and the bug is not that it's a dead assignment
but rather that server is not where it should be.

cheers

Re: [PATCH] powerpc: isa-bridge: Fix ISA mmapping when "ranges" is not present

[Christian Zigotzky]

On 03.07.23 07:21, Michael Ellerman wrote:

On Fri, 05 May 2023 12:18:17 -0500, Rob Herring wrote:

Commit e4ab08be5b49 ("powerpc/isa-bridge: Remove open coded "ranges"
parsing") broke PASemi Nemo board booting. The issue is the ISA I/O
range was not getting mapped as the logic to handle no "ranges" was
inverted. If phb_io_base_phys is non-zero, then the ISA range defaults
to the first 64K of the PCI I/O space. phb_io_base_phys should only be 0
when looking for a non-PCI ISA region.

[...]

Applied to powerpc/fixes.

[1/1] powerpc: isa-bridge: Fix ISA mmapping when "ranges" is not present
   https://git.kernel.org/powerpc/c/79de36042eecb684e0f748d17ba52f365fde0d65

cheers

Hello Michael,

This patch has already been applied. Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4927cb98f0eeaa5dbeac882e8372f4b16dc62624


Thanks,
Christian

Re: [PATCH] powerpc: Switch i2c drivers back to use .probe()

[Michael Ellerman]

On Thu, 25 May 2023 22:56:22 +0200, Uwe Kleine-König wrote:
> After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type"), all drivers being converted to .probe_new() and then
> 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter")
> convert back to (the new) .probe() to be able to eventually drop
> .probe_new() from struct i2c_driver.
> 
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc: Switch i2c drivers back to use .probe()
  https://git.kernel.org/powerpc/c/48f2444eb4dc0f3de9146f7278e859fa6b5e568b

cheers

Re: [PATCH] powerpc: Drop MPC5200 LocalPlus bus FIFO driver

[Michael Ellerman]

On Thu, 13 Apr 2023 08:16:42 +0200, Uwe Kleine-König wrote:
> While mpc5200b.dtsi contains a device that this driver can bind to, the
> only purpose of a bound device is to be used by the four exported functions
> mpc52xx_lpbfifo_submit(), mpc52xx_lpbfifo_abort(), mpc52xx_lpbfifo_poll()
> and mpc52xx_lpbfifo_start_xfer(). However there are no callers to this
> function and so the driver is effectively superfluous and can be deleted.
> Also drop some defines and a struct from  that are unused
> now together with the declarations of the four mentioned functions.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc: Drop MPC5200 LocalPlus bus FIFO driver
  https://git.kernel.org/powerpc/c/7d3ee229ea51a17afc1e53272e2a8f377cc82ba2

cheers

Re: [PATCH] macintosh: Switch i2c drivers back to use .probe()

[Michael Ellerman]

On Tue, 23 May 2023 21:50:53 +0200, Uwe Kleine-König wrote:
> After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type"), all drivers being converted to .probe_new() and then
> 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert
> back to (the new) .probe() to be able to eventually drop .probe_new() from
> struct i2c_driver.
> 
> 
> [...]

Applied to powerpc/next.

[1/1] macintosh: Switch i2c drivers back to use .probe()
  https://git.kernel.org/powerpc/c/922db7c571f55b1eab2d2c5da14d150aff1d0252

cheers

Re: [PATCH] powerpc: powermac: Use of_get_cpu_hwid() to read CPU node 'reg'

[Michael Ellerman]

On Sun, 19 Mar 2023 09:59:31 -0500, Rob Herring wrote:
> Replace open coded reading of CPU nodes' "reg" properties with
> of_get_cpu_hwid() dedicated for this purpose.
> 
> 

Applied to powerpc/next.

[1/1] powerpc: powermac: Use of_get_cpu_hwid() to read CPU node 'reg'
  https://git.kernel.org/powerpc/c/bc1cf75027585f8d87f94e464ee5909acf885a8c

cheers

Re: [PATCH] powerpc: remove unneeded if-checks

[Michael Ellerman]

On Fri, 28 Apr 2023 18:12:40 -0400, Tom Rix wrote:
> For ppc64, gcc with W=1 reports
> arch/powerpc/platforms/cell/spu_base.c:330:17: error:
>   suggest braces around empty body in an 'if' statement [-Werror=empty-body]
>   330 | ;
>   | ^
> arch/powerpc/platforms/cell/spu_base.c:333:17: error:
>   suggest braces around empty body in an 'if' statement [-Werror=empty-body]
>   333 | ;
>   | ^
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc: remove unneeded if-checks
  https://git.kernel.org/powerpc/c/da5311a4b852eaf2c0feac8b28884a8d8a801dfc

cheers

Re: [PATCH] powerpc/iommu: Only build sPAPR access functions on pSeries

[Michael Ellerman]

On Mon, 05 Jun 2023 13:48:56 -0500, Timothy Pearson wrote:
>  and PowerNV
> 
> A build failure with CONFIG_HAVE_PCI=y set without PSERIES or POWERNV
> set was caught by the random configuration checker.  Guard the sPAPR
> specific IOMMU functions on CONFIG_PPC_PSERIES || CONFIG_PPC_POWERNV.
> 
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/iommu: Only build sPAPR access functions on pSeries
  https://git.kernel.org/powerpc/c/bfd8d989210cb6bb1c8e87b7c525831dceb91418

cheers

Re: [PATCH] powerpc: mpc512x: Remove open coded "ranges" parsing

[Michael Ellerman]

On Fri, 09 Jun 2023 12:32:32 -0600, Rob Herring wrote:
> "ranges" is a standard property, and we have common helper functions
> for parsing it, so let's use the for_each_of_range() iterator.
> 
> 

Applied to powerpc/next.

[1/1] powerpc: mpc512x: Remove open coded "ranges" parsing
  https://git.kernel.org/powerpc/c/ef8e341075330b3d0e06d4b026d971e7e4ce378b

cheers

Re: [PATCH] macintosh: Use of_address_to_resource()

[Michael Ellerman]

On Sun, 19 Mar 2023 11:32:26 -0500, Rob Herring wrote:
> Replace open coded reading of "reg" and of_translate_address() calls with
> single call to of_address_to_resource().
> 
> 

Applied to powerpc/next.

[1/1] macintosh: Use of_address_to_resource()
  https://git.kernel.org/powerpc/c/93cfa6fb9f78f472862240208ef6e5a65f58f775

cheers

Re: [PATCH] powerpc: fsl: Use of_property_read_reg() to parse "reg"

[Michael Ellerman]

On Fri, 09 Jun 2023 12:31:50 -0600, Rob Herring wrote:
> Use the recently added of_property_read_reg() helper to get the
> untranslated "reg" address value.
> 
> 

Applied to powerpc/next.

[1/1] powerpc: fsl: Use of_property_read_reg() to parse "reg"
  https://git.kernel.org/powerpc/c/f892ac774b34a769318030f5febe5ce41d6e122e

cheers

Re: [PATCH] powerpc: fsl_soc: Use of_range_to_resource() for "ranges" parsing

[Michael Ellerman]

On Fri, 09 Jun 2023 12:32:38 -0600, Rob Herring wrote:
> "ranges" is a standard property with common parsing functions. Users
> shouldn't be implementing their own parsing of it. Refactor the FSL RapidIO
> "ranges" parsing to use of_range_to_resource() instead.
> 
> 

Applied to powerpc/next.

[1/1] powerpc: fsl_soc: Use of_range_to_resource() for "ranges" parsing
  https://git.kernel.org/powerpc/c/be0f9ca024b3ae17fac6b15c04519840f3418269

cheers