>>> On 22.11.16 at 17:13, <ta...@tklengyel.com> wrote: > On Tue, Nov 22, 2016 at 3:12 AM, Jan Beulich <jbeul...@suse.com> wrote: > >> >>> On 14.11.16 at 11:34, <jbeul...@suse.com> wrote: >> > They need to be range checked against the current table limit in any >> > event. >> > >> > Reported-by: Huawei PSIRT <ps...@huawei.com> >> > >> > Move the code to where it belongs, eliminating a number of duplicate >> > definitions. Add locking. Produce proper error codes, and consume them >> > instead of making one up. Check grant type. Convert parameter types at >> > once. >> > >> > Signed-off-by: Jan Beulich <jbeul...@suse.com> >> >> Tamas? (The minor fix needed to address Andrew's reply doesn't seem >> to warrant sending out a v2.) > > >> > --- >> > Note that likely there's more work needed subsequently: The grant isn't >> > being marked in use for the duration of the use of the GFN. But I'll >> > leave that to someone actually knowing how to properly to test this. >> >> > Hi Jan, > unfortunately I don't have a good way to test this either as I never used > memsharing with grefs before. The above comment about the grant not being > marked for in-use makes me wonder whether this is a regression from this > patch or whether that just was never the case.
This was never the case. I wouldn't dare to submit a patch knowingly breaking something. > Either way, I can see this > being an issue only if memory is being removed by hot-plugging, which AFAIK > is not a supported scenario anyway. The rest of the patch is fairly > mechanical, so: > > Acked-by: Tamas K Lengyel <ta...@tklengyel.com> Thanks. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
