On Thu, Dec 14, 2023 at 05:55:33AM +, Nicholas Miehlbradt wrote:
> KMSAN does not unpoison the ainsn field of a kprobe struct correctly.
> Manually unpoison it to prevent false positives.
>
> Signed-off-by: Nicholas Miehlbradt
> ---
> arch/powerpc/kernel/kprobes.c | 2 ++
> 1 file changed,
Hello Baoquan,
On 15/12/23 07:58, Baoquan He wrote:
On 12/11/23 at 02:00pm, Sourabh Jain wrote:
The commit a72bbec70da2 ("crash: hotplug support for kexec_load()")
introduced a new kexec flag, `KEXEC_UPDATE_ELFCOREHDR`. Kexec tool uses
this flag to indicate kernel that it is safe to modify the
From: George Stark
Using of devm API leads to a certain order of releasing resources.
So all dependent resources which are not devm-wrapped should be deleted
with respect to devm-release order. Mutex is one of such objects that
often is bound to other resources and has no own devm wrapping.
On 15/12/23 06:53, Baoquan He wrote:
On 12/11/23 at 02:00pm, Sourabh Jain wrote:
..
diff --git a/arch/powerpc/include/asm/kexec_ranges.h
b/arch/powerpc/include/asm/kexec_ranges.h
index f83866a19e87..802abf580cf0 100644
--- a/arch/powerpc/include/asm/kexec_ranges.h
+++
Hello Baoquan,
On 14/12/23 19:43, Baoquan He wrote:
On 12/11/23 at 02:00pm, Sourabh Jain wrote:
Architectures' specific functions `arch_crash_hotplug_cpu_support()` and
`arch_crash_hotplug_memory_support()` advertise the kernel's capability
to update the kdump image on CPU and Memory hotplug
Le 14/12/2023 à 22:48, Waiman Long a écrit :
> On 12/14/23 14:53, Christophe Leroy wrote:
>>
>> Le 14/12/2023 à 19:48, Waiman Long a écrit :
>>> On 12/14/23 12:36, George Stark wrote:
Using of devm API leads to a certain order of releasing resources.
So all dependent resources which
Srikar Dronamraju writes:
> If there are shared processor LPARs, underlying Hypervisor can have more
> virtual cores to handle than actual physical cores.
>
> Starting with Power 9, a big core (aka SMT8 core) has 2 nearly
> independent thread groups. On a shared processors LPARs, it helps to
>
On 12/11/23 at 02:00pm, Sourabh Jain wrote:
> The commit a72bbec70da2 ("crash: hotplug support for kexec_load()")
> introduced a new kexec flag, `KEXEC_UPDATE_ELFCOREHDR`. Kexec tool uses
> this flag to indicate kernel that it is safe to modify the elfcorehdr
> of kdump image loaded using
On 12/11/23 at 02:00pm, Sourabh Jain wrote:
..
> diff --git a/arch/powerpc/include/asm/kexec_ranges.h
> b/arch/powerpc/include/asm/kexec_ranges.h
> index f83866a19e87..802abf580cf0 100644
> --- a/arch/powerpc/include/asm/kexec_ranges.h
> +++ b/arch/powerpc/include/asm/kexec_ranges.h
> @@
On 12/14/23 14:53, Christophe Leroy wrote:
Le 14/12/2023 à 19:48, Waiman Long a écrit :
On 12/14/23 12:36, George Stark wrote:
Using of devm API leads to a certain order of releasing resources.
So all dependent resources which are not devm-wrapped should be deleted
with respect to
On 12/14/23 4:18 AM, Aneesh Kumar K.V wrote:
Gaurav Batra writes:
When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due to
NULL pointer execption.
Here is the complete stack
[ 19.944378] Kernel attempted to read user page (0) - exploit attempt? (uid:
0)^M
[
Le 14/12/2023 à 19:48, Waiman Long a écrit :
>
> On 12/14/23 12:36, George Stark wrote:
>> Using of devm API leads to a certain order of releasing resources.
>> So all dependent resources which are not devm-wrapped should be deleted
>> with respect to devm-release order. Mutex is one of such
Le 14/12/2023 à 18:36, George Stark a écrit :
> [Vous ne recevez pas souvent de courriers de gnst...@salutedevices.com.
> Découvrez pourquoi ceci est important à
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Using of devm API leads to a certain order of releasing resources.
> So all
On 12/14/23 12:36, George Stark wrote:
Using of devm API leads to a certain order of releasing resources.
So all dependent resources which are not devm-wrapped should be deleted
with respect to devm-release order. Mutex is one of such objects that
often is bound to other resources and has no
Currently there are four Powerpc specific sched topologies. These are
all statically defined. However not all these topologies are used by
all Powerpc systems.
To avoid unnecessary degenerations by the scheduler, masks and flags
are compared. However if the sched topologies are build
There are some variables that are only updated at boot time.
So add __ro_after_init attribute to such variables
Signed-off-by: Srikar Dronamraju
---
Changelog:
v2 -> v3:
Use __ro_after_init instead of __read_mostly
Suggested by : Peter Zijlstra and Michael Ellerman
arch/powerpc/kernel/smp.c |
PowerVM Hypervisor will schedule at a core granularity. However each
core can have more than one thread_groups. For better utilization in
case of a shared processor, its preferable for the scheduler to pack to
the lowest core. However there is no benefit of moving a thread between
two thread
Like L2-cache info, coregroup information which is used to determine MC
sched domains is only present on dedicated LPARs. i.e PowerVM doesn't
export coregroup information for shared processor LPARs. Hence disable
creating MC domains on shared LPAR Systems.
Signed-off-by: Srikar Dronamraju
---
PowerVM systems configured in shared processors mode have some unique
challenges. Some device-tree properties will be missing on a shared
processor. Hence some sched domains may not make sense for shared processor
systems.
Most shared processor systems are over-provisioned. Underlying PowerVM
If there are shared processor LPARs, underlying Hypervisor can have more
virtual cores to handle than actual physical cores.
Starting with Power 9, a big core (aka SMT8 core) has 2 nearly
independent thread groups. On a shared processors LPARs, it helps to
pack threads to lesser number of cores
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's
This driver wants to keep its LEDs state after module is removed
and implemented it in its own way. LED subsystem supports dedicated
flag LED_RETAIN_AT_SHUTDOWN for the same purpose so use the flag
instead of custom implementation.
Signed-off-by: George Stark
---
drivers/leds/leds-powernv.c |
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
In the probe() callback in case of error mutex is destroyed being locked
which is not allowed so unlock the mutex before destroying.
Fixes: 59ea3c9faf32 ("leds: add aw2013 driver")
Signed-off-by: George Stark
Reviewed-by: Andy Shevchenko
---
drivers/leds/leds-aw2013.c | 1 +
1 file changed, 1
This patch series fixes the problem of devm_led_classdev_register misusing.
The basic problem is described in [1]. Shortly when devm_led_classdev_register()
is used then led_classdev_unregister() called after driver's remove() callback.
led_classdev_unregister() calls driver's brightness_set
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's
Using of devm API leads to a certain order of releasing resources.
So all dependent resources which are not devm-wrapped should be deleted
with respect to devm-release order. Mutex is one of such objects that
often is bound to other resources and has no own devm wrapping.
Since mutex_destroy()
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
On 12/11/23 at 02:00pm, Sourabh Jain wrote:
> Architectures' specific functions `arch_crash_hotplug_cpu_support()` and
> `arch_crash_hotplug_memory_support()` advertise the kernel's capability
> to update the kdump image on CPU and Memory hotplug events to userspace
> via the sysfs interface.
On Thu, Dec 14, 2023 at 03:58:56PM +0300, George Stark wrote:
> On 12/14/23 08:42, Nikita Travkin wrote:
> > George Stark писал(а) 14.12.2023 03:30:
...
> > Btw, seems like (5..11)/11 never arrived to the lists...
>
> Yeah there was a delay, but now all patches from series #3 are online.
On Thu, Dec 14, 2023 at 3:00 PM Christophe Leroy
wrote:
> Le 14/12/2023 à 13:48, George Stark a écrit :
> > [Vous ne recevez pas souvent de courriers de gnst...@salutedevices.com.
> > Découvrez pourquoi ceci est important à
> > https://aka.ms/LearnAboutSenderIdentification ]
> > On 12/14/23
Le 14/12/2023 à 13:48, George Stark a écrit :
> [Vous ne recevez pas souvent de courriers de gnst...@salutedevices.com.
> Découvrez pourquoi ceci est important à
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Hello Christophe
>
> On 12/14/23 13:06, Christophe Leroy wrote:
>>
>>
> ...
Hello Nikita
Thanks for the review and testing.
On 12/14/23 08:42, Nikita Travkin wrote:
George Stark писал(а) 14.12.2023 03:30:
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
Hello Christophe
On 12/14/23 13:06, Christophe Leroy wrote:
...
So you abandonned the idea of using mutex.h ?
I'm not the one who make a choice here. The patch [1] you're talking
about was seen by everyone but it seems like no one had shown interest.
For me personally approach with
On 13/12/2023 06:17, Michael Ellerman wrote:
David Heidelberg writes:
fsl,tmu-calibration is in u32-matrix. Use matching property syntax.
No functional changes. Fixes warnings as:
$ make dtbs_check
...
arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dt.yaml: tmu@3026:
Hi Gaurav,
kernel test robot noticed the following build warnings:
[auto build test WARNING on powerpc/next]
[also build test WARNING on powerpc/fixes linus/master v6.7-rc5 next-20231214]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
Hi,
On 12/14/23 11:06, Christophe Leroy wrote:
>
>
> Le 13/12/2023 à 23:30, George Stark a écrit :
>> [Vous ne recevez pas souvent de courriers de gnst...@salutedevices.com.
>> Découvrez pourquoi ceci est important à
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Using of devm API
From: Christophe Leroy
Replace all usages of of_root by of_find_node_by_path("/")
Signed-off-by: Christophe Leroy
Reviewed-by: Rob Herring
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/secure_boot.c| 8 ++--
arch/powerpc/kexec/ranges.c | 8 +---
From: Christophe Leroy
Most probe functions that do not use the 'compatible' string do
nothing else than checking whether the machine is compatible with
one of the strings in a NULL terminated table of strings.
Define that table of strings in ppc_md structure and check it directly
from
From: Christophe Leroy
of_machine_compatible_match() works with a table of strings.
of_machine_is_compatible() is a simplier version with only one string.
Re-implement of_machine_is_compatible() by setting a table of strings
with a single string then using of_machine_compatible_match().
of_machine_is_compatible() currently returns a positive integer if it
finds a match. However none of the callers ever check the value, they
all treat it as a true/false.
So change of_machine_is_compatible() to return bool, which will allow
the implementation to be changed in a subsequent patch.
We have of_machine_is_compatible() to check if a machine is compatible
with a single compatible string. However some code is able to support
multiple compatible boards, and so wants to check for one of many
compatible strings.
So add of_machine_compatible_match() which takes a NULL terminated
Gaurav Batra writes:
> When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due to
> NULL pointer execption.
>
> Here is the complete stack
>
> [ 19.944378] Kernel attempted to read user page (0) - exploit attempt?
> (uid: 0)^M
> [ 19.944388] BUG: Kernel NULL pointer
Le 13/12/2023 à 23:30, George Stark a écrit :
> [Vous ne recevez pas souvent de courriers de gnst...@salutedevices.com.
> Découvrez pourquoi ceci est important à
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Using of devm API leads to a certain order of releasing resources.
> So all
Le 14/12/2023 à 06:55, Nicholas Miehlbradt a écrit :
> Enable KMSAN in the Kconfig.
>
> Signed-off-by: Nicholas Miehlbradt
> ---
> arch/powerpc/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index e33e3250c478..71cc7d2a0a72
Le 14/12/2023 à 06:55, Nicholas Miehlbradt a écrit :
> KMSAN expects functions __mem{set,cpy,move} so add aliases pointing to
> the respective functions.
>
> Disable use of architecture specific memset{16,32,64} to ensure that
> metadata is correctly updated and strn{cpy,cmp} and mem{chr,cmp}
Le 14/12/2023 à 06:55, Nicholas Miehlbradt a écrit :
> arch_kmsan_get_meta_or_null finds the metadata addresses for addresses
> in the ioremap region which is mapped separately on powerpc.
>
> kmsan_vir_addr_valid is the same as virt_addr_valid except excludes the
> check that addr is less than
Le 14/12/2023 à 06:55, Nicholas Miehlbradt a écrit :
> Splits the vmalloc region into four. The first quarter is the new
> vmalloc region, the second is used to store shadow metadata and the
> third is used to store origin metadata. The fourth quarter is unused.
>
> Do the same for the ioremap
Hi,
On 12/13/23 23:38, Andy Shevchenko wrote:
> On Thu, Dec 14, 2023 at 12:36 AM Andy Shevchenko
> wrote:
>> On Thu, Dec 14, 2023 at 12:30 AM George Stark
>> wrote:
>>>
>>> Using of devm API leads to a certain order of releasing resources.
>>> So all dependent resources which are not
Le 14/12/2023 à 06:55, Nicholas Miehlbradt a écrit :
> Functions which walk the stack read parts of the stack which cannot be
> instrumented by KMSAN e.g. the backchain. Disable KMSAN sanitization of
> these functions to prevent false positives.
Do other architectures have to do it as well ?
I
Le 14/12/2023 à 06:55, Nicholas Miehlbradt a écrit :
> Word sized accesses may read uninitialized data when optimizing loads.
> Disable this optimization when KMSAN is enabled to prevent false
> positives.
>
> Signed-off-by: Nicholas Miehlbradt
> ---
> arch/powerpc/Kconfig | 2 +-
> 1 file
Le 14/12/2023 à 06:55, Nicholas Miehlbradt a écrit :
> All elements of bounce_buffer are eventually read and passed to the
> hypervisor so it should probably be fully initialized.
should or shall ?
>
> Signed-off-by: Nicholas Miehlbradt
Should be a Fixed: tag ?
> ---
>
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses resources which were destroyed already
in module's
This driver wants to keep its LEDs state after module is removed
and implemented it in its own way. LED subsystem supports dedicated
flag LED_RETAIN_AT_SHUTDOWN for the same purpose so use the flag
instead of custom implementation.
Signed-off-by: George Stark
---
drivers/leds/leds-powernv.c |
62 matches
Mail list logo
