Le 16/06/2021 à 08:33, Madhavan Srinivasan a écrit :
On 6/16/21 11:56 AM, Christophe Leroy wrote:
Le 16/06/2021 à 05:40, Athira Rajeev a écrit :
On 16-Jun-2021, at 8:53 AM, Madhavan Srinivasan wrote:
On 6/15/21 8:35 PM, Christophe Leroy wrote:
For your information, I'm getting the f
commit 367dc4aa932b ("cpufreq: Add stop CPU callback to cpufreq_driver
interface") added the stop_cpu() callback to allow the drivers to do
clean up before the CPU is completely down and its state can't be
modified.
At that time the CPU hotplug framework used to call the cpufreq core's
registered
Hi Rafael,
Sending these separately from CPPC stuff to avoid unnecessary confusion and
independent merging of these patches. These should get in nevertheless.
commit 367dc4aa932b ("cpufreq: Add stop CPU callback to cpufreq_driver
interface") added the stop_cpu() callback to allow the drivers to d
On 6/16/21 11:56 AM, Christophe Leroy wrote:
Le 16/06/2021 à 05:40, Athira Rajeev a écrit :
On 16-Jun-2021, at 8:53 AM, Madhavan Srinivasan
wrote:
On 6/15/21 8:35 PM, Christophe Leroy wrote:
For your information, I'm getting the following Oops. Detected with
5.13-rc6, it also oopses
v12: https://lore.kernel.org/patchwork/cover/1447254/
On Wed, Jun 16, 2021 at 11:52 AM Claire Chang wrote:
>
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or un
Le 16/06/2021 à 05:40, Athira Rajeev a écrit :
On 16-Jun-2021, at 8:53 AM, Madhavan Srinivasan wrote:
On 6/15/21 8:35 PM, Christophe Leroy wrote:
For your information, I'm getting the following Oops. Detected with 5.13-rc6,
it also oopses on 5.12 and 5.11.
Runs ok on 5.10. I'm starting
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 33 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 6 +
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 36
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpec
Add the functions, swiotlb_{alloc,free} and is_swiotlb_for_alloc to
support the memory allocation from restricted DMA pool.
The restricted DMA pool is preferred if available.
Note that since coherent allocation needs remapping, one must set up
another device coherent pool by shared-dma-pool and u
Add a new function, swiotlb_release_slots, to make the code reusable for
supporting different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
dif
Rename find_slots to swiotlb_find_slots and move the maintenance of
alloc_size to it for better code reusability later.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/kernel
Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
use it to determine whether to bounce the data or not. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
---
include/linux/swiotlb.h | 11 +++
kernel/dma/direct.c | 2 +-
kernel/d
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
drivers/pci/
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 7 ---
Always have the pointer to the swiotlb pool used in struct device. This
could help simplify the code for other pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/base/core.c| 4
include/linux/device.h | 4
kernel/dma/swiotlb.c | 8
3 files cha
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/swiotlb.c
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 49 ++--
1 file changed, 24 insertions(+), 25 deletions(
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for Wi
lyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a002-20210615
i386 randconfig-a006-20210615
i386 randconfig-a004-20210615
i386 randconfig-a001-202
On Wed, Jun 16, 2021 at 01:10:02PM +0800, Claire Chang wrote:
> On Wed, Jun 16, 2021 at 12:59 PM Christoph Hellwig wrote:
> >
> > On Wed, Jun 16, 2021 at 12:04:16PM +0800, Claire Chang wrote:
> > > Just noticed that after propagating swiotlb_force setting into
> > > io_tlb_default_mem->force, the
On Wed, Jun 16, 2021 at 12:59 PM Christoph Hellwig wrote:
>
> On Wed, Jun 16, 2021 at 12:04:16PM +0800, Claire Chang wrote:
> > Just noticed that after propagating swiotlb_force setting into
> > io_tlb_default_mem->force, the memory allocation behavior for
> > swiotlb_force will change (i.e. alway
On Wed, Jun 16, 2021 at 12:04:16PM +0800, Claire Chang wrote:
> Just noticed that after propagating swiotlb_force setting into
> io_tlb_default_mem->force, the memory allocation behavior for
> swiotlb_force will change (i.e. always skipping arch_dma_alloc and
> dma_direct_alloc_from_pool).
Yes, I
mremap HAVE_MOVE_PMD/PUD optimization time comparison for 1GB region:
1GB mremap - Source PTE-aligned, Destination PTE-aligned
mremap time: 2292772ns
1GB mremap - Source PMD-aligned, Destination PMD-aligned
mremap time: 1158928ns
1GB mremap - Source PUD-aligned, Destination PUD-aligne
flush_tlb_range is special in that we don't specify the page size used
for the translation. Hence when flushing TLB we flush the translation cache
for all possible page sizes. The kernel also uses the same interface when
moving page tables around. Such a move requires us to flush the page walk cach
Architectures like ppc64 support faster mremap only with radix
translation. Hence allow a runtime check w.r.t support for fast mremap.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/tlb.h | 6 ++
mm/mremap.c| 15 ++-
2 files changed, 20 insertio
This patchset enables MOVE_PMD/MOVE_PUD support on power. This requires
the platform to support updating higher-level page tables without
updating page table entries. This also needs to invalidate the Page Walk
Cache on architecture supporting the same.
This patchset is dependent on
https://lore.k
On 15-06-21, 08:17, Qian Cai wrote:
> On 6/15/2021 3:50 AM, Viresh Kumar wrote:
> > This is a strange place to get the issue from. And this is a new
> > issue.
>
> Well, it was still the same exercises with CPU online/offline.
>
> >
> >> [ 488.151939][ T670] kthread+0x3ac/0x460
> >> [ 488.15
To avoid a race between rmap walk and mremap, mremap does take_rmap_locks().
The lock was taken to ensure that rmap walk don't miss a page table entry due to
PTE moves via move_pagetables(). The kernel does further optimization of
this lock such that if we are going to find the newly added vma afte
pmd/pud_populate is the right interface to be used to set the respective
page table entries. Some architectures like ppc64 do assume that set_pmd/pud_at
can only be used to set a hugepage PTE. Since we are not setting up a hugepage
PTE here, use the pmd/pud_populate interface.
Signed-off-by: Anees
With two level page table don't enable move_normal_pud.
Signed-off-by: Aneesh Kumar K.V
---
mm/mremap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/mremap.c b/mm/mremap.c
index 958ecdc6f29d..97313e316a4d 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -276,7 +276,7 @@ st
With TRANSPARENT_HUGEPAGE_PUD enabled the kernel can find huge PUD entries.
Add a helper to move huge PUD entries on mremap().
This will be used by a later patch to optimize mremap of PUD_SIZE aligned
level 4 PTE mapped address
This also make sure we support mremap on huge PUD entries even with
C
With a large mmap map size, we can overlap with the text area and using
MAP_FIXED results in unmapping that area. Switch to MAP_FIXED_NOREPLACE
and handle the EEXIST error.
Reviewed-by: Kalesh Singh
Signed-off-by: Aneesh Kumar K.V
---
tools/testing/selftests/vm/mremap_test.c | 5 +++--
1 file c
Instead of hardcoding 4K page size fetch it using sysconf(). For the performance
measurements test still assume 2M and 1G are hugepage sizes.
Reviewed-by: Kalesh Singh
Signed-off-by: Aneesh Kumar K.V
---
tools/testing/selftests/vm/mremap_test.c | 113 ---
1 file changed, 61
This patch series is split out series from [PATCH v7 00/11] Speedup mremap on
ppc64
(https://lore.kernel.org/linux-mm/20210607055131.156184-1-aneesh.ku...@linux.ibm.com)
dropping ppc64 specific changes.
This patchset is dependent on
https://lore.kernel.org/linux-mm/20210615110859.320299-1-aneesh.
Excerpts from Andy Lutomirski's message of June 16, 2021 1:21 pm:
> The old sync_core_before_usermode() comments suggested that a
> non-icache-syncing
> return-to-usermode instruction is x86-specific and that all other
> architectures automatically notice cross-modified code on return to
> userspa
Hi Marco,
>> + /* Don't touch the shadow memory if arch isn't ready */
>> + if (!kasan_arch_is_ready())
>> + return;
>> +
>
> What about kasan_poison_last_granule()? kasan_unpoison() currently
> seems to potentially trip on that.
Ah the perils of rebasing an old series! I
Hi Marco,
@@ -12,6 +12,15 @@ config HAVE_ARCH_KASAN_HW_TAGS
>> config HAVE_ARCH_KASAN_VMALLOC
>> bool
>>
>> +# Sometimes an architecture might not be able to support inline
>> instrumentation
>> +# but might be able to support outline instrumentation. This option allows
>> an
>> +# arch
Excerpts from Andy Lutomirski's message of June 16, 2021 1:21 pm:
> powerpc did the following on some, but not all, paths through
> switch_mm_irqs_off():
>
>/*
> * Only need the full barrier when switching between processes.
> * Barrier when switching from kernel to userspa
On Wed, Jun 16, 2021 at 11:54 AM Claire Chang wrote:
>
> Add the functions, swiotlb_{alloc,free} to support the memory allocation
> from restricted DMA pool.
>
> The restricted DMA pool is preferred if available.
>
> Note that since coherent allocation needs remapping, one must set up
> another de
v11 https://lore.kernel.org/patchwork/cover/1447216/
On Tue, Jun 15, 2021 at 9:27 PM Claire Chang wrote:
>
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or unex
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 33 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 6 +
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 36
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpec
Add the functions, swiotlb_{alloc,free} to support the memory allocation
from restricted DMA pool.
The restricted DMA pool is preferred if available.
Note that since coherent allocation needs remapping, one must set up
another device coherent pool by shared-dma-pool and use
dma_alloc_from_dev_coh
Add a new function, swiotlb_release_slots, to make the code reusable for
supporting different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
dif
Rename find_slots to swiotlb_find_slots and move the maintenance of
alloc_size to it for better code reusability later.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/kernel
Propagate the swiotlb_force setting into io_tlb_default_mem->force and
use it to determine whether to bounce the data or not. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
include/linux/swiotlb.h | 11 +++
kernel/d
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
drivers/pci/
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 7 ---
Always have the pointer to the swiotlb pool used in struct device. This
could help simplify the code for other pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/base/core.c| 4
include/linux/device.h | 4
kernel/dma/swiotlb.c | 8
3 files cha
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/swiotlb.c
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 49 ++--
1 file changed, 24 insertions(+), 25 deletions(
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for Wi
> On 16-Jun-2021, at 8:53 AM, Madhavan Srinivasan wrote:
>
>
> On 6/15/21 8:35 PM, Christophe Leroy wrote:
>> For your information, I'm getting the following Oops. Detected with
>> 5.13-rc6, it also oopses on 5.12 and 5.11.
>> Runs ok on 5.10. I'm starting bisecting now.
>
>
> Thanks for r
allnoconfig
x86_64 randconfig-a001-20210615
x86_64 randconfig-a004-20210615
x86_64 randconfig-a002-20210615
x86_64 randconfig-a003-20210615
x86_64 randconfig-a006-20210615
x86_64 randconfig-a005-20210615
i386
-powerpc-lib-restart_table.c:warning:no-previous-prototype-for-search_kernel_restart_table
`-- x86_64-allnoconfig
`--
arch-powerpc-kernel-interrupt_64.S:asm-head-.h-is-included-more-than-once.
clang_recent_errors
`-- powerpc-randconfig-r012-20210615
|--
arch-powerpc-kernel
allnoconfig
x86_64 randconfig-a001-20210615
x86_64 randconfig-a004-20210615
x86_64 randconfig-a002-20210615
x86_64 randconfig-a003-20210615
x86_64 randconfig-a006-20210615
x86_64 randconfig-a005-20210615
On 6/15/21 8:35 PM, Christophe Leroy wrote:
For your information, I'm getting the following Oops. Detected with
5.13-rc6, it also oopses on 5.12 and 5.11.
Runs ok on 5.10. I'm starting bisecting now.
Thanks for reporting, got the issue. What has happened in this case is
that, pmu device is
powerpc did the following on some, but not all, paths through
switch_mm_irqs_off():
/*
* Only need the full barrier when switching between processes.
* Barrier when switching from kernel to userspace is not
* required here, given that it is implied by mmdrop(). Barri
The old sync_core_before_usermode() comments suggested that a non-icache-syncing
return-to-usermode instruction is x86-specific and that all other
architectures automatically notice cross-modified code on return to
userspace.
This is misleading. The incantation needed to modify code from one
CPU
Roman Bolshakov writes:
> On Mon, Jun 14, 2021 at 11:14:40PM +1000, Michael Ellerman wrote:
>> Commit b0b3b2c78ec0 ("powerpc: Switch to relative jump labels") switched
>> us to using relative jump labels. That involves changing the code,
>> target and key members in struct jump_entry to be relativ
Segher Boessenkool writes:
> On Tue, Jun 15, 2021 at 03:41:00PM +0200, Jessica Yu wrote:
>> +++ Segher Boessenkool [15/06/21 07:50 -0500]:
>> >On Tue, Jun 15, 2021 at 02:17:40PM +0200, Jessica Yu wrote:
>> >>+int __weak elf_check_module_arch(Elf_Ehdr *hdr)
>> >>+{
>> >>+ return 1;
>> >>+}
>>
Jessica Yu writes:
> +++ Nicholas Piggin [15/06/21 12:05 +1000]:
>>Excerpts from Jessica Yu's message of June 14, 2021 10:06 pm:
>>> +++ Nicholas Piggin [11/06/21 19:39 +1000]:
The elf_check_arch() function is used to test usermode binaries, but
kernel modules may have more specific requir
Rob Herring writes:
> On Tue, Jun 15, 2021 at 10:13 AM nramas wrote:
>>
>> On Tue, 2021-06-15 at 08:01 -0600, Rob Herring wrote:
>> > On Tue, Jun 15, 2021 at 6:18 AM Geert Uytterhoeven <
>> > ge...@linux-m68k.org> wrote:
>> > >
>> > > > +void *of_kexec_alloc_and_setup_fdt(const struct kimage *ima
Excerpts from Linus Torvalds's message of June 9, 2021 3:10 am:
> On Mon, Jun 7, 2021 at 3:10 AM Nick Piggin wrote:
>>
>> I'd really rather not do this, I'm not sure if micro benchmark captures
>> everything.
>
> I don't much care what powerpc code does _itnernally_ for this
> architecture-speci
Excerpts from Michael Ellerman's message of June 16, 2021 12:07 am:
> Nicholas Piggin writes:
>> This series attempts to improve the speed of interrupts and system calls
>> in three major ways.
>
> With the full series applied I'm seeing various warnings.
Gah, sorry :( I've tested hash/radix gue
Excerpts from Michael Ellerman's message of June 15, 2021 11:44 pm:
> Nicholas Piggin writes:
>> diff --git a/arch/powerpc/lib/feature-fixups.c
>> b/arch/powerpc/lib/feature-fixups.c
>> index fe26f2fa0f3f..fbe94e2d5011 100644
>> --- a/arch/powerpc/lib/feature-fixups.c
>> +++ b/arch/powerpc/lib/fe
Excerpts from Jessica Yu's message of June 15, 2021 10:17 pm:
> +++ Nicholas Piggin [15/06/21 12:05 +1000]:
>>Excerpts from Jessica Yu's message of June 14, 2021 10:06 pm:
>>> +++ Nicholas Piggin [11/06/21 19:39 +1000]:
The elf_check_arch() function is used to test usermode binaries, but
ke
Jordan Niethe writes:
> Load Multiple Word (lmw) and Store Multiple Word (stmw) will raise an
> Alignment Exception:
> - Little Endian mode: always
> - Big Endian mode: address not word aligned
>
> These conditions do not depend on cache inhibited memory. Test the
> alignment handler emulation
Excerpts from Andy Lutomirski's message of June 16, 2021 10:14 am:
> On 6/14/21 5:55 PM, Nicholas Piggin wrote:
>> Excerpts from Andy Lutomirski's message of June 15, 2021 2:20 am:
>>> Replying to several emails at once...
>>>
>
>>
>> So the only documentation relating to the current active_mm va
On 6/14/21 5:55 PM, Nicholas Piggin wrote:
> Excerpts from Andy Lutomirski's message of June 15, 2021 2:20 am:
>> Replying to several emails at once...
>>
>
> So the only documentation relating to the current active_mm value or
> refcounting is that it may not match what the x86 specific code is
Fabiano Rosas writes:
> Pratik Sampat writes:
...
>>>
The new H_CALL exports information in direct string value format, hence
a new interface has been introduced in /sys/firmware/papr to export
>>> Hm.. Maybe this should be something less generic than "papr"?
>>
>> The interface naming
The patch titled
Subject: mm: rename p4d_page_vaddr to p4d_pgtable and make it return pud_t
*
has been added to the -mm tree. Its filename is
mm-rename-p4d_page_vaddr-to-p4d_pgtable-and-make-it-return-pud_t.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/br
The patch titled
Subject: mm: rename pud_page_vaddr to pud_pgtable and make it return pmd_t
*
has been added to the -mm tree. Its filename is
mm-rename-pud_page_vaddr-to-pud_pgtable-and-make-it-return-pmd_t.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/br
On Tue, Jun 15, 2021 at 09:27:02PM +0800, Claire Chang wrote:
> Always have the pointer to the swiotlb pool used in struct device. This
> could help simplify the code for other pools.
Applying: swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used
error: patch failed: kernel/dma/swiotlb.c:339
> On 14 Jun 2021, at 16:14, Michael Ellerman wrote:
>
> Commit b0b3b2c78ec0 ("powerpc: Switch to relative jump labels") switched
> us to using relative jump labels. That involves changing the code,
> target and key members in struct jump_entry to be relative to the
> address of the jump_entry,
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
head: 103bf32b0d2dd8b8a4d3d9ebdded5ba4e8263e6a
commit: 88a293b28ae07acc86b09ebbe8715bcee412a63e [119/124] powerpc/64: use
interrupt restart table to speed up return from interrupt
config: powerpc-allyesconfig (a
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
head: 103bf32b0d2dd8b8a4d3d9ebdded5ba4e8263e6a
commit: 9d1e5f27172b011ed4d07c92c304fa60caef03ff [116/124] powerpc/64: allow
alternate return locations for soft-masked interrupts
config: powerpc-allyesconfig (att
On Tue, Jun 15, 2021 at 10:13 AM nramas wrote:
>
> On Tue, 2021-06-15 at 08:01 -0600, Rob Herring wrote:
> > On Tue, Jun 15, 2021 at 6:18 AM Geert Uytterhoeven <
> > ge...@linux-m68k.org> wrote:
> > >
> > > > +void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
> > > > +
Hi Christoph,
On 15.06.2021 17:58, Christoph Hellwig wrote:
> On Tue, Jun 15, 2021 at 05:47:44PM +0200, Marek Szyprowski wrote:
>> On 02.06.2021 08:53, Christoph Hellwig wrote:
>>> Use the blk_mq_alloc_disk API to simplify the gendisk and request_queue
>>> allocation.
>>>
>>> Signed-off-by: Christ
On Tue, 2021-06-15 at 08:01 -0600, Rob Herring wrote:
> On Tue, Jun 15, 2021 at 6:18 AM Geert Uytterhoeven <
> ge...@linux-m68k.org> wrote:
> >
> > > +void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
> > > + unsigned long
> > > initrd_load_addr,
> > >
On Tue, Jun 15, 2021 at 05:47:44PM +0200, Marek Szyprowski wrote:
> Hi,
>
> On 02.06.2021 08:53, Christoph Hellwig wrote:
> > Use the blk_mq_alloc_disk API to simplify the gendisk and request_queue
> > allocation.
> >
> > Signed-off-by: Christoph Hellwig
>
> This patch landed in linux-next as co
Hi,
On 02.06.2021 08:53, Christoph Hellwig wrote:
> Use the blk_mq_alloc_disk API to simplify the gendisk and request_queue
> allocation.
>
> Signed-off-by: Christoph Hellwig
This patch landed in linux-next as commit 6966bb921def ("mtd_blkdevs:
use blk_mq_alloc_disk"). It causes the following r
From: Nicolas Cavallari
[ Upstream commit a8437f05384cb472518ec21bf4fffbe8f0a47378 ]
Otherwise, when compiled as module, a WARN_ON is triggered:
WARNING: CPU: 0 PID: 5 at sound/core/init.c:208 snd_card_new+0x310/0x39c [snd]
[...]
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.39 #1
Hardware n
From: Nicolas Cavallari
[ Upstream commit a8437f05384cb472518ec21bf4fffbe8f0a47378 ]
Otherwise, when compiled as module, a WARN_ON is triggered:
WARNING: CPU: 0 PID: 5 at sound/core/init.c:208 snd_card_new+0x310/0x39c [snd]
[...]
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.39 #1
Hardware n
On Wed, Sep 27, 2017 at 04:52:31PM +1000, Alexey Kardashevskiy wrote:
> In order to make generic IOV code work, the physical function IOV BAR
> should start from offset of the first VF. Since M64 segments share
> PE number space across PHB, and some PEs may be in use at the time
> when IOV is enabl
For your information, I'm getting the following Oops. Detected with 5.13-rc6, it also oopses on 5.12
and 5.11.
Runs ok on 5.10. I'm starting bisecting now.
root@vgoippro:/tmp# perf record /root/null_syscall
[ 285.559987] BUG: Kernel NULL pointer dereference on read at 0x0040
[ 285.566533]
On Tue, Jun 15, 2021 at 03:41:00PM +0200, Jessica Yu wrote:
> +++ Segher Boessenkool [15/06/21 07:50 -0500]:
> >On Tue, Jun 15, 2021 at 02:17:40PM +0200, Jessica Yu wrote:
> >>+int __weak elf_check_module_arch(Elf_Ehdr *hdr)
> >>+{
> >>+ return 1;
> >>+}
> >
> >But is this a good idea? It is
[+Cc Andrey]
On Tue, 15 Jun 2021 at 03:47, Daniel Axtens wrote:
>
> Building on the work of Christophe, Aneesh and Balbir, I've ported
> KASAN to 64-bit Book3S kernels running on the Radix MMU.
>
> I've been trying this for a while, but we keep having collisions
> between the kasan code in the mm
On Tue, 15 Jun 2021 at 03:47, Daniel Axtens wrote:
>
> Allow architectures to define a kasan_arch_is_ready() hook that bails
> out of any function that's about to touch the shadow unless the arch
> says that it is ready for the memory to be accessed. This is fairly
> uninvasive and should have a n
Nicholas Piggin writes:
> This series attempts to improve the speed of interrupts and system calls
> in three major ways.
With the full series applied I'm seeing various warnings.
I feel like I must be missing some lead up patch?
cheers
mambo, p8, hash, be:
[0.001038][T0] ---
On Tue, Jun 15, 2021 at 6:18 AM Geert Uytterhoeven wrote:
>
> Hi Lakshmi and Rob,
>
> On Sun, Feb 21, 2021 at 6:52 PM Lakshmi Ramasubramanian
> wrote:
> > From: Rob Herring
> >
> > Both arm64 and powerpc do essentially the same FDT /chosen setup for
> > kexec. The differences are either omissio
Nicholas Piggin writes:
> diff --git a/arch/powerpc/lib/feature-fixups.c
> b/arch/powerpc/lib/feature-fixups.c
> index fe26f2fa0f3f..fbe94e2d5011 100644
> --- a/arch/powerpc/lib/feature-fixups.c
> +++ b/arch/powerpc/lib/feature-fixups.c
> @@ -412,12 +430,19 @@ void do_entry_flush_fixups(enum l1d_
On Tue, Jun 15, 2021 at 09:27:09PM +0800, Claire Chang wrote:
> Add the functions, swiotlb_{alloc,free} to support the memory allocation
> from restricted DMA pool.
>
> The restricted DMA pool is preferred if available.
>
> Note that since coherent allocation needs remapping, one must set up
> an
+++ Segher Boessenkool [15/06/21 07:50 -0500]:
On Tue, Jun 15, 2021 at 02:17:40PM +0200, Jessica Yu wrote:
+int __weak elf_check_module_arch(Elf_Ehdr *hdr)
+{
+ return 1;
+}
But is this a good idea? It isn't useful to be able to attempt to load
a module not compiled for your architectur
On Mon, Jun 14, 2021 at 11:14:40PM +1000, Michael Ellerman wrote:
> Commit b0b3b2c78ec0 ("powerpc: Switch to relative jump labels") switched
> us to using relative jump labels. That involves changing the code,
> target and key members in struct jump_entry to be relative to the
> address of the jump
On Tue, Jun 15, 2021 at 09:27:08PM +0800, Claire Chang wrote:
> Add the initialization function to create restricted DMA pools from
> matching reserved-memory nodes.
>
> Regardless of swiotlb setting, the restricted DMA pool is preferred if
> available.
>
> The restricted DMA pools provide a basi
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Jun 15, 2021 at 09:27:06PM +0800, Claire Chang wrote:
> Rename find_slots to swiotlb_find_slots and move the maintenance of
> alloc_size to it for better code reusability later.
>
> Signed-off-by: Claire Chang
Looks good,
Reviewed-by: Christoph Hellwig
1 - 100 of 180 matches
Mail list logo
