On Thu, Aug 03, 2017 at 08:24:43PM +0300, Mike Rapoport wrote:
> Now, seriously, I believe there are not many users of non-cooperative uffd
> if at all and it is very unlikely anybody has it in production.
>
> I'll send a patch with s/ENOSPC/ESRCH in the next few days.
Ok.
Some more thought on
On Thu, Aug 03, 2017 at 08:24:43PM +0300, Mike Rapoport wrote:
> Now, seriously, I believe there are not many users of non-cooperative uffd
> if at all and it is very unlikely anybody has it in production.
>
> I'll send a patch with s/ENOSPC/ESRCH in the next few days.
Ok.
Some more thought on
On Wed, Aug 02, 2017 at 06:40:01PM +0200, Andrea Arcangeli wrote:
> On Wed, Aug 02, 2017 at 06:22:49PM +0200, Michal Hocko wrote:
> > ESRCH refers to "no such process". Strictly speaking userfaultfd code is
> > about a mm which is gone but that is a mere detail. In fact the owner of
>
> Well this
On Wed, Aug 02, 2017 at 06:40:01PM +0200, Andrea Arcangeli wrote:
> On Wed, Aug 02, 2017 at 06:22:49PM +0200, Michal Hocko wrote:
> > ESRCH refers to "no such process". Strictly speaking userfaultfd code is
> > about a mm which is gone but that is a mere detail. In fact the owner of
>
> Well this
On Wed, Aug 02, 2017 at 06:22:49PM +0200, Michal Hocko wrote:
> ESRCH refers to "no such process". Strictly speaking userfaultfd code is
> about a mm which is gone but that is a mere detail. In fact the owner of
Well this whole issue about which retval, is about a mere detail in
the first place,
On Wed, Aug 02, 2017 at 06:22:49PM +0200, Michal Hocko wrote:
> ESRCH refers to "no such process". Strictly speaking userfaultfd code is
> about a mm which is gone but that is a mere detail. In fact the owner of
Well this whole issue about which retval, is about a mere detail in
the first place,
On Wed 02-08-17 17:55:22, Andrea Arcangeli wrote:
> On Wed, Aug 02, 2017 at 03:34:41PM +0300, Mike Rapoport wrote:
> > I surely can take care of CRIU, but I don't know if QEMU or certain
> > database application that uses userfaultfd rely on this API, not mentioning
> > there maybe other unknown
On Wed 02-08-17 17:55:22, Andrea Arcangeli wrote:
> On Wed, Aug 02, 2017 at 03:34:41PM +0300, Mike Rapoport wrote:
> > I surely can take care of CRIU, but I don't know if QEMU or certain
> > database application that uses userfaultfd rely on this API, not mentioning
> > there maybe other unknown
On Wed, Aug 02, 2017 at 03:34:41PM +0300, Mike Rapoport wrote:
> I surely can take care of CRIU, but I don't know if QEMU or certain
> database application that uses userfaultfd rely on this API, not mentioning
> there maybe other unknown users.
>
> Andrea, what do you think?
The manpage would
On Wed, Aug 02, 2017 at 03:34:41PM +0300, Mike Rapoport wrote:
> I surely can take care of CRIU, but I don't know if QEMU or certain
> database application that uses userfaultfd rely on this API, not mentioning
> there maybe other unknown users.
>
> Andrea, what do you think?
The manpage would
* Mike Rapoport (r...@linux.vnet.ibm.com) wrote:
> On Mon, Jul 31, 2017 at 03:45:08PM +0200, Michal Hocko wrote:
> > On Mon 31-07-17 15:32:47, Andrea Arcangeli wrote:
> > > On Mon, Jul 31, 2017 at 02:22:04PM +0200, Michal Hocko wrote:
> > > > On Thu 27-07-17 09:26:59, Mike Rapoport wrote:
> > > >
* Mike Rapoport (r...@linux.vnet.ibm.com) wrote:
> On Mon, Jul 31, 2017 at 03:45:08PM +0200, Michal Hocko wrote:
> > On Mon 31-07-17 15:32:47, Andrea Arcangeli wrote:
> > > On Mon, Jul 31, 2017 at 02:22:04PM +0200, Michal Hocko wrote:
> > > > On Thu 27-07-17 09:26:59, Mike Rapoport wrote:
> > > >
On Mon, Jul 31, 2017 at 03:45:08PM +0200, Michal Hocko wrote:
> On Mon 31-07-17 15:32:47, Andrea Arcangeli wrote:
> > On Mon, Jul 31, 2017 at 02:22:04PM +0200, Michal Hocko wrote:
> > > On Thu 27-07-17 09:26:59, Mike Rapoport wrote:
> > > > In the non-cooperative userfaultfd case, the process exit
On Mon, Jul 31, 2017 at 03:45:08PM +0200, Michal Hocko wrote:
> On Mon 31-07-17 15:32:47, Andrea Arcangeli wrote:
> > On Mon, Jul 31, 2017 at 02:22:04PM +0200, Michal Hocko wrote:
> > > On Thu 27-07-17 09:26:59, Mike Rapoport wrote:
> > > > In the non-cooperative userfaultfd case, the process exit
On Mon 31-07-17 15:32:47, Andrea Arcangeli wrote:
> On Mon, Jul 31, 2017 at 02:22:04PM +0200, Michal Hocko wrote:
> > On Thu 27-07-17 09:26:59, Mike Rapoport wrote:
> > > In the non-cooperative userfaultfd case, the process exit may race with
> > > outstanding mcopy_atomic called by the uffd
On Mon 31-07-17 15:32:47, Andrea Arcangeli wrote:
> On Mon, Jul 31, 2017 at 02:22:04PM +0200, Michal Hocko wrote:
> > On Thu 27-07-17 09:26:59, Mike Rapoport wrote:
> > > In the non-cooperative userfaultfd case, the process exit may race with
> > > outstanding mcopy_atomic called by the uffd
On Mon, Jul 31, 2017 at 02:22:04PM +0200, Michal Hocko wrote:
> On Thu 27-07-17 09:26:59, Mike Rapoport wrote:
> > In the non-cooperative userfaultfd case, the process exit may race with
> > outstanding mcopy_atomic called by the uffd monitor. Returning -ENOSPC
> > instead of -EINVAL when mm is
On Mon, Jul 31, 2017 at 02:22:04PM +0200, Michal Hocko wrote:
> On Thu 27-07-17 09:26:59, Mike Rapoport wrote:
> > In the non-cooperative userfaultfd case, the process exit may race with
> > outstanding mcopy_atomic called by the uffd monitor. Returning -ENOSPC
> > instead of -EINVAL when mm is
On Mon, Jul 31, 2017 at 02:22:04PM +0200, Michal Hocko wrote:
> On Thu 27-07-17 09:26:59, Mike Rapoport wrote:
> > In the non-cooperative userfaultfd case, the process exit may race with
> > outstanding mcopy_atomic called by the uffd monitor. Returning -ENOSPC
> > instead of -EINVAL when mm is
On Mon, Jul 31, 2017 at 02:22:04PM +0200, Michal Hocko wrote:
> On Thu 27-07-17 09:26:59, Mike Rapoport wrote:
> > In the non-cooperative userfaultfd case, the process exit may race with
> > outstanding mcopy_atomic called by the uffd monitor. Returning -ENOSPC
> > instead of -EINVAL when mm is
On Thu 27-07-17 09:26:59, Mike Rapoport wrote:
> In the non-cooperative userfaultfd case, the process exit may race with
> outstanding mcopy_atomic called by the uffd monitor. Returning -ENOSPC
> instead of -EINVAL when mm is already gone will allow uffd monitor to
> distinguish this case from
On Thu 27-07-17 09:26:59, Mike Rapoport wrote:
> In the non-cooperative userfaultfd case, the process exit may race with
> outstanding mcopy_atomic called by the uffd monitor. Returning -ENOSPC
> instead of -EINVAL when mm is already gone will allow uffd monitor to
> distinguish this case from
In the non-cooperative userfaultfd case, the process exit may race with
outstanding mcopy_atomic called by the uffd monitor. Returning -ENOSPC
instead of -EINVAL when mm is already gone will allow uffd monitor to
distinguish this case from other error conditions.
Cc: sta...@vger.kernel.org
In the non-cooperative userfaultfd case, the process exit may race with
outstanding mcopy_atomic called by the uffd monitor. Returning -ENOSPC
instead of -EINVAL when mm is already gone will allow uffd monitor to
distinguish this case from other error conditions.
Cc: sta...@vger.kernel.org
24 matches
Mail list logo
