On 04/28/2015 12:12 AM, Andrea Arcangeli wrote:
> Hello,
>
> On Thu, Apr 23, 2015 at 09:29:07AM +0300, Pavel Emelyanov wrote:
>> So your proposal is to always report 16 bytes per PF from read() and
>> let userspace decide itself how to handle the result?
>
> Reading 16bytes for each userfault (in
Hello,
On Thu, Apr 23, 2015 at 09:29:07AM +0300, Pavel Emelyanov wrote:
> So your proposal is to always report 16 bytes per PF from read() and
> let userspace decide itself how to handle the result?
Reading 16bytes for each userfault (instead of 8) and sharing the same
read(2) protocol (UFFD_API)
On 04/21/2015 03:18 PM, Andrea Arcangeli wrote:
> On Wed, Mar 18, 2015 at 10:35:17PM +0300, Pavel Emelyanov wrote:
>> +if (!(ctx->features & UFFD_FEATURE_LONGMSG)) {
>
> If we are to use different protocols, it'd be nicer to have two
> different methods to assign to userfaultfd_fops.re
On Wed, Mar 18, 2015 at 10:35:17PM +0300, Pavel Emelyanov wrote:
> + if (!(ctx->features & UFFD_FEATURE_LONGMSG)) {
If we are to use different protocols, it'd be nicer to have two
different methods to assign to userfaultfd_fops.read that calls an
__always_inline function, so that the a
The new API will report more than just the page-faults. The
reason for this is -- when the task whose mm we monitor with
uffd and the monitor task itself cannot cooperate with each
other, the former one can screw things up. Like this.
If task fork()-s the child process is detached from uffd and
t
5 matches
Mail list logo