On 2019-10-16 06:57:48 [+0200], Christophe Leroy wrote:
>
>
> Le 15/10/2019 à 21:17, Sebastian Andrzej Siewior a écrit :
> > From: Thomas Gleixner
> >
> > CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT.
> > Both PREEMPT and PREEMPT_RT require the same functionality whi
On Tue, Oct 15, 2019 at 09:35:01AM +0200, Christoph Hellwig wrote:
> On Fri, Oct 11, 2019 at 06:25:19PM -0700, Ram Pai wrote:
> > From: Thiago Jung Bauermann
> >
> > Normally, virtio enables DMA API with VIRTIO_F_IOMMU_PLATFORM, which must
> > be set by both device and guest driver. However, as a
On Tue 15-10-19 20:51:11, Anshuman Khandual wrote:
>
>
> On 10/15/2019 08:11 PM, Qian Cai wrote:
> > The x86 will crash with linux-next during boot due to this series (v5) with
> > the
> > config below plus CONFIG_DEBUG_VM_PGTABLE=y. I am not sure if v6 would
> > address
> > it.
> >
> > https:
On Thu, Oct 10, 2019 at 05:05:46PM -0700, Kees Cook wrote:
> In preparation for moving NOTES into RO_DATA, move RO_DATA back into the
> "text" PT_LOAD Program Header, as done with other architectures. The
> "data" PT_LOAD now starts with the writable data section.
>
> Signed-off-by: Kees Cook
> -
On Thu, Oct 10, 2019 at 05:05:40PM -0700, Kees Cook wrote:
> Arch maintainers: please send Acks (if you haven't already) for your
> respective linker script changes; the intention is for this series to
> land via -tip.
>
> v1: https://lore.kernel.org/lkml/20190926175602.33098-1-keesc...@chromium.o
On 10/16/19 11:35 AM, Christoph Hellwig wrote:
On Wed, Oct 16, 2019 at 11:21:30AM +0530, Aneesh Kumar K.V wrote:
With commit: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel
regions in the same 0xc range"), kernel now split the 64TB address range
into 4 contexts each of 16TB. That implies w
On 10/16/2019 12:12 AM, Qian Cai wrote:
> On Tue, 2019-10-15 at 20:51 +0530, Anshuman Khandual wrote:
>>
>> On 10/15/2019 08:11 PM, Qian Cai wrote:
>>> The x86 will crash with linux-next during boot due to this series (v5) with
>>> the
>>> config below plus CONFIG_DEBUG_VM_PGTABLE=y. I am not s
Christoph Hellwig writes:
> On Wed, Oct 16, 2019 at 11:21:30AM +0530, Aneesh Kumar K.V wrote:
>> With commit: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel
>> regions in the same 0xc range"), kernel now split the 64TB address range
>> into 4 contexts each of 16TB. That implies we can do onl
Christophe Leroy writes:
> Le 15/10/2019 à 21:17, Sebastian Andrzej Siewior a écrit :
>> From: Thomas Gleixner
>>
>> CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT.
>> Both PREEMPT and PREEMPT_RT require the same functionality which today
>> depends on CONFIG_PREEMPT.
>
On 2019-10-16 20:33:08 [+1100], Michael Ellerman wrote:
> Christophe Leroy writes:
> > Le 15/10/2019 à 21:17, Sebastian Andrzej Siewior a écrit :
> >> From: Thomas Gleixner
> >>
> >> CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT.
> >> Both PREEMPT and PREEMPT_RT requir
On 10/15/2019 11:39 PM, Qian Cai wrote:
> On Tue, 2019-10-15 at 14:51 +0530, Anshuman Khandual wrote:
>> +static unsigned long __init get_random_vaddr(void)
>> +{
>> +unsigned long random_vaddr, random_pages, total_user_pages;
>> +
>> +total_user_pages = (TASK_SIZE - FIRST_USER_ADDRESS)
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/atmel-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/atmel-rng.c
b/drivers/char/hw_random/at
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/exynos-trng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/exynos-trng.c
b/drivers/char/hw_rando
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/bcm2835-rng.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/char/hw_random/bcm2835-rng.c
b/drivers/char/hw_rand
devm_platform_ioremap_resource() internally have platform_get_resource()
and devm_ioremap_resource() in it. So instead of calling them separately
use devm_platform_ioremap_resource() directly.
YueHaibing (13):
hwrng: atmel - use devm_platform_ioremap_resource() to simplify code
hwrng: bcm2835
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/ks-sa-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/ks-sa-rng.c
b/drivers/char/hw_random/ks
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/hisi-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/hisi-rng.c
b/drivers/char/hw_random/hisi
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/meson-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/meson-rng.c
b/drivers/char/hw_random/me
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/npcm-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/npcm-rng.c
b/drivers/char/hw_random/npcm
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/omap-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/omap-rng.c
b/drivers/char/hw_random/omap
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/pic32-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/pic32-rng.c
b/drivers/char/hw_random/pi
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/st-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/st-rng.c b/drivers/char/hw_random/st-rng.c
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/xgene-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/xgene-rng.c
b/drivers/char/hw_random/xg
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/tx4939-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/tx4939-rng.c
b/drivers/char/hw_random/
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/hw_random/pasemi-rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/pasemi-rng.c
b/drivers/char/hw_random/
On 2019/10/16 0:58, Greg KH wrote:
> On Tue, Oct 15, 2019 at 06:40:29PM +0800, Yunsheng Lin wrote:
>> On 2019/10/14 17:25, Greg KH wrote:
>>> On Mon, Oct 14, 2019 at 04:00:46PM +0800, Yunsheng Lin wrote:
On 2019/10/12 18:47, Greg KH wrote:
> On Sat, Oct 12, 2019 at 12:40:01PM +0200, Greg K
On 10/14/19 4:57 PM, Daniel Axtens wrote:
> Hi Andrey,
>
>
>>> + /*
>>> +* Ensure poisoning is visible before the shadow is made visible
>>> +* to other CPUs.
>>> +*/
>>> + smp_wmb();
>>
>> I'm not quite understand what this barrier do and why it needed.
>> And if it's really ne
Hi
On 10/16/19 12:46 PM, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Signed-off-by: YueHaibing
> ---
> drivers/char/hw_random/st-rng.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/driver
hi
I am a student, I represent a group of friends running a couple of
opensource projects(1), and we are lost with this(2) problem.
I wrote here(2) a couple of years ago, we are still working with kernel
4.11.0 and there is broken support for initializing the PCI.
The PCI initialization of the PP
hi
I am a student, I represent a group of friends running a couple of
opensource projects(1), and we are lost with this(2) problem.
I wrote here(2) a couple of years ago, we are still working with kernel
4.11.0 and there is broken support for initializing the PCI.
The PCI initialization of the PP
Hi Andrey,
On Wed, Oct 16, 2019 at 03:19:50PM +0300, Andrey Ryabinin wrote:
> On 10/14/19 4:57 PM, Daniel Axtens wrote:
> >>> + /*
> >>> + * Ensure poisoning is visible before the shadow is made visible
> >>> + * to other CPUs.
> >>> + */
> >>> + smp_wmb();
> >>
> >> I'm not quite understand wh
On 06.10.19 10:56, David Hildenbrand wrote:
Let's poison the pages similar to when adding new memory in
sparse_add_section(). Also call remove_pfn_range_from_zone() from
memunmap_pages(), so we can poison the memmap from there as well.
While at it, calculate the pfn in memunmap_pages() only once
Le 15/10/2019 à 21:41, Frederic Barrat a écrit :
Le 15/10/2019 à 07:42, Sam Bobroff a écrit :
On Fri, Sep 27, 2019 at 02:45:10PM +0200, Frederic Barrat wrote:
Recent cleanup in the way EEH support is added to a device causes a
kernel oops when the cxl driver probes a device and creates vir
On 10/16/19 1:14 AM, Bjorn Helgaas wrote:
On Mon, Sep 30, 2019 at 03:59:25PM +0300, Sergey Miroshnichenko wrote:
Hello Bjorn,
On 9/28/19 1:02 AM, Bjorn Helgaas wrote:
On Fri, Aug 16, 2019 at 07:50:41PM +0300, Sergey Miroshnichenko wrote:
When hot-adding a device, the bridge may have windows n
This series moves the definition and the management of scheduled process
area (SPA) and of the templates (Transaction Layer) for an ocxl card,
using the OCAPI interface. The code is now located in the specific arch
powerpc platform.
These patches will help for a futur implementation of the ocxl dri
Specifies the templates in the Transaction Layer that the OpenCAPI
device/host support when transmitting/receiving DL/DLX frames to or
from the OpenCAPI device/host.
Update, rename and create new few platform-specific calls which can
be used by drivers.
No functional change.
Signed-off-by: Christ
The Scheduled Process Area, located in system momory, contains a list of
Scheduled Processes (Structure of Process Element) to be serviced by the
AFUs. The process elements contain the address context and other state
information for the processes scheduled to run on the AFUs.
Update, rename and cre
Seems to work for me so far! I've tried successfully against 5.2.21 and
5.3.6.
Thanks!
-Cameron
On 10/15/19 10:51 PM, Aneesh Kumar K.V wrote:
With commit: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel
regions in the same 0xc range"), kernel now split the 64TB address range
into 4 conte
YueHaibing writes:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Signed-off-by: YueHaibing
Reviewed-by: Kevin Hilman
Recent cleanup in the way EEH support is added to a device causes a
kernel oops when the cxl driver probes a device and creates virtual
devices discovered on the FPGA:
BUG: Kernel NULL pointer dereference at 0x00a0
Faulting instruction address: 0xc0048070
Oops: Kernel acces
On 10/16/19 3:46 AM, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Signed-off-by: YueHaibing
Acked-by: Florian Fainelli
--
Florian
On 10/16/19 3:46 AM, YueHaibing wrote:
> devm_platform_ioremap_resource() internally have platform_get_resource()
> and devm_ioremap_resource() in it. So instead of calling them separately
> use devm_platform_ioremap_resource() directly.
Did your coccinelle script not cover
drivers/char/hw_random/
On Wed, Oct 16, 2019 at 06:50:30PM +0300, Sergey Miroshnichenko wrote:
> On 10/16/19 1:14 AM, Bjorn Helgaas wrote:
> > On Mon, Sep 30, 2019 at 03:59:25PM +0300, Sergey Miroshnichenko wrote:
> > > On 9/28/19 1:02 AM, Bjorn Helgaas wrote:
> > > > It's possible that a hot-add will trigger this attemp
dlpar_online_cpu() attempts to online all threads of a core that has
been added to an LPAR. If onlining a non-primary thread
fails (e.g. due to an allocation failure), the core is left with at
least one thread online. dlpar_cpu_add() attempts to roll back the
whole operation, releasing the core bac
This is a respin of https://patchwork.ozlabs.org/patch/1164930/.
Changes since v1:
* Address checkpatch warnings in dlpar_offline_cpu before moving it.
* Add Fixes: tags.
Nathan Lynch (2):
powerpc/pseries: address checkpatch warnings in dlpar_offline_cpu
powerpc/pseries: safely roll back fail
Remove some stray blank lines, convert a printk to pr_warn, and
address a line length violation.
One functional change: use WARN_ON instead of BUG_ON in case H_PROD of
a ceded thread yields an unexpected result from the platform. We can
expect this code path to get uninterruptibly stuck in __cpu_d
Nathan Lynch writes:
> Move dlpar_offline_cpu() before dlpar_online_cpu() so the latter can
> use the former to re-offline any threads it has onlined when it
> encounters an error.
Since moving this code yields a few valid checkpatch warnings, I've
submitted a v2 which cleans these up first.
htt
On Fri, 27 Sep 2019 13:53:32 +0200
Greg Kurz wrote:
> This brings some fixes and allows to start more VMs with an in-kernel
> XIVE or XICS-on-XIVE device.
>
> Changes since v1 (https://patchwork.ozlabs.org/cover/1166099/):
> - drop a useless patch
> - add a patch to show VP ids in debugfs
> - up
https://bugzilla.kernel.org/show_bug.cgi?id=205201
--- Comment #1 from Christian Zigotzky (chzigot...@xenosoft.de) ---
I have the same problem with my analog PCI TV card Typhoon TView RDS + FM
Stereo (BT878 chip) in my AmigaOne X5000. It only works with reducing the mem
size to 3500MB (mem=3500M).
Currently, vmalloc space is backed by the early shadow page. This
means that kasan is incompatible with VMAP_STACK.
This series provides a mechanism to back vmalloc space with real,
dynamically allocated memory. I have only wired up x86, because that's
the only currently supported arch I can work
Hook into vmalloc and vmap, and dynamically allocate real shadow
memory to back the mappings.
Most mappings in vmalloc space are small, requiring less than a full
page of shadow space. Allocating a full shadow page per mapping would
therefore be wasteful. Furthermore, to ensure that different mapp
Test kasan vmalloc support by adding a new test to the module.
Signed-off-by: Daniel Axtens
--
v5: split out per Christophe Leroy
---
lib/test_kasan.c | 26 ++
1 file changed, 26 insertions(+)
diff --git lib/test_kasan.c lib/test_kasan.c
index 49cc4d570a40..328d33beae3
Supporting VMAP_STACK with KASAN_VMALLOC is straightforward:
- clear the shadow region of vmapped stacks when swapping them in
- tweak Kconfig to allow VMAP_STACK to be turned on with KASAN
Reviewed-by: Dmitry Vyukov
Signed-off-by: Daniel Axtens
---
arch/Kconfig | 9 +
kernel/fork.c
In the case where KASAN directly allocates memory to back vmalloc
space, don't map the early shadow page over it.
We prepopulate pgds/p4ds for the range that would otherwise be empty.
This is required to get it synced to hardware on boot, allowing the
lower levels of the page tables to be filled d
Provide the current number of vmalloc shadow pages in
/sys/kernel/debug/kasan/vmalloc_shadow_pages.
Signed-off-by: Daniel Axtens
---
v8: rename kasan_vmalloc/shadow_pages -> kasan/vmalloc_shadow_pages
On v4 (no dynamic freeing), I saw the following approximate figures
on my test VM:
- fresh
On 2019/10/17 0:44, Florian Fainelli wrote:
> On 10/16/19 3:46 AM, YueHaibing wrote:
>> devm_platform_ioremap_resource() internally have platform_get_resource()
>> and devm_ioremap_resource() in it. So instead of calling them separately
>> use devm_platform_ioremap_resource() directly.
>
> Did
Hi,
We tried to replace the umount system call with our own code. Bellow is the
simplified test case.
When doing umount, there is kernel panic (on centos7
4.14.0-115.10.1.el7a.ppc64le kernel) on P9 OpenPOWER machine.
Could you please give suggestions on how to make the system call hook work
pro
On Wed, 2019-10-16 at 15:19 +0200, Carlo Pisani wrote:
> hi
> I am a student, I represent a group of friends running a couple of
> opensource projects(1), and we are lost with this(2) problem.
>
> I wrote here(2) a couple of years ago, we are still working with
> kernel
> 4.11.0 and there is broke
On Wed, 2019-10-16 at 20:30 +1100, Michael Ellerman wrote:
> I think the main reason is that in some configurations we can't use 64K
> pages for MMIO, so the 64K vmalloc mappings and 4K MMIO mappings need to
> be in different segments.
>
> It's possible that's no longer true on modern configs. But
On 2019/10/15 下午3:35, Christoph Hellwig wrote:
On Fri, Oct 11, 2019 at 06:25:19PM -0700, Ram Pai wrote:
From: Thiago Jung Bauermann
Normally, virtio enables DMA API with VIRTIO_F_IOMMU_PLATFORM, which must
be set by both device and guest driver. However, as a hack, when DMA API
returns physi
On Wed, Oct 16, 2019 at 06:28:33PM +0200, Frederic Barrat wrote:
> Recent cleanup in the way EEH support is added to a device causes a
> kernel oops when the cxl driver probes a device and creates virtual
> devices discovered on the FPGA:
>
> BUG: Kernel NULL pointer dereference at 0x00a0
On Thu, Oct 17, 2019 at 1:01 PM Yi Li wrote:
>
> Hi,
*snip*
> The kernel module can be insert correctly, and we mount a tmpfs, then umount.
> Kernel panic when doing umount:
> "
> [ 148.569777] umount /home/adam/test 0x0
> [ 148.608227] umount2 returned 0
> [ 148.608268] Unable to handle kern
Currently when an EEH error is detected, the system log receives the
same (or almost the same) message twice:
EEH: PHB#0 failure detected, location: N/A
EEH: PHB#0 failure detected, location: N/A
or
EEH: eeh_dev_check_failure: Frozen PHB#0-PE#0 detected
EEH: Frozen PHB#0-PE#0 detected
This looks
For P2P output, the output divider should align with the output sample
rate, if use ideal sample rate, there will be a lot of overload, which
would cause underrun.
The maximum divider of asrc clock is 1024, but there is no judgement
for this limitaion in driver, which may cause the divider setting
64 matches
Mail list logo
