This patch series is a follow-up from one of my patches in 2022 and
Sean's reply here:
https://lore.kernel.org/kvm/ypzu6%2fk+8eydf...@google.com/
KVM functions use "long" return values for functions that are wired up
to "struct file_operations", but otherwise use "int" return values for
function
kvm_vm_ioctl_get_nr_mmu_pages() tries to return a "unsigned long" value,
but its caller only stores ther return value in an "int" - which is also
what all the other kvm_vm_ioctl_*() functions are returning. So returning
values that do not fit into a 32-bit integer anymore does not work here.
It's b
Most functions that are related to kvm_arch_vm_ioctl() already use
"int" as return type to pass error values back to the caller. Some
outlier functions use "long" instead for no good reason (they do not
really require long values here). Let's standardize on "int" here to
avoid casting the values ba
The KVM_GET_NR_MMU_PAGES ioctl is quite questionable on 64-bit hosts
since it fails to return the full 64 bits of the value that can be
set with the corresponding KVM_SET_NR_MMU_PAGES call. This ioctl
likely has also never really been used by userspace applications
(at least not by QEMU and kvmtool
These two functions only return normal integers, so it does not
make sense to declare the return type as "long" here.
Signed-off-by: Thomas Huth
---
arch/s390/kvm/kvm-s390.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.
This function only returns normal integer values, so there is
no need to declare its return value as "long".
Signed-off-by: Thomas Huth
---
arch/arm64/include/asm/kvm_host.h | 4 ++--
arch/arm64/kvm/guest.c| 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/
All kvm_arch_vm_ioctl() implementations now only deal with "int"
types as return values, so we can change the return type of these
functions to use "int" instead of "long".
Signed-off-by: Thomas Huth
---
arch/arm64/kvm/arm.c | 3 +--
arch/mips/kvm/mips.c | 4 ++--
arch/powerpc/kvm/po
KVM functions use "long" return values for functions that are wired up
to "struct file_operations", but otherwise use "int" return values for
functions that can return 0/-errno in order to avoid unintentional
divergences between 32-bit and 64-bit kernels.
Some code still uses "long" in unnecessary
On Fri Feb 3, 2023 at 7:42 PM AEST, Thomas Huth wrote:
> The KVM_GET_NR_MMU_PAGES ioctl is quite questionable on 64-bit hosts
> since it fails to return the full 64 bits of the value that can be
> set with the corresponding KVM_SET_NR_MMU_PAGES call. This ioctl
> likely has also never really been u
On Fri Feb 3, 2023 at 7:42 PM AEST, Thomas Huth wrote:
> Most functions that are related to kvm_arch_vm_ioctl() already use
> "int" as return type to pass error values back to the caller. Some
> outlier functions use "long" instead for no good reason (they do not
> really require long values here).
On Fri Feb 3, 2023 at 4:26 PM AEST, Sachin Sant wrote:
> I am observing an intermittent crash while running powerpc/security
> selftests on a Power10 LPAR booted with powerpc/merge branch code.
>
> [ cut here ]
> WARNING: CPU: 1 PID: 5644 at arch/powerpc/kernel/irq_64.c:278
On Fri, 03 Feb 2023 13:02:59 +1100
Benjamin Gray wrote:
> Do you have a QEMU command to boot this? I tried with
>
> qemu-system-ppc64 --nographic --vga none --kernel ./vmlinux
>
> But it crashes immediately on booting the kernel (same using KVM on
> Power9).
No, this is a custom kernel
On 03/02/2023 11.16, Nicholas Piggin wrote:
On Fri Feb 3, 2023 at 7:42 PM AEST, Thomas Huth wrote:
The KVM_GET_NR_MMU_PAGES ioctl is quite questionable on 64-bit hosts
since it fails to return the full 64 bits of the value that can be
set with the corresponding KVM_SET_NR_MMU_PAGES call. This io
Here's a few things I wanted to tidy before doing the lazy tlb mm
shootdown / exit TLB flush IPI optimisation. There is no hard
dependency just slight code rearrangement but since we're waiting
for the shootdown patches to go via the -mm tree we could do these
now.
It basically just removing a bun
need_flush_all is only set by arch code to instruct generic tlb_flush
to flush all. It is never set by powerpc, so it can be removed.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/mm/book3s64/radix_tlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/book3s
The MMU_NO_CONTEXT checks are an unnecessary complication. Make
these warn to prepare to remove them in future.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/mm/book3s64/radix_tlb.c | 39 +++-
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/
This looks like it came across from x86, but x86 uses TLB_FLUSH_ALL as
a parameter to internal functions. Powerpc never sets it anywhere.
Remove the associated logic and leave a warning for now.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/mm/book3s64/radix_tlb.c | 21 ++---
Here's a few of the easier preparation patches from the pcrel
addressing series.
Thanks,
Nick
Nicholas Piggin (3):
crypto: powerpc - Use address generation helper for asm
powerpc/64s: Refactor initialisation after prom
powerpc/64e: Simplify address calculation in secondary hold loop
arch/
Replace open-coded toc-relative address calculation with helper macros,
commit dab3b8f4fd09 ("powerpc/64: asm use consistent global variable
declaration and access") made similar conversions already but missed
this one.
This allows data addressing model to be changed more easily.
Signed-off-by: N
Move some basic Book3S initialisation after prom to a function similar
to what Book3E looks like. Book3E returns from this function at the
virtual address mapping, and Book3S will do the same in a later change,
so making them look similar helps with that.
Signed-off-by: Nicholas Piggin
---
arch/
As the earlier comment explains, __secondary_hold_spinloop does not have
to be accessed at its virtual address, slightly simplifying code.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/head_64.S | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel
Em Thu, Feb 02, 2023 at 05:41:22PM -0800, Ian Rogers escreveu:
> On Thu, Feb 2, 2023 at 5:40 PM Ian Rogers wrote:
> >
> > ARM64 overrides a weak function but a previous change had broken the
> > build.
> >
> > Fixes: 8cefeb8bd336 ("perf pmu-events: Introduce pmu_metrics_table")
>
> As 8cefeb8bd33
On 29.01.23 13:42, Mike Rapoport wrote:
From: "Mike Rapoport (IBM)"
Makes it consistent with other architectures and allows for generic
definition of pfn_valid() in asm-generic/memory_model.h with clear override
in arch/arm/include/asm/page.h
Signed-off-by: Mike Rapoport (IBM)
---
Reviewed-
On 29.01.23 13:42, Mike Rapoport wrote:
From: "Mike Rapoport (IBM)"
The MMU variant uses generic definitions of page_to_pfn() and
pfn_to_page(), but !MMU defines them in include/asm/page_no.h for no
good reason.
Include asm-generic/memory_model.h in the common include/asm/page.h and
drop redun
On 29.01.23 13:42, Mike Rapoport wrote:
From: "Mike Rapoport (IBM)"
There is stale definition of pfn_valid() for DISCONTINGMEM memory model
guarded !FLATMEM && !SPARSEMEM && NUMA ifdefery.
Remove everything but definition of pfn_valid() for FLATMEM.
Signed-off-by: Mike Rapoport (IBM)
Revie
On 29.01.23 13:42, Mike Rapoport wrote:
From: "Mike Rapoport (IBM)"
Every architecture that supports FLATMEM memory model defines its own
version of pfn_valid() that essentially compares a pfn to max_mapnr.
Use mips/powerpc version implemented as static inline as a generic
implementation of pf
Em Fri, Feb 03, 2023 at 11:17:38AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Feb 02, 2023 at 05:41:22PM -0800, Ian Rogers escreveu:
> > On Thu, Feb 2, 2023 at 5:40 PM Ian Rogers wrote:
> > >
> > > ARM64 overrides a weak function but a previous change had broken the
> > > build.
> > >
> >
Em Fri, Feb 03, 2023 at 11:35:29AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Feb 03, 2023 at 11:17:38AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Thu, Feb 02, 2023 at 05:41:22PM -0800, Ian Rogers escreveu:
> > > On Thu, Feb 2, 2023 at 5:40 PM Ian Rogers wrote:
> > > >
> > > > ARM6
Em Fri, Feb 03, 2023 at 11:36:30AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Feb 03, 2023 at 11:35:29AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Feb 03, 2023 at 11:17:38AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Thu, Feb 02, 2023 at 05:41:22PM -0800, Ian Rogers esc
Em Fri, Feb 03, 2023 at 11:43:23AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Feb 03, 2023 at 11:36:30AM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Feb 03, 2023 at 11:35:29AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Fri, Feb 03, 2023 at 11:17:38AM -0300, Arnaldo Carval
This patch series fixes a number of issues with hotplugging
hvcs devices including memory leaks as well as, the inability
to reconnect to a console device after it has been hot added
back, since it was not getting cleaned up properly on the
hotplug remove path.
Changes since version 2:
- Change at
Use the dev_groups functionality to manage the attribute groups
for hvcs devices. This simplifies the code and also eliminates
errors coming from kernfs when attempting to remove a console
device that is in use.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 19 +--
1 fil
Rather than manually creating attributes for the hvcs driver,
let the driver core do this for us. This also fixes some hotplug
remove issues and ensures that cleanup of these attributes
is done in the right order.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 17 -
1 fil
Grab a reference to the tty when removing the hvcs to ensure
it does not get freed unexpectedly.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
index 522910716025..8d40
When hotplug removing an hvcs device, we need to ensure the
hangup processing is done prior to exiting the remove function,
so use tty_vhangup to do the hangup processing directly
rather than using tty_hangup which simply schedules the hangup
work for later execution.
Signed-off-by: Brian King
--
Synchronizes hotplug remove with the freeing of the port.
This ensures we have freed all the memory associated with
this port and are not leaking memory.
Signed-off-by: Brian King
---
drivers/tty/hvc/hvcs.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff
Em Fri, Feb 03, 2023 at 12:43:48PM -0300, Arnaldo Carvalho de Melo escreveu:
> I tried bisecting, but at this cset:
>
> acme@roc-rk3399-pc:~/git/perf$ git log --oneline -1
> d22e569cd33d (HEAD) perf pmu-events: Separate the metrics from events for no
> jevents
> acme@roc-rk3399-pc:~/git/perf$
>
Em Fri, Feb 03, 2023 at 01:02:02PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Feb 03, 2023 at 12:43:48PM -0300, Arnaldo Carvalho de Melo escreveu:
> > I tried bisecting, but at this cset:
> >
> > acme@roc-rk3399-pc:~/git/perf$ git log --oneline -1
> > d22e569cd33d (HEAD) perf pmu-events:
On Fri, Feb 03, 2023, Thomas Huth wrote:
> kvm_vm_ioctl_get_nr_mmu_pages() tries to return a "unsigned long" value,
> but its caller only stores ther return value in an "int" - which is also
> what all the other kvm_vm_ioctl_*() functions are returning. So returning
> values that do not fit into a
On Wednesday 01 February 2023 09:29:45 Nick Desaulniers wrote:
> On Wed, Feb 1, 2023 at 3:41 AM Christophe Leroy
> wrote:
> >
> >
> >
> > Le 01/02/2023 à 12:31, Naresh Kamboju a écrit :
> > > Following build regression started from next-20230131.
> > >
> > > Regressions found on powerpc:
> > >
> >
Le 03/02/2023 à 18:58, Pali Rohár a écrit :
> On Wednesday 01 February 2023 09:29:45 Nick Desaulniers wrote:
>> On Wed, Feb 1, 2023 at 3:41 AM Christophe Leroy
>> wrote:
>>>
>>>
>>>
>>> Le 01/02/2023 à 12:31, Naresh Kamboju a écrit :
Following build regression started from next-20230131.
>>
Le 02/02/2023 à 00:46, Pali Rohár a écrit :
> On Tuesday 20 December 2022 21:15:08 Pali Rohár wrote:
>> On Monday 19 December 2022 19:45:58 Christophe Leroy wrote:
>>> E500MC64 is a processor pre-dating E5500 that has never been
>>> commercialised. Use -mcpu=e5500 for E5500 core.
>>>
>>> More det
On Wed, 1 Feb 2023 22:36:19 +0800 Dawei Li wrote:
> Commit fc7a6209d571 ("bus: Make remove callback return void") forces
> bus_type::remove be void-returned, it doesn't make much sense for any
> bus based driver implementing remove callbalk to return non-void to
> its caller.
>
> This change is f
{ .compatible = "fsl,ls1046a-pcie-ep", .data = &ls1_ep_drvdata },
+ { .compatible = "fsl,ls1028a-pcie-ep", .data = &ls1_ep_drvdata },
{ .compatible = "fsl,ls1088a-pcie-ep", .data = &ls2_ep_drvdata },
can it be like this for better readability. ?
Thanks,
Alok
On 2/2/2023 11
Hi,
Sorry for digging...
This patch series seems useful for fs developers. I'm not sure its
current status and why it doesn't get merged.
On 3/9/21 11:53 PM, Christoph Hellwig wrote:
> Hi all,
>
> this series first renames the existing alloc_anon_inode to
> alloc_anon_inode_sb to clearly mark
On Saturday 24 December 2022 22:14:20 Pali Rohár wrote:
> This moves machine descriptions and all related code for all P2020 boards
> into new p2020.c source file. This change also copies helper static
> functions from other mpc85xx*.c files into p2020.c, which are required for
> machine descriptio
> to disable filling deprecated pci-OF-bus-map
> config: powerpc-buildonly-randconfig-r006-20230202
> (https://download.01.org/0day-ci/archive/20230203/202302030001.hqpci490-...@intel.com/config)
> compiler: powerpc-linux-gcc (GCC) 12.1.0
> reproduce (this is a W=1 buil
Em Thu, Jan 26, 2023 at 03:36:45PM -0800, Ian Rogers escreveu:
> Add a target that generates a log file for running metric_test.py and
> make this a dependency on generating pmu-events.c. The log output is
> displayed if the test fails like (the test was modified to make it
> fail):
>
> ```
> TE
Include to make sure arch_cpu_idle_dead() matches its
prototype going forward.
Signed-off-by: Josh Poimboeuf
---
arch/alpha/kernel/process.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index 0eddd22c6212..4813172547b5 100644
---
arch_cpu_idle_dead() doesn't return. Make that more explicit with a
BUG().
BUG() is preferable to unreachable() because BUG() is a more explicit
failure mode and avoids undefined behavior like falling off the edge of
the function into whatever code happens to be next.
Signed-off-by: Josh Poimboe
These are some minor changes to enable the __noreturn attribute for
arch_cpu_idle_dead(). (If there are no objections, I can merge the
entire set through the tip tree.)
Until recently [1], in Xen, when a previously offlined CPU was brought
back online, it unexpectedly resumed execution where it l
arch_cpu_idle_dead() doesn't return. Make that more explicit with a
BUG().
BUG() is preferable to unreachable() because BUG() is a more explicit
failure mode and avoids undefined behavior like falling off the edge of
the function into whatever code happens to be next.
Signed-off-by: Josh Poimboe
cpu_die() doesn't return. Annotate it as such. By extension this also
makes arch_cpu_idle_dead() noreturn.
Signed-off-by: Josh Poimboeuf
---
arch/arm64/include/asm/smp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/sm
arch_cpu_idle_dead() doesn't return. Make that more explicit with a
BUG().
BUG() is preferable to unreachable() because BUG() is a more explicit
failure mode and avoids undefined behavior like falling off the edge of
the function into whatever code happens to be next.
Signed-off-by: Josh Poimboe
play_dead() doesn't return. Annotate it as such. By extension this
also makes arch_cpu_idle_dead() noreturn.
Signed-off-by: Josh Poimboeuf
---
arch/ia64/kernel/process.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/proces
play_dead() doesn't return. Make that more explicit with a BUG().
BUG() is preferable to unreachable() because BUG() is a more explicit
failure mode and avoids undefined behavior like falling off the edge of
the function into whatever code happens to be next.
Signed-off-by: Josh Poimboeuf
---
play_dead() doesn't return. Annotate it as such. By extension this
also makes arch_cpu_idle_dead() noreturn.
Signed-off-by: Josh Poimboeuf
---
arch/loongarch/include/asm/smp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/loongarch/include/asm/smp.h b/arch/loongarch/
Include to make sure play_dead() matches its prototype going
forward.
Signed-off-by: Josh Poimboeuf
---
arch/mips/kernel/smp-bmips.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
index f5d7bfa3472a..df9158e8329d 100644
--- a/arch
play_dead() doesn't return. Annotate it as such. By extension this
also makes arch_cpu_idle_dead() noreturn.
Signed-off-by: Josh Poimboeuf
---
arch/mips/include/asm/smp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/smp.h b/arch/mips/include/asm/smp
play_dead() doesn't return. Make that more explicit with a BUG().
BUG() is preferable to unreachable() because BUG() is a more explicit
failure mode and avoids undefined behavior like falling off the edge of
the function into whatever code happens to be next.
Signed-off-by: Josh Poimboeuf
---
start_secondary_resume() doesn't return. Annotate it as such. By
extension this also makes arch_cpu_idle_dead() noreturn.
Signed-off-by: Josh Poimboeuf
---
arch/powerpc/include/asm/smp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/p
play_dead() doesn't return. Annotate it as such. By extension this
also makes arch_cpu_idle_dead() noreturn.
Signed-off-by: Josh Poimboeuf
---
arch/sh/include/asm/smp-ops.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/sh/include/asm/smp-ops.h b/arch/sh/include/a
play_dead() doesn't return. Make that more explicit with a BUG().
BUG() is preferable to unreachable() because BUG() is a more explicit
failure mode and avoids undefined behavior like falling off the edge of
the function into whatever code happens to be next.
Signed-off-by: Josh Poimboeuf
---
cpu_play_dead() doesn't return. Annotate it as such. By extension this
also makes arch_cpu_idle_dead() noreturn.
Signed-off-by: Josh Poimboeuf
---
arch/sparc/include/asm/smp_64.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sparc/include/asm/smp_64.h b/arch/sparc/in
Include to make sure arch_cpu_idle_dead() matches its
prototype going forward.
Signed-off-by: Josh Poimboeuf
---
arch/sh/kernel/idle.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/sh/kernel/idle.c b/arch/sh/kernel/idle.c
index 3418c40f0099..114f0c4abeac 100644
--- a/arch/sh/kernel/i
After commit 076cbf5d2163 ("x86/xen: don't let xen_pv_play_dead()
return"), play_dead() never returns. Make that more explicit with a
BUG().
BUG() is preferable to unreachable() because BUG() is a more explicit
failure mode and avoids undefined behavior like falling off the edge of
the function i
cpu_die() doesn't return. Make that more explicit with a BUG().
BUG() is preferable to unreachable() because BUG() is a more explicit
failure mode and avoids undefined behavior like falling off the edge of
the function into whatever code happens to be next.
Signed-off-by: Josh Poimboeuf
---
ar
play_dead() doesn't return. Annotate it as such. By extension this
also makes arch_cpu_idle_dead() noreturn.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/smp.h | 2 +-
arch/x86/kernel/process.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/a
cpu_die() doesn't return. Annotate it as such. By extension this also
makes arch_cpu_idle_dead() noreturn.
Signed-off-by: Josh Poimboeuf
---
arch/xtensa/include/asm/smp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/xtensa/include/asm/smp.h b/arch/xtensa/include/asm
arch_cpu_idle_dead() should never return. Make it so.
Signed-off-by: Josh Poimboeuf
---
kernel/sched/idle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index e9ef66be2870..56e152f06d0f 100644
--- a/kernel/sched/idle.c
+++ b/kerne
Before commit 076cbf5d2163 ("x86/xen: don't let xen_pv_play_dead()
return"), in Xen, when a previously offlined CPU was brought back
online, it unexpectedly resumed execution where it left off in the
middle of the idle loop.
There were some hacks to make that work, but the behavior was surprising
On 2/1/23 19:07, Shuah Khan wrote:
Hi Mathieu,
On 1/30/23 15:29, Shuah Khan wrote:
On 1/27/23 06:57, Mathieu Desnoyers wrote:
Hi,
This series fixes incorrect kernel header search path in kernel
selftests.
Near the end of the series, a few changes are not tagged as "Fixes"
because the current
On Sat, Feb 4, 2023 at 6:05 AM Josh Poimboeuf wrote:
>
> arch_cpu_idle_dead() doesn't return. Make that more explicit with a
> BUG().
>
> BUG() is preferable to unreachable() because BUG() is a more explicit
> failure mode and avoids undefined behavior like falling off the edge of
> the function
On Sat, Feb 04, 2023 at 09:12:31AM +0800, Guo Ren wrote:
> On Sat, Feb 4, 2023 at 6:05 AM Josh Poimboeuf wrote:
> >
> > arch_cpu_idle_dead() doesn't return. Make that more explicit with a
> > BUG().
> >
> > BUG() is preferable to unreachable() because BUG() is a more explicit
> > failure mode and
74 matches
Mail list logo
