On Thu, Oct 31, 2019 at 11:12:52PM +0200, Jarkko Sakkinen wrote: > On Wed, Oct 30, 2019 at 02:30:45AM -0700, Sean Christopherson wrote: > > Why? The number of pages processed is effectively returned via the params > > on any error, e.g. wouldn't it be more appropriate to return -ERESTARTSYS? > > And I don't see any reason to add an arbitrary cap on the number of pages, > > e.g. SGX plays nice with the scheduler and signals, and restricting the > > number of EPC pages available to a process via cgroups (returning -ENOMEM) > > is a better solution for managing EPC. > > Returning -ENOMEM does not tell you from which page to retry. API should be robust enough to be able to cap the amount of data processed with or without cgroups like send(), recv(), read() and write() are and the call pattern for it must be a loop not a single shot call for any megalomaniac length. I'll add @count to address this. This output field will contain the number of bytes actually written instead of overwriting input parameters, which is a bad practice in anyway. We don't need to actually cap to anything but API must be able to support such scenario. Caller must be prepared to deal with the situation where the return value is zero but @count < @length. /Jarkko
