From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: [PATCH XEN v8 14/29] tools/libs/foreignmemory: Mention restrictions on fork in docs. Date: Tue, 19 Jan 2016 14:25:56 +0000 Message-ID: <20160119142556.GE1691@citrix.com> References: <1452864168.32341.97.camel@citrix.com> <1452864188-2417-1-git-send-email-ian.campbell@citrix.com> <1452864188-2417-15-git-send-email-ian.campbell@citrix.com> <20160119132400.GW1691@citrix.com> <1453210498.29930.31.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <1453210498.29930.31.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: ian.jackson@eu.citrix.com, Wei Liu , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Tue, Jan 19, 2016 at 01:34:58PM +0000, Ian Campbell wrote: > On Tue, 2016-01-19 at 13:24 +0000, Wei Liu wrote: > > On Fri, Jan 15, 2016 at 01:22:53PM +0000, Ian Campbell wrote: > > > Signed-off-by: Ian Campbell > > > --- > > > v6: Also discuss recovering the memory. > > > = > > > v7: Further clarifications regarding forking based on ML discussions. > > > =A0=A0=A0=A0(Dropped Wei's ack) > > > --- > > > =A0.../libs/foreignmemory/include/xenforeignmemory.h=A0=A0| 33 > > > +++++++++++++++++++++- > > > =A01 file changed, 32 insertions(+), 1 deletion(-) > > > = > > > diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h > > > b/tools/libs/foreignmemory/include/xenforeignmemory.h > > > index 04ff548..a6d1bdb 100644 > > > --- a/tools/libs/foreignmemory/include/xenforeignmemory.h > > > +++ b/tools/libs/foreignmemory/include/xenforeignmemory.h > > > @@ -32,13 +32,44 @@ typedef struct xentoollog_logger xentoollog_logge= r; > > > =A0typedef struct xenforeignmemory_handle xenforeignmemory_handle; > > > =A0 > > > =A0/* > > > - * Return a handle onto the hypercall driver.=A0=A0Logs errors. > > > + * Return a handle onto the foreign memory mapping driver.=A0=A0Logs > > > errors. > > > + * > > > + * Note: After fork(2) a child process must not use any opened > > > + * foreignmemory handle inherited from their parent, nor access any > > > + * grant mapped areas associated with that handle. > > > + * > > > + * The child must open a new handle if they want to interact with > > > + * foreignmemory. > > > + * > > > + * Calling exec(2) in a child will safely (and reliably) reclaim any > > > + * resources which were allocated via a xenforeignmemory_handle in t= he > > > + * parent. > > > + * > > > + * A child which does not call exec(2) may safely call > > > + * xenforeignmemory_close() on a xenforeignmemory_handle inherited > > > + * from their parent. This will attempt to reclaim any resources > > > + * associated with that handle. Note that in some implementations th= is > > > + * reclamation may not be completely effective, in this case any > > > + * affected resources remain allocated. > > > + * > > > + * Calling xenforeignmemory_close() is the only safe operation on a > > > + * xenforeignmemory_handle which has been inherited. > > > =A0 */ > > > =A0xenforeignmemory_handle *xenforeignmemory_open(xentoollog_logger > > > *logger, > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= unsigned open_flags); > > > =A0 > > > =A0/* > > > =A0 * Close a handle previously allocated with xenforeignmemory_open(= ). > > > + * > > > + * Under normal circumstances (i.e. not in the child after a fork) > > > + * xenforeignmemory_unmap() should be used on all mappings allocated > > = > > "Should" according to RFC 2119 has the connotation of "there might be a > > valid reason to ignore such action". But after reading this passage I > > think we should use "must" here? > = > RFC 2119 formally defines "SHOULD" not "should" (or "Should"), and in any > case in order to be subject to those formal definitions a document would > need to explicitly reference RFC 2119. > = > I think most readers of normal English prose would probably take "must" a= nd > "should" to mean mostly the same thing. > = > If there are other reasons to resend I don't mind switching it to must, b= ut > I don't think it is worth a resend of this mega-series for what is a minor > semantic quibble. > = No need to resend then. Acked-by: Wei Liu Wei. > Ian.