Re: [Xen-devel] [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as required

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.03.19 at 16:36, <ian.jackson@xxxxxxxxxx> wrote:
> Jan Beulich writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as 
> required"):
>> Ian Jackson <ian.jackson@xxxxxxxxxx> 03/07/19 3:44 PM >>>
>> >Jan Beulich writes ("Re: [PATCH v11 5/9] xen/x86: use DECLARE_BOUNDS as 
>> >required"):
>> >> I'd like to note though that in the first two cases we don't alter the
>> >> declared object anyway, but instead a derived one; the declaration
>> >> should not use const for other reasons though. And the 3rd case is
>> >> fiddling with something that has lost its meaning as an object. In fact
>> >> we're about to free the underlying memory. In this case I'd prefer to
>> >> retain the const, but I won't insist as the symbol is non-const right
>> >> now as well.
>> >
>> >I think if you do this
>> >extern const struct blah blah_start[];
>> >it is not safe to cast the const away later.
> ...
>> It looks to me as if we were in agreement then.
> 
> Perhaps so.
> 
>> I was talking about freeing an object that was const-qualified, not
>> modifying it.
> 
> I'm not sure what you mean, precisely.  Do you mean this:
> 
>    extern const struct blah blah_start[];
>    ...
>    free(blah_start);
> 
> ?  But I'm sure the hypervisor doesn't have a function free().

It has xfree(), free_xenheap_pages() and a few more.

>> The scrubbing of the memory could be considered part
>> of the freeing, it just ought to occur up front because of otherwise
>> possible races, and because we have no means to tell the freeing
>> function to do the scrubbing (in fact I should say "we used to have
>> no means, as I think right now the memory would be scrubbed
>> implicitly, so the explicit scrubbing could probably be dropped).
> 
> Maybe you mean this:
> 
>    extern const struct blah blah_start[];
>    ...
>    memset(blah_start, 0, size of blah array);
> 
> ?  That is clearly forbidden, regardless of whether the cost
> is cast away.  But I think this:
> 
>    extern struct blah blah_start[];
>    ...
>    memset(blah_start, 0, size of blah array);
> 
> is fine.

Of course. What I was meaning though is entirely different.
Assume we had

void my_free(const void *);

I could then

extern const struct blah blah_start[];
...
my_free(blah_start);

my_free() might internally scrub the memory, no matter that it
was handed a pointer to const, because at that point the
memory doesn't underly any particular object anymore - it's just
plain memory. The context here was

    /* Zero the .init code and data. */
    for ( va = __init_begin; va < _p(__init_end); va += PAGE_SIZE )
        clear_page(va);

    /* Destroy Xen's mappings, and reuse the pages. */
    if ( using_2M_mapping() )
    {
        start = (unsigned long)&__2M_init_start,
        end   = (unsigned long)&__2M_init_end;
    }
    else
    {
        start = (unsigned long)&__init_begin;
        end   = (unsigned long)&__init_end;
    }

    destroy_xen_mappings(start, end);
    init_xenheap_pages(__pa(start), __pa(end));

and what I was trying to explain is that here we're simply doing
the scrubbing ahead of calling the freeing function
(init_xenheap_pages()) because, at least back when this code
was written, no scrubbing would have been done inside the
page allocator itself in this case.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel