Re: Policy: A release acks for the release manager's patches (was Re: [PATCH v5 2/2] xen/arm: p2m: Populate pages for GICv2 mapping in p2m_init())

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.10.2022 17:28, George Dunlap wrote:
> On Tue, Oct 18, 2022 at 3:24 PM Henry Wang <Henry.Wang@xxxxxxx> wrote:
> 
>> Hardware using GICv2 needs to create a P2M mapping of 8KB GICv2 area
>> when the domain is created. Considering the worst case of page tables
>> which requires 6 P2M pages as the two pages will be consecutive but not
>> necessarily in the same L3 page table and keep a buffer, populate 16
>> pages as the default value to the P2M pages pool in p2m_init() at the
>> domain creation stage to satisfy the GICv2 requirement. For GICv3, the
>> above-mentioned P2M mapping is not necessary, but since the allocated
>> 16 pages here would not be lost, hence populate these pages
>> unconditionally.
>>
>> With the default 16 P2M pages populated, there would be a case that
>> failures would happen in the domain creation with P2M pages already in
>> use. To properly free the P2M for this case, firstly support the
>> optionally preemption of p2m_teardown(), then call p2m_teardown() and
>> p2m_set_allocation(d, 0, NULL) non-preemptively in p2m_final_teardown().
>> As non-preemptive p2m_teardown() should only return 0, use a
>> BUG_ON to confirm that.
>>
>> Since p2m_final_teardown() is called either after
>> domain_relinquish_resources() where relinquish_p2m_mapping() has been
>> called, or from failure path of domain_create()/arch_domain_create()
>> where mappings that require p2m_put_l3_page() should never be created,
>> relinquish_p2m_mapping() is not added in p2m_final_teardown(), add
>> in-code comments to refer this.
>>
>> Fixes: cbea5a1149ca ("xen/arm: Allocate and free P2M pages from the P2M
>> pool")
>> Suggested-by: Julien Grall <jgrall@xxxxxxxxxx>
>> Signed-off-by: Henry Wang <Henry.Wang@xxxxxxx>
>>
> 
> 
> Henry brought this patch to my attention because it needs a release ack,
> but it doesn't seem proper for Henry to be the one to release-ack his own
> patches. :-)
> 
> I propose that a suitable rule would be:
> 
> "If the release manager themselves have submitted a patch which needs a
> release ack, then the patch needs a release ack from one of the Committers
> who is not involved in the patch."

Like Andrew I think a self-release-ack, as was common practice in the past,
is quite fine. These are entirely different hats that the person would be
wearing.

Jan