Hi Jan,
On 04/05/2021 09:42, Jan Beulich wrote:
This array can be large when many grant frames are permitted; avoid
allocating it when it's not going to be used anyway, by doing this only
in gnttab_populate_status_frames(). While the delaying of the respective
memory allocation adds possible reasons for failure of the respective
enclosing operations, there are other memory allocations there already,
so callers can't expect these operations to always succeed anyway.
As to the re-ordering at the end of gnttab_unpopulate_status_frames(),
this is merely to represent intended order of actions (shrink array
bound, then free higher array entries). If there were racing accesses,
suitable barriers would need adding in addition.
Please drop the last sentence, this is at best misleading because you
can't just add barriers to make it race free (see the discussion on v2
for more details).
With the sentence dropped:
Reviewed-by: Julien Grall <[email protected]>
Cheers,
[1] <[email protected]>
--
Julien Grall
