On Thu, Aug 22, 2024 at 09:13:11AM +0200, Christophe Leroy wrote:
> _vdso_data is specific to x86 and __arch_get_k_vdso_data() is provided
> so that all architectures can provide the requested pointer.
>
> Do the same with _vdso_rng_data, provide __arch_get_k_vdso_rng_data()
> and don't use x86 _v
On Thu, Aug 22, 2024 at 09:13:21AM +0200, Christophe Leroy wrote:
> Architectures use different location for vDSO sources:
> arch/mips/vdso
> arch/sparc/vdso
> arch/arm64/kernel/vdso
> arch/riscv/kernel/vdso
> arch/csky/kernel/vdso
> arch/x86/um/vdso
> arch
Hi Christophe,
Thanks for this series. There are quite a few preliminary patches in it,
before you get to the PPC part, which fix up general build system or test
harness correctness issues. Since some of those affect all architectures
that are adding vDSO getrandom() support for 6.12, I'm going to
On Thu, Aug 22, 2024 at 09:13:09AM +0200, Christophe Leroy wrote:
> include/asm-generic/unaligned.h | 11 +--
> include/vdso/unaligned.h| 15 +++
> 2 files changed, 16 insertions(+), 10 deletions(-)
> create mode 100644 include/vdso/unaligned.h
Do you need to also adj
On Thu, Aug 22, 2024 at 09:13:22AM +0200, Christophe Leroy wrote:
> Don't hard-code x86 specific names, use vdso_config definitions
> to find the correct function matching the architecture.
>
> Add random VDSO function names in names[][]. Remove the #ifdef
> CONFIG_VDSO32, having the name there al
On Sat, Aug 24, 2024 at 11:58 AM Christoph Hellwig wrote:
>
> Hi all,
>
> we've had a long standing problems where drivers try to hook into the
> DMA_OPS mechanisms to override them for something that is not DMA, or
> to introduce additional dispatching.
>
> Now that we are not using DMA_OPS suppo
Le 26/08/2024 à 09:20, Jason A. Donenfeld a écrit :
On Thu, Aug 22, 2024 at 09:13:09AM +0200, Christophe Leroy wrote:
include/asm-generic/unaligned.h | 11 +--
include/vdso/unaligned.h| 15 +++
2 files changed, 16 insertions(+), 10 deletions(-)
create mode 10
On Mon, Aug 26, 2024 at 2:16 PM Jason Wang wrote:
>
> On Sat, Aug 24, 2024 at 11:58 AM Christoph Hellwig wrote:
> >
> > Hi all,
> >
> > we've had a long standing problems where drivers try to hook into the
> > DMA_OPS mechanisms to override them for something that is not DMA, or
> > to introduce
On Mon, Aug 26, 2024 at 2:30 PM Christoph Hellwig wrote:
>
> On Mon, Aug 26, 2024 at 02:27:27PM +0800, Jason Wang wrote:
> > Actually I meant, we can extend the virtio_config_ops to allow mapping
> > ops there, then simulator and VDUSE can hook the map ops there.
>
> From a quick glance that feels
On Thu, Aug 22, 2024 at 09:13:23AM +0200, Christophe Leroy wrote:
> Replace -isystem by -idirafter
>
> But this implies that now tools/include/linux/linkage.h is
> included instead of include/linux/linkage.h, so define a stub
> for SYM_FUNC_START() and SYM_FUNC_END().
Thanks! I got step 1, but di
From: "Mike Rapoport (Microsoft)"
Using large pages to map text areas reduces iTLB pressure and improves
performance.
Extend execmem_alloc() with an ability to use PMD_SIZE'ed pages with ROX
permissions as a cache for smaller allocations.
To populate the cache, a writable large page is allocate
From: "Mike Rapoport (Microsoft)"
Enable execmem's cache of PMD_SIZE'ed pages mapped as ROX for module
text allocations.
Signed-off-by: Mike Rapoport (Microsoft)
---
arch/x86/mm/init.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/in
From: "Mike Rapoport (Microsoft)"
In order to support ROX allocations for module text, it is necessary to
handle modifications to the code, such as relocations and alternatives
patching, without write access to that memory.
One option is to use text patching, but this would make module loading
e
From: "Mike Rapoport (Microsoft)"
Hi,
These patches add support for using large ROX pages for allocations of
executable memory on x86.
They address Andy's comments [1] about having executable mappings for code
that was not completely formed.
The approach taken is to allocate ROX memory along w
From: "Mike Rapoport (Microsoft)"
vmalloc allocations with VM_ALLOW_HUGE_VMAP that do not explicitly
specify node ID will use huge pages only if size_per_node is larger than
a huge page.
Still the actual allocated memory is not distributed between nodes and
there is no advantage in such approach.
From: "Mike Rapoport (Microsoft)"
There are a couple of declarations that depend on CONFIG_MMU in
include/linux/vmalloc.h spread all over the file.
Group them all together to improve code readability.
No functional changes.
Signed-off-by: Mike Rapoport (Microsoft)
---
include/linux/vmalloc.h
From: Song Liu
ftrace_process_locs sorts module mcount, which is inside RO memory. Add a
ftrace_swap_func so that archs can use RO-memory-poke function to do the
sorting.
Signed-off-by: Song Liu
Signed-off-by: Mike Rapoport (Microsoft)
---
include/linux/ftrace.h | 2 ++
kernel/trace/ftrace.c
From: "Mike Rapoport (Microsoft)"
Several architectures support text patching, but they name the header
files that declare patching functions differently.
Make all such headers consistently named text-patching.h and add an empty
header in asm-generic for architectures that do not support text pa
Le 26/08/2024 à 09:28, Jason A. Donenfeld a écrit :
> On Thu, Aug 22, 2024 at 09:13:22AM +0200, Christophe Leroy wrote:
>> Don't hard-code x86 specific names, use vdso_config definitions
>> to find the correct function matching the architecture.
>>
>> Add random VDSO function names in names[][].
From: "Mike Rapoport (Microsoft)"
When module text memory will be allocated with ROX permissions, the
memory at the actual address where the module will live will contain
invalid instructions and there will be a writable copy that contains the
actual module code.
Update relocations and alternati
On Thu, Aug 22, 2024 at 09:13:24AM +0200, Christophe Leroy wrote:
> On powerpc, a call to a VDSO function is not a standard C function
> call. Unlike x86 that returns a negated error code in case of an
> error, powerpc sets CR[SO] and returns the error code as a
> positive value.
>
> So use a macr
On Thu, Aug 22, 2024 at 09:13:12AM +0200, Christophe Leroy wrote:
> Same as for gettimeofday CVDSO implementation, add c-getrandom-y
> to ease the inclusion of lib/vdso/getrandom.c in architectures
> VDSO builds.
Thanks, seems straight forward. I'll apply this now as a fix.
On Wed, Aug 21, 2024 at 10:21 AM Michael Ellerman wrote:
> register_pmu_pm_ops() is only called at init time, via
> device_initcall(), so can be marked __init. The driver can't be built as
> a module.
>
> Signed-off-by: Michael Ellerman
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Le 26/08/2024 à 09:37, Jason A. Donenfeld a écrit :
> On Thu, Aug 22, 2024 at 09:13:24AM +0200, Christophe Leroy wrote:
>> On powerpc, a call to a VDSO function is not a standard C function
>> call. Unlike x86 that returns a negated error code in case of an
>> error, powerpc sets CR[SO] and retur
On Thu, Aug 22, 2024 at 09:13:14AM +0200, Christophe Leroy wrote:
> Performing SMP atomic operations on u64 fails on powerpc32.
>
> Random driver generation is handled as unsigned long not u64,
> see for instance base_cnrg or struct crng.
>
> Use the same type for vDSO's getrandom as it gets copi
Le 26/08/2024 à 09:50, Jason A. Donenfeld a écrit :
On Thu, Aug 22, 2024 at 09:13:14AM +0200, Christophe Leroy wrote:
Performing SMP atomic operations on u64 fails on powerpc32.
Random driver generation is handled as unsigned long not u64,
see for instance base_cnrg or struct crng.
Use the
On Thu, Aug 22, 2024 at 09:13:13AM +0200, Christophe Leroy wrote:
> With the current implementation, __cvdso_getrandom_data() calls
> memset(), which is unexpected in the VDSO.
>
> Rewrite opaque data initialisation to avoid memset().
I think of the various ways I've seen of fixing this -- e.g. a
If an interrupt occurs in queued_spin_lock_slowpath() after we increment
qnodesp->count and before node->lock is initialized, another CPU might
see stale lock values in get_tail_qnode(). If the stale lock value happens
to match the lock on that CPU, then we write to the "next" pointer of
the wrong
On Thu, Aug 22, 2024 at 09:13:10AM +0200, Christophe Leroy wrote:
> diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
> index 0c92db84469d..6e4f8fae3ce9 100644
> --- a/arch/x86/include/asm/pvclock.h
> +++ b/arch/x86/include/asm/pvclock.h
> @@ -5,6 +5,7 @@
> #include
>
On Mon, Aug 26, 2024 at 09:19:22AM +0200, Jason A. Donenfeld wrote:
> Hi Christophe,
>
> Thanks for this series. There are quite a few preliminary patches in it,
> before you get to the PPC part, which fix up general build system or test
> harness correctness issues. Since some of those affect all
On Mon, Aug 26, 2024 at 10:01:17AM +0200, Christophe Leroy wrote:
>
>
> Le 26/08/2024 à 09:50, Jason A. Donenfeld a écrit :
> > On Thu, Aug 22, 2024 at 09:13:14AM +0200, Christophe Leroy wrote:
> >> Performing SMP atomic operations on u64 fails on powerpc32.
> >>
> >> Random driver generation is
Le 26/08/2024 à 10:07, Jason A. Donenfeld a écrit :
On Thu, Aug 22, 2024 at 09:13:10AM +0200, Christophe Leroy wrote:
+#define _PAGE_SIZE (1UL << CONFIG_PAGE_SHIFT)
+#define _PAGE_MASK (~(_PAGE_SIZE - 1))
If PAGE_SIZE isn't defined at this point, why not just call it PAGE_SIZE
instead of
On Mon, Aug 26, 2024 at 10:37:49AM +0200, Christophe Leroy wrote:
>
>
> Le 26/08/2024 à 10:07, Jason A. Donenfeld a écrit :
> > On Thu, Aug 22, 2024 at 09:13:10AM +0200, Christophe Leroy wrote:
> >>
> >> +#define _PAGE_SIZE (1UL << CONFIG_PAGE_SHIFT)
> >> +#define _PAGE_MASK (~(_PAGE_SIZE - 1)
On Mon, Aug 26 2024 at 10:01, Christophe Leroy wrote:
> Le 26/08/2024 à 09:50, Jason A. Donenfeld a écrit :
>> But tglx pointed out in that thread that this actually isn't necessary:
>>
>> | All of this is pointless because if a 32-bit application runs on a
>> | 64-bit kernel it has to use the 64-
r-for-vDSO/20240826-103525
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
patch link:
https://lore.kernel.org/r/315e3a268b165b6edad7dcb723b0d8a506a56c4e.1724309198.git.christophe.leroy%40csgroup.eu
patch subject: [PATCH v2 07/17] mm: Define VM_DROPPABLE for powerpc
Hi Andy,
On 24-08-23, Andy Shevchenko wrote:
> On Mon, Jul 01, 2024 at 03:53:39PM +0200, Marco Felsch wrote:
> > This series adds the intial support to handle EEPROMs via the MTD layer
> > as well. This allow the user-space to have separate paritions since
> > EEPROMs can become quite large nowada
On Mon, Aug 26, 2024 at 11:43:39AM +0200, Thomas Gleixner wrote:
> As explained before, there is no problem with store or load tearing on
> 32bit systems because the generation counter is only 32bit wide. So the
> obvious solution is to only update 32 bits on a 32bit kernel:
>
> --- a/drivers/char
act-common-header-for-vDSO/20240826-103525
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
patch link:
https://lore.kernel.org/r/315e3a268b165b6edad7dcb723b0d8a506a56c4e.1724309198.git.christophe.leroy%40csgroup.eu
patch subject: [PATCH v2 07/17] mm: Define VM_DRO
Le 26/08/2024 à 11:43, Thomas Gleixner a écrit :
> On Mon, Aug 26 2024 at 10:01, Christophe Leroy wrote:
>> Le 26/08/2024 à 09:50, Jason A. Donenfeld a écrit :
>>> But tglx pointed out in that thread that this actually isn't necessary:
>>>
>>> | All of this is pointless because if a 32-bit applic
On Mon, Aug 26, 2024 at 09:51:10AM +0200, Marco Felsch wrote:
> On 24-08-23, Andy Shevchenko wrote:
> > On Mon, Jul 01, 2024 at 03:53:39PM +0200, Marco Felsch wrote:
> > > This series adds the intial support to handle EEPROMs via the MTD layer
> > > as well. This allow the user-space to have separa
Le 26/08/2024 à 10:58, Jason A. Donenfeld a écrit :
On Mon, Aug 26, 2024 at 10:37:49AM +0200, Christophe Leroy wrote:
Le 26/08/2024 à 10:07, Jason A. Donenfeld a écrit :
On Thu, Aug 22, 2024 at 09:13:10AM +0200, Christophe Leroy wrote:
+#define _PAGE_SIZE (1UL << CONFIG_PAGE_SHIFT)
+#
Hi Michael,
Thanks for the patch, the patch looks fine to me.
Tested-by: Kajol Jain
Reviewed-by: Kajol Jain
Thanks,
Kajol Jain
On 8/19/24 17:54, Michael Ellerman wrote:
> The dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because
> the code calls kmalloc() while holding it, whic
On Mon, Aug 26 2024 at 12:45, Christophe Leroy wrote:
> Le 26/08/2024 à 10:58, Jason A. Donenfeld a écrit :
>> On Mon, Aug 26, 2024 at 10:37:49AM +0200, Christophe Leroy wrote:
>>>
>>>
>>> Le 26/08/2024 à 10:07, Jason A. Donenfeld a écrit :
On Thu, Aug 22, 2024 at 09:13:10AM +0200, Christophe
On Mon, Aug 26, 2024 at 12:45:40PM +0200, Christophe Leroy wrote:
>
>
> Le 26/08/2024 à 10:58, Jason A. Donenfeld a écrit :
> > On Mon, Aug 26, 2024 at 10:37:49AM +0200, Christophe Leroy wrote:
> >>
> >>
> >> Le 26/08/2024 à 10:07, Jason A. Donenfeld a écrit :
> >>> On Thu, Aug 22, 2024 at 09:13:
On Fri, Aug 23, 2024 at 06:19:52AM +, LEROY Christophe wrote:
> Why is an option needed for that ? If pmd_leaf() returns always false,
> it means the arch doesn't support pmd mappings and if properly used all
> related code should fold away without a config option, shouldn't it ?
It's not al
On 22.08.24 09:13, Qi Zheng wrote:
Currently, the usage of pte_offset_map_nolock() can be divided into the
following two cases:
1) After acquiring PTL, only read-only operations are performed on the PTE
page. In this case, the RCU lock in pte_offset_map_nolock() will ensure
that the PTE
On 22.08.24 09:13, Qi Zheng wrote:
In do_adjust_pte(), we may modify the pte entry. At this time, the write
lock of mmap_lock is not held, and the pte_same() check is not performed
after the PTL held. The corresponding pmd entry may have been modified
concurrently. Therefore, in order to ensure t
On 22.08.24 09:13, Qi Zheng wrote:
In assert_pte_locked(), we just get the ptl and assert if it was already
held, so convert it to using pte_offset_map_ro_nolock().
Signed-off-by: Qi Zheng
---
arch/powerpc/mm/pgtable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/
On 22.08.24 09:13, Qi Zheng wrote:
In filemap_fault_recheck_pte_none(), we just do pte_none() check, so
convert it to using pte_offset_map_ro_nolock().
Signed-off-by: Qi Zheng
---
mm/filemap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
On 22.08.24 09:13, Qi Zheng wrote:
In __collapse_huge_page_swapin(), we just use the ptl for pte_same() check
in do_swap_page(). In other places, we directly use pte_offset_map_lock(),
so convert it to using pte_offset_map_ro_nolock().
Signed-off-by: Qi Zheng
---
mm/khugepaged.c | 6 +-
On 22.08.24 09:13, Qi Zheng wrote:
In handle_pte_fault(), we may modify the vmf->pte after acquiring the
vmf->ptl, so convert it to using pte_offset_map_rw_nolock(). But since we
will do the pte_same() check, so there is no need to get pmdval to do
pmd_same() check, just pass a dummy variable to
Le 26/08/2024 à 17:48, Pankaj Raghav (Samsung) a écrit :
On Mon, Aug 26, 2024 at 05:59:31PM +1000, Stephen Rothwell wrote:
Hi all,
After merging the vfs-brauner tree, today's linux-next boot test (powerpc
pseries_le_defconfig) produced this warning:
iomap dio calls set_memory_ro() on the p
Hi Christophe,
kernel test robot noticed the following build warnings:
[auto build test WARNING on powerpc/next]
[also build test WARNING on powerpc/fixes shuah-kselftest/next
shuah-kselftest/fixes linus/master v6.11-rc5 next-20240826]
[cannot apply to crng-random/master]
[If your patch is
'struct kobj_type' is not modified. It is only used in kobject_init()
which takes a 'const struct kobj_type *ktype' parameter.
Constifying this structure moves some data to a read-only section,
so increase over all security.
On a x86_64, compiled with ppc64 defconfig:
Before:
==
textda
'struct kobj_type' is not modified. It is only used in kobject_init()
which takes a 'const struct kobj_type *ktype' parameter.
Constifying this structure moves some data to a read-only section,
so increase over all security.
On a x86_64, compiled with ppc64 defconfig:
Before:
==
textda
'struct kobj_type' is not modified. It is only used in
kobject_init_and_add()/kobject_init() which takes
a 'const struct kobj_type *ktype' parameter.
Constifying this structure moves some data to a read-only section,
so increase over all security.
On a x86_64, compiled with ppc64 defconfig:
Befor
On Mon, Aug 26, 2024 at 05:59:31PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the vfs-brauner tree, today's linux-next boot test (powerpc
> pseries_le_defconfig) produced this warning:
iomap dio calls set_memory_ro() on the page that is used for sub block
zeroing.
But looking at
On Mon, 26 Aug 2024 09:55:29 +0300
Mike Rapoport wrote:
> From: Song Liu
>
> ftrace_process_locs sorts module mcount, which is inside RO memory. Add a
> ftrace_swap_func so that archs can use RO-memory-poke function to do the
> sorting.
Can you add the above as a comment above the ftrace_swap_
On 7 Aug 2024, at 2:41, Mike Rapoport wrote:
From: "Mike Rapoport (Microsoft)" mailto:r...@kernel.org>>
Until now arch_numa was directly translating firmware NUMA information
to memblock.
Using numa_memblks as an intermediate step has a few advantages:
* alignment with more battle tested x86 imp
Dear All,
On 11.08.2024 09:09, Baruch Siach wrote:
> From: Catalin Marinas
>
> Hardware DMA limit might not be power of 2. When RAM range starts above
> 0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
> can not encode this limit.
>
> Use plain address for DMA zone limit.
>
>
On Mon, Aug 26, 2024 at 07:43:20PM +0200, Christophe Leroy wrote:
>
>
> Le 26/08/2024 à 17:48, Pankaj Raghav (Samsung) a écrit :
> > On Mon, Aug 26, 2024 at 05:59:31PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the vfs-brauner tree, today's linux-next boot test (power
On Mon, Aug 26, 2024 at 01:52:54PM -0700, Luis Chamberlain wrote:
> On Mon, Aug 26, 2024 at 07:43:20PM +0200, Christophe Leroy wrote:
> >
> >
> > Le 26/08/2024 à 17:48, Pankaj Raghav (Samsung) a écrit :
> > > On Mon, Aug 26, 2024 at 05:59:31PM +1000, Stephen Rothwell wrote:
> > > > Hi all,
> > >
On Mon, Aug 26, 2024 at 02:10:49PM -0700, Darrick J. Wong wrote:
> On Mon, Aug 26, 2024 at 01:52:54PM -0700, Luis Chamberlain wrote:
> > On Mon, Aug 26, 2024 at 07:43:20PM +0200, Christophe Leroy wrote:
> > >
> > >
> > > Le 26/08/2024 à 17:48, Pankaj Raghav (Samsung) a écrit :
> > > > On Mon, Aug
On 7 Aug 2024, at 2:41, Mike Rapoport wrote:
From: "Mike Rapoport (Microsoft)"
Until now arch_numa was directly translating firmware NUMA information
to memblock.
Using numa_memblks as an intermediate step has a few advantages:
* alignment with more battle tested x86 implementation
* availabili
Hi David,
On 2024/8/26 23:21, David Hildenbrand wrote:
On 22.08.24 09:13, Qi Zheng wrote:
Currently, the usage of pte_offset_map_nolock() can be divided into the
following two cases:
1) After acquiring PTL, only read-only operations are performed on the
PTE
page. In this case, the RCU loc
On 2024/8/26 23:36, David Hildenbrand wrote:
On 22.08.24 09:13, Qi Zheng wrote:
In handle_pte_fault(), we may modify the vmf->pte after acquiring the
vmf->ptl, so convert it to using pte_offset_map_rw_nolock(). But since we
will do the pte_same() check, so there is no need to get pmdval to do
Hi Narayana,
Thanks for the patch.
Narayana Murty N writes:
> VFIO_EEH_PE_INJECT_ERR ioctl is currently failing on pseries
> due to missing implementation of err_inject eeh_ops for pseries.
> This patch implements pseries_eeh_err_inject in eeh_ops/pseries
> eeh_ops. Implements support for injec
Hi Marek,
Thanks for your report.
On Mon, Aug 26 2024, Marek Szyprowski wrote:
> On 11.08.2024 09:09, Baruch Siach wrote:
>> From: Catalin Marinas
>>
>> Hardware DMA limit might not be power of 2. When RAM range starts above
>> 0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bi
Update JSON/events for power10 platform with additional events.
Signed-off-by: Kajol Jain
---
.../arch/powerpc/power10/datasource.json | 25 +++
.../arch/powerpc/power10/frontend.json| 10
.../pmu-events/arch/powerpc/power10/pmc.json | 5
3 files chan
Move some of the JSON/events from others.json to
more appropriate json files for power10 platform.
Signed-off-by: Kajol Jain
---
.../arch/powerpc/power10/cache.json | 15 ++
.../arch/powerpc/power10/datasource.json | 15 ++
.../arch/powerpc/power10/frontend.json| 10 ++
Move PM_BR_MPRED_CMPL event from cache.json to frontend.json file
for power10 platform
Signed-off-by: Kajol Jain
---
tools/perf/pmu-events/arch/powerpc/power10/cache.json| 5 -
tools/perf/pmu-events/arch/powerpc/power10/frontend.json | 5 +
2 files changed, 5 insertions(+), 5 deletio
Luis Chamberlain writes:
> On Mon, Aug 26, 2024 at 02:10:49PM -0700, Darrick J. Wong wrote:
>> On Mon, Aug 26, 2024 at 01:52:54PM -0700, Luis Chamberlain wrote:
>> > On Mon, Aug 26, 2024 at 07:43:20PM +0200, Christophe Leroy wrote:
>> > >
>> > >
>> > > Le 26/08/2024 à 17:48, Pankaj Raghav (Sams
Sergei Shtylyov writes:
> On 8/20/24 6:04 AM, Michael Ellerman wrote:
>
>> The overflow/underflow conditions in pata_macio_qc_prep() should never
>> happen. But if they do there's no need to kill the system entirely, a
>> WARN and failing the IO request should be sufficient and might allow the
>>
On 27.08.2024 06:52, Baruch Siach wrote:
> Hi Marek,
>
> Thanks for your report.
>
> On Mon, Aug 26 2024, Marek Szyprowski wrote:
>> On 11.08.2024 09:09, Baruch Siach wrote:
>>> From: Catalin Marinas
>>>
>>> Hardware DMA limit might not be power of 2. When RAM range starts above
>>> 0, say 4GB, DM
On 08/23/24 at 08:16pm, John Paul Adrian Glaubitz wrote:
> Hi Geert,
>
> On Fri, 2024-08-23 at 15:13 +0200, Geert Uytterhoeven wrote:
> > IMHO CRASH_DUMP should just default to n, like most kernel options, as
> > it enables non-trivial extra functionality: the kernel source tree has
> > more than
"Pankaj Raghav (Samsung)" writes:
> On Mon, Aug 26, 2024 at 05:59:31PM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the vfs-brauner tree, today's linux-next boot test (powerpc
>> pseries_le_defconfig) produced this warning:
>
> iomap dio calls set_memory_ro() on the page that is
Maddy will be helping out with upstream maintenance, add him as a
reviewer.
Signed-off-by: Michael Ellerman
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 878dcd23b331..0ee724dcc05a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12912,6 +12912
On Tue, 2024-08-27 at 14:22 +0800, Baoquan He wrote:
> About why it's enabled by default, as Michael has explained in another
> thread, distros usualy needs to enable it by default because vmcore
> dumping is a very important feature on servers, even guest instances.
> Even though kdump codes are
78 matches
Mail list logo
