[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] trace: convert init_trace_bufs() to constructor



Hi Jan,

On 27/03/2025 16:10, Jan Beulich wrote:
On 27.03.2025 16:49, Julien Grall wrote:
On 27/03/2025 15:08, Jan Beulich wrote:
On 27.03.2025 15:49, Julien Grall wrote:
On 13/03/2025 13:38, Jan Beulich wrote:
---
Same could then apparently be done for heap_init_late(). Thoughts?

Looking at the code, I couldn't figure out whether any of the
constructors may rely on some changes done by heap_init_late().

The only issue I can think of is scrubbing. In the case it is
synchronous, would the memory allocated before hand be scrubbed?

Memory that is allocated can't possibly be scrubbed; only memory that's
still un-allocated can be. With that I fear I don't properly understand
the question you raise.

I meant that if memory is allocated by calls from init_constructors().
Before this patch, the memory would be scrubbed. After this patch,
anything constructors called before heap_init_late() would end up to not
be scrubbed if it is synchronous.

Oh, I see. Since scrubbing may be asynchronous, any site relying on scrubbing
having happened would be flawed anyway.

I have to disagree. If the scrubbing is asynchronous then...

Apart from that, unless callers pass
MEMF_no_scrub to alloc_heap_pages(), un-scrubbed pages would be scrubbed> 
anyway (see near the end of the function).

... the page will be scrubbed at the time it is allocated if it was not done before. But for synchronous scrubbing, at boot, this will not be the case (unless CONFIG_SCRUB_DEBUG is set and with the associated command line option). It will only happen during heap_init_late(). This is because init_heap_pages() will not request scrubbing unless asynchronous scrubbing is enabled (or CONFIG_SCRUB_DEBUG is set and with the associated command line).

So I still think there is a potential difference of behavior if we move heap_init_late() later. Someone will need to investigate whether there is effectively an issue.

Cheers,

--
Julien Grall




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.