[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87tudhjmx7.fsf@email.froward.int.ebiederm.org>
Date: Wed, 02 Feb 2022 09:41:40 -0600
From: "Eric W. Biederman" <ebiederm@...ssion.com>
To: Jann Horn <jannh@...gle.com>
Cc: Matthew Wilcox <willy@...radead.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
Alexander Viro <viro@...iv.linux.org.uk>,
Denys Vlasenko <vda.linux@...glemail.com>,
Kees Cook <keescook@...omium.org>,
Vlastimil Babka <vbabka@...e.cz>,
"Liam R . Howlett" <liam.howlett@...cle.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 2/5] coredump: Snapshot the vmas in do_coredump
Jann Horn <jannh@...gle.com> writes:
> On Mon, Jan 31, 2022 at 7:46 PM Eric W. Biederman <ebiederm@...ssion.com> wrote:
>> Move the call of dump_vma_snapshot and kvfree(vma_meta) out of the
>> individual coredump routines into do_coredump itself. This makes
>> the code less error prone and easier to maintain.
>>
>> Make the vma snapshot available to the coredump routines
>> in struct coredump_params. This makes it easier to
>> change and update what is captures in the vma snapshot
>> and will be needed for fixing fill_file_notes.
>>
>> Signed-off-by: "Eric W. Biederman" <ebiederm@...ssion.com>
>
> Reviewed-by: Jann Horn <jannh@...gle.com>
>
>> for (i = 0, vma = first_vma(current, gate_vma); vma != NULL;
>> vma = next_vma(vma, gate_vma), i++) {
>> - struct core_vma_metadata *m = (*vma_meta) + i;
>> + struct core_vma_metadata *m = cprm->vma_meta + i;
>>
>> m->start = vma->vm_start;
>> m->end = vma->vm_end;
>> m->flags = vma->vm_flags;
>> m->dump_size = vma_dump_size(vma, cprm->mm_flags);
>>
>> - vma_data_size += m->dump_size;
>> + cprm->vma_data_size += m->dump_size;
>
> FYI, this part is probably going to cause a merge conflict with the
> fix https://www.ozlabs.org/~akpm/mmotm/broken-out/coredump-also-dump-first-pages-of-non-executable-elf-libraries.patch
> in akpm's tree. I don't know what the right way to handle that is,
> just thought I'd point it out.
There are not any conflicts in principle we could just let resolution
handle it. Unfortunately both are candidates for backporting.
Either we replace your fix with a simple deletion of the executable
check, or I need to base mine on yours.
Since I need to repost mine anyway I will look at the latter.
Eric
Powered by blists - more mailing lists