nfig
arm64allyesconfig
mips randconfig-c004-20211203
i386 randconfig-c001-20211203
i386 randconfig-c001-20211207
i386 randconfig-c001-20211206
mips ip27_defconfig
sh r7780mp_defconf
Hi all,
Today's linux-next merge of the bitmap tree got a conflict in:
arch/powerpc/include/asm/cputhreads.h
between commit:
b350111bf7b3 ("powerpc: remove cpu_online_cores_map function")
from the powerpc tree and commit:
4e258d05437b ("cpumask: replace cpumask_next_* with cpumask_first
On 07/12/21 8:22 pm, Arnaldo Carvalho de Melo wrote:
Em Fri, Dec 03, 2021 at 07:50:37AM +0530, Athira Rajeev escreveu:
Sort key p_stage_cyc is used to present the latency
cycles spend in pipeline stages. perf tool has local
p_stage_cyc sort key to display this info. There is no
global variant
randconfig-c001-20211207
m68k alldefconfig
arc tb10x_defconfig
arm tegra_defconfig
powerpc mpc837x_rdb_defconfig
h8300 edosk2674_defconfig
mips rs90_defconfig
mips
allmodconfig
mips randconfig-c004-20211203
i386 randconfig-c001-20211203
i386 randconfig-c001-20211206
i386 randconfig-c001-20211207
arm shannon_defconfig
powerpc
allmodconfig
i386 randconfig-c001-20211207
m68k alldefconfig
arc tb10x_defconfig
arm tegra_defconfig
powerpc mpc837x_rdb_defconfig
h8300 edosk2674_defconfig
mips
On Tue, 2021-12-07 at 09:44 -0500, Joe Lawrence wrote:
> On 11/23/21 3:15 AM, Russell Currey wrote:
>
> [[ cc += livepatching list ]]
>
> Hi Russell,
>
> Thanks for writing a minimal fix for stable / backporting. As I
> mentioned on the github issue [1], this avoided the crashes I
> reported
>
On Mon, Dec 06, 2021 at 11:28:00PM +0100, Thomas Gleixner wrote:
> The irqdomain code already returns the information. Move the loop to the
> legacy code.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci
On Mon, Dec 06, 2021 at 11:27:59PM +0100, Thomas Gleixner wrote:
> Get rid of yet another irqdomain callback and let the core code return the
> already available information of how many descriptors could be allocated.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: J
On Mon, Dec 06, 2021 at 11:27:57PM +0100, Thomas Gleixner wrote:
> No users outside of that file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/irqdomain.c |5 +++--
> include/linux/msi.h
On Mon, Dec 06, 2021 at 11:27:56PM +0100, Thomas Gleixner wrote:
> It's only required for PCI/MSI. So no point in having it in every struct
> device.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> V2: New patch
> ---
> drivers/base/core.c|1 -
> drivers/pci/msi/msi
On Mon, Dec 06, 2021 at 11:27:54PM +0100, Thomas Gleixner wrote:
> Unmapping the MSIX base mapping in the loops which allocate/free MSI
> desciptors is daft and in the way of allowing runtime expansion of MSI-X
> descriptors.
s/MSIX/MSI-X/ (subject and first use in commit log)
s/desciptors/descrip
On Mon, Dec 06, 2021 at 11:27:52PM +0100, Thomas Gleixner wrote:
> Move the irqdomain specific code into it's own file.
s/it's/its/
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/Makefile|1
On Mon, Dec 06, 2021 at 11:27:51PM +0100, Thomas Gleixner wrote:
> Split out the non irqdomain code into its own file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> V2: Add proper includes and fix variable name -
On Mon, Dec 06, 2021 at 11:27:49PM +0100, Thomas Gleixner wrote:
> These functions are required even when CONFIG_PCI_MSI is not set. Move them
> to their own file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> dr
On Mon, Dec 06, 2021 at 11:27:47PM +0100, Thomas Gleixner wrote:
> msi.c is getting larger and really could do with a splitup. Move it into
> it's own directory to prepare for that.
s/it's/its/
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by
On Mon, Dec 06, 2021 at 11:27:46PM +0100, Thomas Gleixner wrote:
> No need to walk the descriptors and check for each one whether the entries
> pointer function argument is NULL. Do it once.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by:
On Mon, Dec 06, 2021 at 11:27:44PM +0100, Thomas Gleixner wrote:
> Get rid of the pile of unneeded includes which accumulated over time.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
Nice, thanks!
> ---
> V2: Address bui
On Mon, Dec 06, 2021 at 11:27:42PM +0100, Thomas Gleixner wrote:
> Make arch_restore_msi_irqs() return a boolean which indicates whether the
> core code should restore the MSI message or not. Get rid of the indirection
> in x86.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Rev
On Mon, Dec 06, 2021 at 11:27:36PM +0100, Thomas Gleixner wrote:
> instead of fiddling with msi descriptors.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
s/msi/MSI/ above if you have a chance. Nice cleanup, thanks!
> -
On Mon, Dec 06, 2021 at 11:27:34PM +0100, Thomas Gleixner wrote:
> Last user is gone long ago.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi.c |8
> include/linux/msi.h |5 -
On Mon, Dec 06, 2021 at 11:27:33PM +0100, Thomas Gleixner wrote:
> There is no point to have this function public as it is set by the PCI core
> anyway when a PCI/MSI irqdomain is created.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bj
On Mon, Dec 06, 2021 at 11:27:26PM +0100, Thomas Gleixner wrote:
> pci_irq_vector() and pci_irq_get_affinity() use the list position to find the
> MSI-X descriptor at a given index. That's correct for the normal case where
> the entry number is the same as the list position.
>
> But it's wrong for
Cedric,
On Tue, Dec 07 2021 at 16:50, Cédric Le Goater wrote:
> On 12/7/21 12:36, Michael Ellerman wrote:
>>
>> This patch should drop those selects I guess. Can you send an
>> incremental diff for Thomas to squash in?
>
> Sure.
>
>> Removing all the tendrils in various device tree files will pro
Le 07/12/2021 à 11:34, Maxime Bizon a écrit :
>
> On Tue, 2021-12-07 at 06:10 +, Christophe Leroy wrote:
>
> Hello,
>
> With the patch applied and
>
> CONFIG_DEBUG_PAGEALLOC=y
> CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y
> CONFIG_DEBUG_VM=y
>
> I get tons of this during boot:
>
> [0.00
On Tue, Dec 07, 2021 at 05:10:14PM +0100, Philipp Rudo wrote:
> Hi Michal,
>
> i finally had the time to take a closer look at the series. Except for
> the nit in patch 4 and my personal preference in patch 6 the code looks
> good to me.
>
> What I don't like are the commit messages on the first
On 07/12/2021, 18:18:40, Laurent Dufour wrote:
> On 07/12/2021, 18:07:50, Nathan Lynch wrote:
>> Laurent Dufour writes:
>>> On 07/12/2021, 15:32:39, Nathan Lynch wrote:
Is there a reasonable fallback for VMs where this parameter doesn't
exist? PowerVM partitions should always have it, bu
On 07/12/2021, 18:07:50, Nathan Lynch wrote:
> Laurent Dufour writes:
>> On 07/12/2021, 15:32:39, Nathan Lynch wrote:
>>> Is there a reasonable fallback for VMs where this parameter doesn't
>>> exist? PowerVM partitions should always have it, but what do we want the
>>> behavior to be on other hyp
The LPAR name may be changed after the LPAR has been started in the HMC.
In that case lparstat command is not reporting the updated value because it
reads it from the device tree which is read at boot time.
However this value could be read from RTAS.
Adding this value in the /proc/powerpc/lparcfg
Laurent Dufour writes:
> On 07/12/2021, 15:32:39, Nathan Lynch wrote:
>> Is there a reasonable fallback for VMs where this parameter doesn't
>> exist? PowerVM partitions should always have it, but what do we want the
>> behavior to be on other hypervisors?
>
> In that case, there is no value displ
On Tue, Dec 07, 2021 at 12:02:28PM +0100, Anders Roxell wrote:
> Clang warns:
>
> arch/powerpc/platforms/cell/pervasive.c:81:2: error: unannotated fall-through
> between switch labels [-Werror,-Wimplicit-fallthrough]
> case SRR1_WAKEEE:
> ^
> arch/powerpc/platforms/cell/pervasive.
Hi Michal,
On Thu, 25 Nov 2021 19:02:42 +0100
Michal Suchanek wrote:
> It is stripped by each caller separately.
>
> Signed-off-by: Michal Suchanek
> ---
> arch/powerpc/kexec/elf_64.c | 9 -
> arch/s390/kernel/machine_kexec_file.c | 9 -
> kernel/module.c
Hi Michal,
i finally had the time to take a closer look at the series. Except for
the nit in patch 4 and my personal preference in patch 6 the code looks
good to me.
What I don't like are the commit messages on the first commits. In my
opinion they are so short that they are almost useless. For e
Hi Michal,
On Thu, 25 Nov 2021 19:02:44 +0100
Michal Suchanek wrote:
> Multiple users of mod_check_sig check for the marker, then call
> mod_check_sig, extract signature length, and remove the signature.
>
> Put this code in one place together with mod_check_sig.
>
> Signed-off-by: Michal Such
On 07/12/2021, 15:32:39, Nathan Lynch wrote:
> Hi Laurent,
>
> Laurent Dufour writes:
>> +/*
>> + * PAPR defines, in section "7.3.16 System Parameters Option", the token 55
>> to
>> + * read the LPAR name.
>> + */
>> +#define SPLPAR_LPAR_NAME_TOKEN 55
>> +static void read_lpar_name(struct s
On 12/7/21 12:36, Michael Ellerman wrote:
Cédric Le Goater writes:
Hello Thomas,
On 12/6/21 23:27, Thomas Gleixner wrote:
This code is broken since day one. ppc4xx_setup_msi_irqs() has the
following gems:
1) The handling of the result of msi_bitmap_alloc_hwirqs() is completely
broke
Em Fri, Dec 03, 2021 at 07:50:37AM +0530, Athira Rajeev escreveu:
> Sort key p_stage_cyc is used to present the latency
> cycles spend in pipeline stages. perf tool has local
> p_stage_cyc sort key to display this info. There is no
> global variant available for this sort key. local variant
> shows
On 11/23/21 3:15 AM, Russell Currey wrote:
> Livepatching a loaded module involves applying relocations through
> apply_relocate_add(), which attempts to write to read-only memory when
> CONFIG_STRICT_MODULE_RWX=y. Work around this by performing these
> writes through the text poke area by using p
Hi Laurent,
Laurent Dufour writes:
> +/*
> + * PAPR defines, in section "7.3.16 System Parameters Option", the token 55
> to
> + * read the LPAR name.
> + */
> +#define SPLPAR_LPAR_NAME_TOKEN 55
> +static void read_lpar_name(struct seq_file *m)
> +{
> + int rc, len, token;
> + unio
On Fri, 19 Nov 2021 21:31:41 +1000, Nicholas Piggin wrote:
> These are some watchdog fixes and improvements, in particular a
> deadlock between the wd_smp_lock and console lock when the watchdog
> fires, found by Laurent.
>
> Thanks,
> Nick
>
> [...]
Patch 5 applied to powerpc/next.
[5/5] power
On Mon, 29 Nov 2021 13:09:15 +1000, Nicholas Piggin wrote:
> Allow the LPID bit width and partition table size to be set at runtime
> from the device tree.
>
> Move the PID bit width detection into the same place.
>
> KVM does not support using the extra bits yet, this is mainly required
> to get
On Fri, 22 Oct 2021 16:13:22 +1000, Nicholas Piggin wrote:
> Introduce macros that operate on a (start, end) range of GPRs, which
> reduces lines of code and need to do mental arithmetic while reading the
> code.
>
>
Applied to powerpc/next.
[1/1] powerpc: flexible GPR range save/restore macros
On Fri, 5 Nov 2021 13:50:41 +1000, Nicholas Piggin wrote:
> This function builds the cores online map with on-stack cpumasks which
> can cause high stack usage with large NR_CPUS.
>
> It is not used in any performance sensitive paths, so instead just check
> for first thread sibling.
>
>
> [...]
On Wed, 24 Nov 2021 20:32:49 +1100, Michael Ellerman wrote:
> Fixes the following W=1 warning:
> arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c:89:12: warning: no previous
> prototype for 'mpc85xx_setup_pmc'
>
>
Applied to powerpc/next.
[1/6] powerpc/85xx: Fix no previous prototype warning for
On Thu, 18 Nov 2021 12:36:04 -0800, Kees Cook wrote:
> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field bounds checking for memset(), avoid intentionally writing across
> neighboring fields.
>
> Add a struct_group() for the spe registers so that memset() can correctly
On Wed, 1 Dec 2021 17:54:18 +0100, Cédric Le Goater wrote:
> The automatic "save & restore" of interrupt context is a POWER10/XIVE2
> feature exploited by KVM under the PowerNV platform. It is not
> available under pSeries and the associated toggle should not be
> exposed under the XIVE debugfs dir
On Tue, 21 Sep 2021 17:09:47 +0200, Christophe Leroy wrote:
> Today we get the following code generation for bitops like
> set or clear bit:
>
> c0009fe0: 39 40 08 00 li r10,2048
> c0009fe4: 7c e0 40 28 lwarx r7,0,r8
> c0009fe8: 7c e7 53 78 or
On Thu, 28 Oct 2021 14:24:00 +0200, Christophe Leroy wrote:
> This series implements livepatch on PPC32.
>
> This is largely copied from what's done on PPC64.
>
> Christophe Leroy (5):
> livepatch: Fix build failure on 32 bits processors
> powerpc/ftrace: No need to read LR from stack in _mco
On Fri, 26 Nov 2021 11:30:03 +0100, Christophe Leroy wrote:
> We have wrong units on BAT's sizes (G instead of M, M instead of ...)
>
> ---[ Instruction Block Address Translation ]---
> 0: 0xc000-0xc03f 0x 4G Kernel x m
> 1: 0xc040-0xc05f 0x0
On Tue, 30 Nov 2021 10:32:42 +0100, Christophe Leroy wrote:
> KeyWest i2c @0xf8001003 irq 42 /uni-n@f800/i2c@f8001000
> BUG: key c2d00cbc has not been registered!
> [ cut here ]
> DEBUG_LOCKS_WARN_ON(1)
> WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:4801
> lockdep
On Tue, 30 Nov 2021 11:10:43 +0100, Christophe Leroy wrote:
> module_alloc() first tries to allocate module text within
> 24 bits direct jump from kernel text, and tries a wider
> allocation if first one fails.
>
> When first allocation fails the following is observed in kernel logs:
>
> vmap all
On Thu, 25 Nov 2021 12:43:33 +0100, Christophe Leroy wrote:
> Since commit 9a427556fb8e ("vmlinux.lds.h: catch compound literals
> into data and BSS") .data..Lubsan sections are taken into account
> in DATA_MAIN which is included in DATA_DATA macro.
>
> No need to take care of them anymore in powe
On Tue, 30 Nov 2021 09:42:37 +0100, Christophe Leroy wrote:
>
> UBSAN: shift-out-of-bounds in arch/powerpc/mm/kasan/book3s_32.c:22:23
> shift exponent -1 is negative
> CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.5-gen
On Wed, 21 Jul 2021 01:48:28 -0400, Athira Rajeev wrote:
> Running perf fuzzer testsuite popped up below messages
> in the dmesg logs:
>
> "Can't find PMC that caused IRQ"
>
> This means a PMU exception happened, but none of the PMC's (Performance
> Monitor Counter) were found to be overflown. Pe
From: Wang Qing
of_find_device_by_node() takes a reference to the embedded struct device
which needs to be dropped when error return.
Signed-off-by: Wang Qing
---
sound/soc/fsl/imx-hdmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c
i
A mis-match between reported and actual mitigation is not restricted to the
Vulnerable case. The guest might also report the mitigation as "Software
count cache flush" and the host will still mitigate with branch cache
disabled.
So, instead of skipping depending on the detected mitigation, simply
On Tue, Dec 7, 2021 at 12:02 PM Anders Roxell wrote:
>
> Clang warns:
>
> arch/powerpc/platforms/cell/pervasive.c:81:2: error: unannotated fall-through
> between switch labels [-Werror,-Wimplicit-fallthrough]
> case SRR1_WAKEEE:
> ^
> arch/powerpc/platforms/cell/pervasive.c:81:2:
Nicholas Piggin writes:
> Compiling out hash support code when CONFIG_PPC_64S_HASH_MMU=n saves
> 128kB kernel image size (90kB text) on powernv_defconfig minus KVM,
> 350kB on pseries_defconfig minus KVM, 40kB on a tiny config.
>
> Signed-off-by: Nicholas Piggin
> ---
> arch/powerpc/Kconfig
Nicholas Piggin writes:
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h
> b/arch/powerpc/include/asm/book3s/64/mmu.h
> index 015d7d972d16..c480d21a146c 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
> @@ -239,8 +251,9 @@ static inl
Cédric Le Goater writes:
> Hello Thomas,
>
> On 12/6/21 23:27, Thomas Gleixner wrote:
>> This code is broken since day one. ppc4xx_setup_msi_irqs() has the
>> following gems:
>>
>> 1) The handling of the result of msi_bitmap_alloc_hwirqs() is completely
>> broken:
>>
>> When the
Nathan Chancellor writes:
> On Tue, Dec 07, 2021 at 02:37:26PM +1100, Michael Ellerman wrote:
>> Bill Wendling writes:
>> > On Tue, Nov 30, 2021 at 10:38 AM Bill Wendling wrote:
>> >> On Tue, Nov 30, 2021 at 10:17 AM Nathan Chancellor
>> >> wrote:
>> >> > On Tue, Nov 30, 2021 at 10:25:43PM +11
Clang warns:
arch/powerpc/platforms/cell/pervasive.c:81:2: error: unannotated fall-through
between switch labels [-Werror,-Wimplicit-fallthrough]
case SRR1_WAKEEE:
^
arch/powerpc/platforms/cell/pervasive.c:81:2: note: insert 'break;' to avoid
fall-through
case SRR1_WAKEEE
In panic path, fadump is triggered via a panic notifier function.
Before calling panic notifier functions, smp_send_stop() gets called,
which stops all CPUs except the panic'ing CPU. Commit 8389b37dffdc
("powerpc: stop_this_cpu: remove the cpu from the online map.") and
again commit bab26238bbd4 ("
Kdump can be triggered after panic_notifers since commit f06e5153f4ae2
("kernel/panic.c: add "crash_kexec_post_notifiers" option for kdump
after panic_notifers") introduced crash_kexec_post_notifiers option.
But using this option would mean smp_send_stop(), that marks all other
CPUs as offline, get
On Tue, 2021-12-07 at 06:10 +, Christophe Leroy wrote:
Hello,
With the patch applied and
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y
CONFIG_DEBUG_VM=y
I get tons of this during boot:
[0.00] Dentry cache hash table entries: 262144 (order: 8, 1048576
bytes, li
On Mon, 2021-12-06 at 14:12 +, Christophe Leroy wrote:
Tested-by: Maxime Bizon
--
Maxime
On Tue, 2021-12-07 at 05:54 +, Christophe Leroy wrote:
>
> Did you check with my latest patch (v2) ?
>
yes I did, works perfectly, I just sent the Tested-By
--
Maxime
On Mon, 2021-12-06 at 11:11 +, Christophe Leroy wrote:
>
> Reported-by: Maxime Bizon
Tested-by: Maxime Bizon
maybe stable ? I had this on 5.15
Thanks !
--
Maxime
68 matches
Mail list logo
