On 16.06.2015 18:46, Borislav Petkov wrote:
> On Tue, Jun 16, 2015 at 02:45:06PM +0300, Andrey Ryabinin wrote:
>> Can't we just move clear_page(init_level4_pgt) higher? Before or right
>> after clear_bss() (iow before kasan_early_init()).
>
> That sounds much better. And I don't see anything
On 16.06.2015 18:46, Borislav Petkov wrote:
On Tue, Jun 16, 2015 at 02:45:06PM +0300, Andrey Ryabinin wrote:
Can't we just move clear_page(init_level4_pgt) higher? Before or right
after clear_bss() (iow before kasan_early_init()).
That sounds much better. And I don't see anything depending
On Tue, Jun 16, 2015 at 02:45:06PM +0300, Andrey Ryabinin wrote:
> Can't we just move clear_page(init_level4_pgt) higher? Before or right
> after clear_bss() (iow before kasan_early_init()).
That sounds much better. And I don't see anything depending on
init_level4_pgt before we clear it. And it
On 06/16/2015 02:34 PM, Borislav Petkov wrote:
> On Tue, Jun 16, 2015 at 01:16:32PM +0200, Borislav Petkov wrote:
>> Now my hunch is that those entries get overwritten later but I wouldn't
>> want to debug any strange bugs from leftovers in init_level4_pgt so
>> having the clear_page() is actually
On Tue, Jun 16, 2015 at 01:16:32PM +0200, Borislav Petkov wrote:
> Now my hunch is that those entries get overwritten later but I wouldn't
> want to debug any strange bugs from leftovers in init_level4_pgt so
> having the clear_page() is actually a good thing.
So I guess we can do that:
#ifndef
On Tue, Jun 09, 2015 at 12:42:00PM +0300, Alexander Popov wrote:
> From: Andrey Ryabinin
>
> Commit 8170e6bed465 ("x86, 64bit: Use a #PF handler to materialize
> early mappings on demand") introduced clear_page(init_level4_pgt);
> call in x86_64_start_kernel(). However, this clear_page is
On Tue, Jun 16, 2015 at 02:45:06PM +0300, Andrey Ryabinin wrote:
Can't we just move clear_page(init_level4_pgt) higher? Before or right
after clear_bss() (iow before kasan_early_init()).
That sounds much better. And I don't see anything depending on
init_level4_pgt before we clear it. And it
On Tue, Jun 09, 2015 at 12:42:00PM +0300, Alexander Popov wrote:
From: Andrey Ryabinin a.ryabi...@samsung.com
Commit 8170e6bed465 (x86, 64bit: Use a #PF handler to materialize
early mappings on demand) introduced clear_page(init_level4_pgt);
call in x86_64_start_kernel(). However, this
On Tue, Jun 16, 2015 at 01:16:32PM +0200, Borislav Petkov wrote:
Now my hunch is that those entries get overwritten later but I wouldn't
want to debug any strange bugs from leftovers in init_level4_pgt so
having the clear_page() is actually a good thing.
So I guess we can do that:
#ifndef
On 06/16/2015 02:34 PM, Borislav Petkov wrote:
On Tue, Jun 16, 2015 at 01:16:32PM +0200, Borislav Petkov wrote:
Now my hunch is that those entries get overwritten later but I wouldn't
want to debug any strange bugs from leftovers in init_level4_pgt so
having the clear_page() is actually a good
From: Andrey Ryabinin
Commit 8170e6bed465 ("x86, 64bit: Use a #PF handler to materialize
early mappings on demand") introduced clear_page(init_level4_pgt);
call in x86_64_start_kernel(). However, this clear_page is useless
because init_level4_page already filled with zeroes in head_64.S
Commit
From: Andrey Ryabinin a.ryabi...@samsung.com
Commit 8170e6bed465 (x86, 64bit: Use a #PF handler to materialize
early mappings on demand) introduced clear_page(init_level4_pgt);
call in x86_64_start_kernel(). However, this clear_page is useless
because init_level4_page already filled with zeroes
12 matches
Mail list logo
