On Mon, Sep 29, 2025 at 01:11:31PM -0600, Khalid Aziz wrote:
> Text for GPL v2 has been updated to remove old mailing address. This
> updates the license text in COPYING file with the current license text
> from https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt
>
> Signed-off-by: Khalid Aziz
On Tue, Sep 23, 2025 at 02:17:04PM -0700, Andrew Morton wrote:
> On Tue, 23 Sep 2025 13:52:09 +0200 Sumanth Korikkar
> wrote:
>
> > > --- a/fs/hugetlbfs/inode.c
> > > +++ b/fs/hugetlbfs/inode.c
> > > @@ -96,8 +96,15 @@ static const struct fs_parameter_spec
> > > hugetlb_fs_parameters[] = {
> > >
Hi Kazu,
Thanks for your review of the patch [1 & 2].
As for the left [3 - 10] patches, I will redraft and post v2 later.
Thanks,
Tao Liu
On Mon, Sep 29, 2025 at 7:30 PM HAGIO KAZUHITO(萩尾 一仁)
wrote:
>
> Hi Tao,
>
> On 2025/06/10 18:57, Tao Liu wrote:
> > There is a bug of not supporting random
On Tue, Sep 23, 2025 at 05:42:54PM +0100, Simon Horman wrote:
> Add loongarch64 to build matrix.
>
> A gcc-14 package is installed as there is no generic gcc package
> for loongarch in Ubuntu 24.04. Hopefully this will be resolved in
> Ubuntu 26.04.
>
> Signed-off-by: Simon Horman
Applied.
- w
On Sat, Sep 27, 2025 at 01:43:23PM -0700, Cong Wang wrote:
> On Fri, Sep 26, 2025 at 2:50 AM Jarkko Sakkinen wrote:
> >
> > On Wed, Sep 24, 2025 at 11:39:44AM -0700, Cong Wang wrote:
> > > On Wed, Sep 24, 2025 at 10:51 AM Christoph Lameter (Ampere)
> > > wrote:
> > > > AFAICT various contemporary
On Sun, Sep 28, 2025 at 05:22:43PM +0300, Jarkko Sakkinen wrote:
> On Sat, Sep 27, 2025 at 01:43:23PM -0700, Cong Wang wrote:
> > On Fri, Sep 26, 2025 at 2:50 AM Jarkko Sakkinen wrote:
> > >
> > > On Wed, Sep 24, 2025 at 11:39:44AM -0700, Cong Wang wrote:
> > > > On Wed, Sep 24, 2025 at 10:51 AM C
On Mon, Sep 22, 2025 at 03:41:18PM -0700, Cong Wang wrote:
> On Mon, Sep 22, 2025 at 7:28 AM Stefan Hajnoczi wrote:
> >
> > On Sat, Sep 20, 2025 at 02:40:18PM -0700, Cong Wang wrote:
> > > On Fri, Sep 19, 2025 at 2:27 PM Stefan Hajnoczi
> > > wrote:
> > > >
> > > > On Thu, Sep 18, 2025 at 03:25:
On Fri, Sep 26, 2025 at 2:50 AM Jarkko Sakkinen wrote:
>
> On Wed, Sep 24, 2025 at 11:39:44AM -0700, Cong Wang wrote:
> > On Wed, Sep 24, 2025 at 10:51 AM Christoph Lameter (Ampere)
> > wrote:
> > > AFAICT various contemporary Android deployments do the multiple kernel
> > > approach in one way o
On Sat, Sep 27, 2025 at 4:27 PM Cong Wang wrote:
>
> On Fri, Sep 26, 2025 at 2:01 AM Jarkko Sakkinen wrote:
> >
> > On Thu, Sep 18, 2025 at 03:25:59PM -0700, Cong Wang wrote:
> > > This patch series introduces multikernel architecture support, enabling
> > > multiple independent kernel instances
On Fri, Sep 26, 2025 at 2:01 AM Jarkko Sakkinen wrote:
>
> On Thu, Sep 18, 2025 at 03:25:59PM -0700, Cong Wang wrote:
> > This patch series introduces multikernel architecture support, enabling
> > multiple independent kernel instances to coexist and communicate on a
> > single physical machine. E
Hi Jiaxun,
On Thu, Sep 25, 2025 at 8:48 AM Jiaxun Yang wrote:
>
>
>
> > 2025年9月19日 06:25，Cong Wang 写道：
> >
> > This patch series introduces multikernel architecture support, enabling
> > multiple independent kernel instances to coexist and communicate on a
> > single physical machine. Each kerne
's, which is even stronger for
kernel-to-kernel sharing, this possibly avoids re-inventing
another protocol.
3) It provides eBPF.
4) The spawned kernel does not require any hardware knowledge,
just pure XDP-ringbuffer-based software logic.
But it also has limitations:
1) xdp_md is too specif
Hi,
First, thanks for fixing this!
So, I've been trying to find a failure beyond the printouts being wrong
for the past couple days, and largely failed to duplicate a functional
issue.
That said, this does fix a couple printouts I checked on 32-bit 686
debian 12. Generally I think the code
On Wed, Sep 24, 2025 at 11:39:44AM -0700, Cong Wang wrote:
> On Wed, Sep 24, 2025 at 10:51 AM Christoph Lameter (Ampere)
> wrote:
> > AFAICT various contemporary Android deployments do the multiple kernel
> > approach in one way or another already for security purposes and for
> > specialized cont
On Thu, Sep 18, 2025 at 03:25:59PM -0700, Cong Wang wrote:
> This patch series introduces multikernel architecture support, enabling
> multiple independent kernel instances to coexist and communicate on a
> single physical machine. Each kernel instance can run on dedicated CPU
> cores while sharing
Hi, Dave
On 9/25/25 17:11, Dave Young wrote:
Hi Youling,
On Thu, 25 Sept 2025 at 14:33, Youling Tang wrote:
From: Youling Tang
During kdump operations, the capture kernel cannot reuse the "mem="
parameter from the production kernel. The "mem=" parameter is used
to specify the available memo
On 9/19/25 11:01, Sohil Mehta wrote:
From: Dylan Yudaken
Add a .gitignore for the test case build object.
Signed-off-by: Dylan Yudaken
Signed-off-by: Sohil Mehta
Reviewed-by: Simon Horman
---
The binary creates some noise. The patch to fix that seems to have
fallen through the cracks. Sendi
> 2025年9月19日 06:25，Cong Wang 写道：
>
> This patch series introduces multikernel architecture support, enabling
> multiple independent kernel instances to coexist and communicate on a
> single physical machine. Each kernel instance can run on dedicated CPU
> cores while sharing the underlying har
On Thu, Sep 25, 2025 at 02:27:06PM +0200, Pratyush Yadav wrote:
> I think the tables should be treated as the final serialized data
> structure, and should get all the same properties that other KHO
> serialization formats have like stable binary format, versioning, etc.
Right, that's how I see it
On Thu, Sep 25 2025, Mike Rapoport wrote:
> Hi Jason,
>
> On Tue, Sep 16, 2025 at 07:50:15PM -0700, Jason Miu wrote:
>> This series transitions KHO from an xarray-based metadata tracking
>> system with serialization to using page table like data structures
>> that can be passed directly to the nex
On Thu, 25 Sept 2025 at 14:33, Youling Tang wrote:
>
> From: Youling Tang
>
> Refactor the cmdline_add_xxx code flow, and simultaneously display
> the content of parameters such as initrd in hexadecimal format to
> improve readability.
>
> Signed-off-by: Youling Tang
> ---
> kexec/arch/loongarc
Hi Youling,
On Thu, 25 Sept 2025 at 14:33, Youling Tang wrote:
>
> From: Youling Tang
>
> During kdump operations, the capture kernel cannot reuse the "mem="
> parameter from the production kernel. The "mem=" parameter is used
> to specify the available memory range for the kernel. Reusing the
>
On 09/25/25 at 12:07am, Sabyrzhan Tasbolatov wrote:
> On Wed, Sep 24, 2025 at 5:35 AM Baoquan He wrote:
> >
> > On 09/23/25 at 07:49pm, Andrey Konovalov wrote:
> > > Since the Sabyrzhan's patches are already in mm-stable (and I assume
> > > will be merged during the next merge window), just rebase
On Wed, Sep 24, 2025 at 5:35 AM Baoquan He wrote:
>
> On 09/23/25 at 07:49pm, Andrey Konovalov wrote:
> > Since the Sabyrzhan's patches are already in mm-stable (and I assume
> > will be merged during the next merge window), just rebase your changes
> > on top.
>
> That's fine, I will rebase.
>
>
On Wed, Sep 24, 2025 at 10:51 AM Christoph Lameter (Ampere)
wrote:
> AFAICT various contemporary Android deployments do the multiple kernel
> approach in one way or another already for security purposes and for
> specialized controllers. However, the multi kernel approaches are often
> depending o
On Wed, Sep 24, 2025 at 11:28:04AM -0700, Cong Wang wrote:
> On Wed, Sep 24, 2025 at 5:51 AM Stefan Hajnoczi wrote:
> >
> > On Wed, Sep 24, 2025 at 01:38:31PM +0200, David Hildenbrand wrote:
> > > > >
> > > > > Two more points:
> > > > >
> > > > > 1) Security lockdown. Security lockdown transforms
You dont really need any kernel support to run multiple kernels on an SMP
system. Multiple kernels can operate without a hypervisor or anything
complicated like that.
The firmware can prep the kernel boot so that the kernels operate
on distinct address spaces, processors and I/O resources. Whereup
On Tue, Sep 23, 2025 at 10:05 AM Stefan Hajnoczi wrote:
>
> On Mon, Sep 22, 2025 at 03:41:18PM -0700, Cong Wang wrote:
> > On Mon, Sep 22, 2025 at 7:28 AM Stefan Hajnoczi wrote:
> > >
> > > On Sat, Sep 20, 2025 at 02:40:18PM -0700, Cong Wang wrote:
> > > > On Fri, Sep 19, 2025 at 2:27 PM Stefan H
On Wed, Sep 24, 2025 at 01:38:31PM +0200, David Hildenbrand wrote:
> > >
> > > Two more points:
> > >
> > > 1) Security lockdown. Security lockdown transforms multikernel from
> > > "0-day means total compromise" to "0-day means single workload
> > > compromise with rapid recovery." This is still
On Mon, Sep 15, 2025 at 11:05 AM Baoquan He wrote:
>
> > If you feel strongly that the ~1/8th RAM overhead (coming from the
> > physmap shadow and the slab redzones) is still unacceptable for your
> > use case (noting that the performance overhead (and the constant
> > silent detection of false-po
On Thu, Sep 04, 2025 at 08:22:52PM -0700, Khem Raj wrote:
> ET_EXEC uses image base of 0x40, but the build forces
> section VMAs like .text = 0x1. LLD now errors when any
> section address is below the image base unless you explicitly
> set the base. (Older LLD tolerated it.)
>
> To fix th
On Mon, Sep 22, 2025 at 10:58:21AM +0800, Chenghao Duan wrote:
> On Mon, Sep 22, 2025 at 10:10:57AM +0800, Chenghao Duan wrote:
> > The default COMMAND_LINE_SIZE inherited from asm-generic is 512, which
> > is too small for modern use cases. For example, when the parameter path
> > in the cmdline o
在 2025/9/22 16:08, Andrew Morton 写道:
On Mon, 22 Sep 2025 15:31:42 -0700 "yanjun.zhu" wrote:
+int kho_preserve_vmalloc(void *ptr, struct kho_vmalloc *preservation)
+{
+ struct kho_vmalloc_chunk *chunk;
+ struct vm_struct *vm = find_vm_area(ptr);
+ unsigned int order, flags,
On Mon, 22 Sep 2025 10:19:48 -0300 Jason Gunthorpe wrote:
> > +static void kho_vmalloc_free_chunks(struct kho_vmalloc *kho_vmalloc)
> > +{
> > + struct kho_vmalloc_chunk *chunk = KHOSER_LOAD_PTR(kho_vmalloc->first);
> > +
> > + while (chunk) {
> > + struct kho_vmalloc_chunk *tmp = c
On Fri, 12 Sep 2025 14:11:04 +0800 Baoquan He wrote:
> > int sanity_check_segment_list(struct kimage *image)
> > {
> > // ...
> > for (i = 0; i < nr_segments; i++) {
> > unsigned long mstart, mend;
> >
> > mstart = image->segment[i].mem;
> > mend = mstart + imag
On 09/22/25 at 10:31pm, Askar Safin wrote:
> Simon Horman, so what? This patchset is still not merged.
Not sure if Simon minds the patch log, especially in patch 1. I saw the
'TL;DR' first time in a patch log.
For a problem solving patch, we better provide information like
-what is the problem;
On 9/20/25 10:44 PM, Mike Rapoport wrote:
From: "Mike Rapoport (Microsoft)"
A vmalloc allocation is preserved using binary structure similar to
global KHO memory tracker. It's a linked list of pages where each page
is an array of physical address of pages in vmalloc area.
kho_preserve_vmalloc(
On 9/22/25 12:38 PM, Pingfan Liu wrote:
Hi Chen,
On Fri, Sep 19, 2025 at 3:35 PM Chen Wandun wrote:
I encountered the following error while makedumpfile without enableing
kernel CONFIG_PROC_KCORE and CONFIG_KALLSYMS_ALL, this error only exists
before commit 29fe506 (kexec: make -a the defau
On Mon, 22 Sep 2025 15:31:42 -0700 "yanjun.zhu" wrote:
> > +int kho_preserve_vmalloc(void *ptr, struct kho_vmalloc *preservation)
> > +{
> > + struct kho_vmalloc_chunk *chunk;
> > + struct vm_struct *vm = find_vm_area(ptr);
> > + unsigned int order, flags, nr_contig_pages;
> > + unsigned
On Mon, Sep 22, 2025 at 7:28 AM Stefan Hajnoczi wrote:
>
> On Sat, Sep 20, 2025 at 02:40:18PM -0700, Cong Wang wrote:
> > On Fri, Sep 19, 2025 at 2:27 PM Stefan Hajnoczi wrote:
> > >
> > > On Thu, Sep 18, 2025 at 03:25:59PM -0700, Cong Wang wrote:
> > > > This patch series introduces multikernel
Simon Horman, so what? This patchset is still not merged.
On Wed, 20 Aug 2025 01:30:08 +0400 Askar Safin
wrote ---
> TL;DR: this patchset fixes regression, introduced in aecc554e7b.
> This patchset should be backported to all distributions, which packaged
> v2.0.31, otherwise
> kex
On Sat, Sep 20, 2025 at 02:40:18PM -0700, Cong Wang wrote:
> On Fri, Sep 19, 2025 at 2:27 PM Stefan Hajnoczi wrote:
> >
> > On Thu, Sep 18, 2025 at 03:25:59PM -0700, Cong Wang wrote:
> > > This patch series introduces multikernel architecture support, enabling
> > > multiple independent kernel ins
On Sun, Sep 21, 2025 at 08:44:57AM +0300, Mike Rapoport wrote:
> +/* KHO internal flags for vmalloc preservations */
> +#define KHO_VMALLOC_ALLOC0x0001
> +#define KHO_VMALLOC_HUGE_VMAP0x0002
Maybe something for a followup, but we should really move all these
"ABI" structs and constants
On Sun, Sep 21, 2025 at 1:45 AM Mike Rapoport wrote:
>
> From: "Mike Rapoport (Microsoft)"
>
> A vmalloc allocation is preserved using binary structure similar to
> global KHO memory tracker. It's a linked list of pages where each page
> is an array of physical address of pages in vmalloc area.
>
On Sun, Sep 21 2025, Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> to make it clear that KHO operates on pages rather than on a random
> physical address.
>
> The kho_preserve_pages() will be also used in upcoming support for
> vmalloc preservation.
>
> Signed-off-by: Mike Rapoport
On Sun, Sep 21, 2025 at 08:44:56AM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> to make it clear that KHO operates on pages rather than on a random
> physical address.
>
> The kho_preserve_pages() will be also used in upcoming support for
> vmalloc preservation.
>
> Signe
On Mon, Sep 22, 2025 at 10:10:57AM +0800, Chenghao Duan wrote:
> The default COMMAND_LINE_SIZE inherited from asm-generic is 512, which
> is too small for modern use cases. For example, when the parameter path
> in the cmdline of the kdump first kernel is too long, the limit is
> easily exceeded wh
Hi Chen,
On Fri, Sep 19, 2025 at 3:35 PM Chen Wandun wrote:
>
> I encountered the following error while makedumpfile without enableing
> kernel CONFIG_PROC_KCORE and CONFIG_KALLSYMS_ALL, this error only exists
> before commit 29fe506 (kexec: make -a the default), this commit change
> from kexec_l
On Mon, Sep 22, 2025 at 10:10:57AM +0800, Chenghao Duan wrote:
> The default COMMAND_LINE_SIZE inherited from asm-generic is 512, which
> is too small for modern use cases. For example, when the parameter path
> in the cmdline of the kdump first kernel is too long, the limit is
> easily exceeded wh
On Sun, Sep 21, 2025 at 6:26 PM Matthew Wilcox wrote:
>
> On Wed, Sep 17, 2025 at 08:36:09AM -0300, Jason Gunthorpe wrote:
> > On Tue, Sep 16, 2025 at 07:50:15PM -0700, Jason Miu wrote:
> > > This series transitions KHO from an xarray-based metadata tracking
> > > system with serialization to usin
On Wed, Sep 17, 2025 at 08:36:09AM -0300, Jason Gunthorpe wrote:
> On Tue, Sep 16, 2025 at 07:50:15PM -0700, Jason Miu wrote:
> > This series transitions KHO from an xarray-based metadata tracking
> > system with serialization to using page table like data structures
> > that can be passed directly
Applied with some modifications. You may need to test whether everything is OK.
https://github.com/chenhuacai/linux/commits/loongarch-next
Huacai
On Wed, Sep 3, 2025 at 11:02 AM Youling Tang wrote:
>
> From: Youling Tang
>
> This patchset implement kexec_file_load() support on LoongArch.
>
> Th
On Sun, Sep 21, 2025 at 07:54:31AM +0200, Jan Engelhardt wrote:
>
> On Friday 2025-09-19 00:25, Cong Wang wrote:
>
> >This patch series introduces multikernel architecture support, enabling
> >multiple independent kernel instances to coexist and communicate on a
> >single physical machine.
> >
>
On Friday 2025-09-19 00:25, Cong Wang wrote:
>This patch series introduces multikernel architecture support, enabling
>multiple independent kernel instances to coexist and communicate on a
>single physical machine.
>
>Each kernel instance can run on dedicated CPU
>cores while sharing the underly
On Wed, 10 Sep 2025 21:21:55 +0100 Lorenzo Stoakes
wrote:
> Since commit c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file
> callback"), The f_op->mmap hook has been deprecated in favour of
> f_op->mmap_prepare.
>
> This was introduced in order to make it possible for us to eventually
> eli
On Tue, Sep 16, 2025 at 06:32:53PM -0700, Andrew Morton wrote:
> On Tue, 16 Sep 2025 17:23:31 +0100 Lorenzo Stoakes
> wrote:
>
> > Andrew - Jason has sent a conflicting patch against this file so it's not
> > reasonable to include it in this series any more, please drop it.
>
> No probs.
>
> All
On Mon, Sep 15, 2025 at 03:14:36PM -0700, Nathan Chancellor wrote:
> Hi Andy,
>
> On Mon, Sep 15, 2025 at 05:55:43PM +0200, Andy Shevchenko wrote:
> > clang is not happy about set but unused variable:
> >
> > kernel/kexec_core.c:745:16: error: variable 'maddr' set but not used
> > [-Werror,-Wunu
On Wed, Sep 10, 2025 at 09:22:03PM +0100, Lorenzo Stoakes wrote:
> +static inline void mmap_action_remap(struct mmap_action *action,
> + unsigned long addr, unsigned long pfn, unsigned long size,
> + pgprot_t pgprot)
> +{
> + action->type = MMAP_REMAP_PFN;
> +
> + ac
On Mon, Sep 08, 2025 at 04:59:46PM +0200, David Hildenbrand wrote:
> On 08.09.25 13:10, Lorenzo Stoakes wrote:
> > This simply assigns the vm_ops so is easily updated - do so.
> >
> > Signed-off-by: Lorenzo Stoakes
> > ---
>
> Reviewed-by: David Hildenbrand
Cheers!
>
> --
> Cheers
>
> David /
Hi Mike,
On Mon, Sep 15 2025, Mike Rapoport wrote:
> On Mon, Sep 08, 2025 at 08:12:59PM +0200, Pratyush Yadav wrote:
>> On Mon, Sep 08 2025, Mike Rapoport wrote:
>>
>> > From: "Mike Rapoport (Microsoft)"
>> >
>> > A vmalloc allocation is preserved using binary structure similar to
>> > global K
On Mon, Sep 08, 2025 at 02:27:12PM +0100, Lorenzo Stoakes wrote:
> It's not only remap that is a concern here, people do all kinds of weird
> and wonderful things in .mmap(), sometimes in combination with remap.
So it should really not be split this way, complete is a badly name
prepopulate and i
Hi YAMAZAKI,
On Mon, Sep 8, 2025 at 11:11 PM YAMAZAKI MASAMITSU(山崎 真光)
wrote:
>
> Hi,Liu
>
> Thanks your patch. What kind of environment did you test
> this KASLR problem ? Especialy is it kernel verssion
> 6.11.8-300.fc41.x86_64 ? Have you checked other versions?
> Additionally, do you know the
On Wed, Sep 17 2025, Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> KHO test stores physical addresses of the preserved folios directly in
> fdt.
> Use kho_preserve_vmalloc() instead of it and kho_restore_vmalloc() to
> retrieve the addresses after kexec.
>
> This makes the test mor
On Tue, Sep 16, 2025 at 03:11:56PM +0100, Lorenzo Stoakes wrote:
> Since we can now perform actions after the VMA is established via
> mmap_prepare, use desc->action_success_hook to set up the hugetlb lock
> once the VMA is setup.
>
> We also make changes throughout hugetlbfs to make this possible
On Tue, Sep 09, 2025 at 10:14:41PM +0200, Andrey Ryabinin wrote:
> +static int kstate_preserve_phys(struct kstate_stream *stream, void *obj,
> + const struct kstate_field *field)
> +{
> + struct reserve_mem_table *map = obj;
> +
> + return kho_preserve_phys(map->
On 08.09.25 16:47, Lorenzo Stoakes wrote:
On Mon, Sep 08, 2025 at 11:20:11AM -0300, Jason Gunthorpe wrote:
On Mon, Sep 08, 2025 at 03:09:43PM +0100, Lorenzo Stoakes wrote:
Perhaps
!vma_desc_cowable()
Is what many drivers are really trying to assert.
Well no, because:
static inline bool is_
On Fri, Sep 19, 2025 at 2:27 PM Stefan Hajnoczi wrote:
>
> On Thu, Sep 18, 2025 at 03:25:59PM -0700, Cong Wang wrote:
> > This patch series introduces multikernel architecture support, enabling
> > multiple independent kernel instances to coexist and communicate on a
> > single physical machine. E
On Fri, Sep 19, 2025 at 6:14 AM Pasha Tatashin
wrote:
>
> On Thu, Sep 18, 2025 at 6:26 PM Cong Wang wrote:
> >
> > This patch series introduces multikernel architecture support, enabling
> > multiple independent kernel instances to coexist and communicate on a
> > single physical machine. Each ke
On Wed, Sep 17, 2025 at 7:36 AM Jason Gunthorpe wrote:
>
> On Tue, Sep 16, 2025 at 07:50:15PM -0700, Jason Miu wrote:
> > This series transitions KHO from an xarray-based metadata tracking
> > system with serialization to using page table like data structures
> > that can be passed directly to the
On 08.09.25 13:10, Lorenzo Stoakes wrote:
The devdax driver does nothing special in its f_op->mmap hook, so
straightforwardly update it to use the mmap_prepare hook instead.
Signed-off-by: Lorenzo Stoakes
---
drivers/dax/device.c | 32 +---
1 file changed, 21 inse
On Mon, Sep 08, 2025 at 10:27:23AM -0300, Jason Gunthorpe wrote:
> On Mon, Sep 08, 2025 at 12:10:44PM +0100, Lorenzo Stoakes wrote:
> > We thread the state through the mmap_context, allowing for both PFN map and
> > mixed mapped pre-population.
> >
> > Signed-off-by: Lorenzo Stoakes
> > ---
> > f
On Tue, Sep 16, 2025 at 02:19:30PM -0300, Jason Gunthorpe wrote:
> On Tue, Sep 16, 2025 at 03:11:53PM +0100, Lorenzo Stoakes wrote:
> >
> > -int io_remap_pfn_range(struct vm_area_struct *vma, unsigned long vaddr,
> > - unsigned long pfn, unsigned long size, pgprot_t prot)
> > +static unsi
On Tue, Sep 16, 2025 at 03:11:57PM +0100, Lorenzo Stoakes wrote:
> Update the mem char driver (backing /dev/mem and /dev/zero) to use
> f_op->mmap_prepare hook rather than the deprecated f_op->mmap.
>
> The /dev/zero implementation has a very unique and rather concerning
> characteristic in that i
Hi YAMAZAKI,
Thanks a lot for your comments!
On Sat, Sep 6, 2025 at 12:41 AM YAMAZAKI MASAMITSU(山崎 真光)
wrote:
>
> Hi Liu
>
> I'm sorry it took so long.
No worries. :)
>
> Your proposed issue with regard to GPU memory is useful, but it may not
> be a frequently used feature. I think it would be
On Mon, Sep 08, 2025 at 03:09:43PM +0100, Lorenzo Stoakes wrote:
> > Perhaps
> >
> > !vma_desc_cowable()
> >
> > Is what many drivers are really trying to assert.
>
> Well no, because:
>
> static inline bool is_cow_mapping(vm_flags_t flags)
> {
> return (flags & (VM_SHARED | VM_MAYWRITE)) =
Hi Andrew,
Could you apply the below fixpatch?
Thanks, Lorenzo
8<
>From 35b96b949b44397c744b18f10b40a9989d4a92d2 Mon Sep 17 00:00:00 2001
From: Lorenzo Stoakes
Date: Mon, 15 Sep 2025 11:01:06 +0100
Subject: [PATCH] mm: fix incorrect mixedmap implementation
This was typo'd due to starin
On Mon, Sep 08, 2025 at 02:37:44PM +0100, Lorenzo Stoakes wrote:
> On Mon, Sep 08, 2025 at 10:11:21AM -0300, Jason Gunthorpe wrote:
> > On Mon, Sep 08, 2025 at 12:10:41PM +0100, Lorenzo Stoakes wrote:
> > > @@ -151,20 +123,55 @@ static int hugetlbfs_file_mmap(struct file *file,
> > > struct vm_are
Hi Coiby,
kernel test robot noticed the following build errors:
[auto build test ERROR on b320789d6883cc00ac78ce83bccbfe7ed58afcf0]
url:
https://github.com/intel-lab-lkp/linux/commits/Coiby-Xu/crash-Add-KUnit-tests-for-crash_exclude_mem_range/20250904-174105
base: b320789d6883cc00ac78ce83b
> 1. Find the `start_level` from the `target_order`. (for example,
> target_order = 10, start_level = 4)
> 2. The path from the root down to the level above `start_level` is
> fixed (index 0 at each of these levels).
> 3. At `start_level`, the index is also fixed, by (1 << (63 -
> PAGE_SHIFT
On Thu, Sep 18, 2025 at 03:25:59PM -0700, Cong Wang wrote:
> This patch series introduces multikernel architecture support, enabling
> multiple independent kernel instances to coexist and communicate on a
> single physical machine. Each kernel instance can run on dedicated CPU
> cores while sharing
syzbot ci has tested the following series
[v1] kernel: Introduce multikernel architecture support
https://lore.kernel.org/all/20250918222607.186488-1-xiyou.wangc...@gmail.com
* [RFC Patch 1/7] kexec: Introduce multikernel support via kexec
* [RFC Patch 2/7] x86: Introduce SMP INIT trampoline for m
On Thu, Sep 18, 2025 at 6:26 PM Cong Wang wrote:
>
> This patch series introduces multikernel architecture support, enabling
> multiple independent kernel instances to coexist and communicate on a
> single physical machine. Each kernel instance can run on dedicated CPU
> cores while sharing the un
On Mon, Sep 08, 2025 at 12:10:31PM +0100, Lorenzo Stoakes wrote:
Hi Lorenzo,
I am getting this warning with this series applied:
[Tue Sep 9 10:25:34 2025] [ cut here ]
[Tue Sep 9 10:25:34 2025] WARNING: CPU: 0 PID: 563 at mm/memory.c:2942
remap_pfn_range_internal+0x36e
On Wed 10-09-25 21:21:58, Lorenzo Stoakes wrote:
> It's useful to be able to determine the size of a VMA descriptor range used
> on f_op->mmap_prepare, expressed both in bytes and pages, so add helpers
> for both and update code that could make use of it to do so.
>
> Signed-off-by: Lorenzo Stoake
On Mon, Sep 08, 2025 at 05:15:12PM +0200, David Hildenbrand wrote:
> On 08.09.25 13:10, Lorenzo Stoakes wrote:
> > It is relatively trivial to update this code to use the f_op->mmap_prepare
> > hook in favour of the deprecated f_op->mmap hook, so do so.
> >
> > Signed-off-by: Lorenzo Stoakes
> > -
On Mon, Sep 08, 2025 at 03:18:46PM +0100, Lorenzo Stoakes wrote:
> On Mon, Sep 08, 2025 at 10:35:38AM -0300, Jason Gunthorpe wrote:
> > On Mon, Sep 08, 2025 at 02:27:12PM +0100, Lorenzo Stoakes wrote:
> >
> > > It's not only remap that is a concern here, people do all kinds of weird
> > > and wonde
On Mon, Sep 15, 2025 at 10:11:42AM -0300, Jason Gunthorpe wrote:
> On Mon, Sep 15, 2025 at 01:54:05PM +0100, Lorenzo Stoakes wrote:
> > > Just mark the functions as manipulating the action using the 'action'
> > > in the fuction name.
> >
> > Because now sub-callers that partially map using one met
On Thu, Sep 18, 2025 at 07:06:15PM +0200, Pratyush Yadav wrote:
> kho_fill_kimage() only checks for KHO being enabled before filling in
> the FDT to the image. KHO being enabled does not mean that the kernel
> has data to hand over. That happens when KHO is finalized.
>
> When a kexec is done with
On Wed, Sep 17, 2025 at 08:11:14PM +0100, Lorenzo Stoakes wrote:
> Add the ability to set up a shared anonymous mapping based on a VMA
> descriptor rather than a VMA.
>
> This is a prerequisite for converting to the char mm driver to use the
> mmap_prepare hook.
>
> Signed-off-by: Lorenzo Stoakes
On Mon, Sep 08, 2025 at 05:50:18PM +0200, David Hildenbrand wrote:
> So in practice there is indeed not a big difference between a private and
> cow mapping.
Right and most drivers just check SHARED.
But if we are being documentative why they check shared is because the
driver cannot tolerate CO
On 9/10/25 2:53 AM, Bagas Sanjaya wrote:
> On Tue, Sep 09, 2025 at 10:14:42PM +0200, Andrey Ryabinin wrote:
>> +There are _V forms of many KSTATE_ macros to load fields for version
>> dependent fields, e.g.
>
> Escape the trailing underscore (i.e. KSTATE\_).
>
>> +Addition of new field can be
abstract the concept of
action altogether.
>
> I'd probably also have a small helper wrapper for the very common case
> of whole vma:
>
> /* Fill the entire VMA with pfns starting at pfn. Caller must have
> * already checked desc has an appropriate size */
> mmap_action_rema
On Wed, Sep 17, 2025 at 08:11:08PM +0100, Lorenzo Stoakes wrote:
> -int remap_pfn_range_notrack(struct vm_area_struct *vma, unsigned long addr,
> +static int remap_pfn_range_notrack(struct vm_area_struct *vma, unsigned long
> addr,
> unsigned long pfn, unsigned long size, pgprot_t pr
Hi Andrew,
Finally could you apply the below, which has us return an error in case of
somebody implementing a buggy nommu action.
I also include a fix for the VMA unit tests where an enum declare was not
correctly propagated.
Cheers, Lorenzo
8<
>From 17c8037bc3bfd5cdd52369dc6140d0fbbd03
On Thu, Sep 18, 2025 at 12:11:05PM -0700, Chris Mason wrote:
> On Wed, 10 Sep 2025 21:22:06 +0100 Lorenzo Stoakes
> wrote:
>
> > Update the mem char driver (backing /dev/mem and /dev/zero) to use
> > f_op->mmap_prepare hook rather than the deprecated f_op->mmap.
> >
> > The /dev/zero implementati
On Wed, 10 Sep 2025 21:22:06 +0100 Lorenzo Stoakes
wrote:
> Update the mem char driver (backing /dev/mem and /dev/zero) to use
> f_op->mmap_prepare hook rather than the deprecated f_op->mmap.
>
> The /dev/zero implementation has a very unique and rather concerning
> characteristic in that it co
all refactorings as suggested by Jason.
> * Shared code between mmu and nommu mmap_action_complete() as per Jason.
> * Add missing return in kdoc for shmem_zero_setup().
> * Separate out introduction of shmem_zero_setup_desc() into another patch
> as per Jason.
> * Looked into Jas
On Wed, 10 Sep 2025 21:22:11 +0100 Lorenzo Stoakes
wrote:
> We can use the mmap insert pages functionality provided for use in
> mmap_prepare to insert the kcov pages as required.
>
> This does necessitate an allocation, but since it's in the mmap path this
> doesn't seem egregious. The allocat
On Thu, Sep 18, 2025 at 12:45:38PM -0700, Chris Mason wrote:
> On Wed, 10 Sep 2025 21:22:11 +0100 Lorenzo Stoakes
> wrote:
>
> > We can use the mmap insert pages functionality provided for use in
> > mmap_prepare to insert the kcov pages as required.
> >
> > This does necessitate an allocation, b
On Wed, Sep 17, 2025 at 06:19:44PM -0300, Jason Gunthorpe wrote:
> On Wed, Sep 17, 2025 at 08:11:09PM +0100, Lorenzo Stoakes wrote:
>
> > -#define io_remap_pfn_range(vma, vaddr, pfn, size, prot) \
> > - remap_pfn_range(vma, vaddr, pfn, size, prot)
> > +#define io_remap_pfn_range_pfn(pfn, size) (p
1 - 100 of 19810 matches
Mail list logo
