From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753311AbbA2Ojb (ORCPT ); Thu, 29 Jan 2015 09:39:31 -0500 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:34280 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751815AbbA2Oja (ORCPT ); Thu, 29 Jan 2015 09:39:30 -0500 Date: Thu, 29 Jan 2015 14:39:08 +0000 From: Russell King - ARM Linux To: Sumit Semwal Cc: linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linaro-kernel@lists.linaro.org, stanislawski.tomasz@googlemail.com, robdclark@gmail.com, daniel@ffwll.ch, robin.murphy@arm.com, m.szyprowski@samsung.com Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Message-ID: <20150129143908.GA26493@n2100.arm.linux.org.uk> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 27, 2015 at 01:55:54PM +0530, Sumit Semwal wrote: > +/* > + * recalc_constraints - recalculates constraints for all attached devices; > + * useful for detach() recalculation, and for dma_buf_recalc_constraints() > + * helper. > + * Returns recalculated constraints in recalc_cons, or error in the unlikely > + * case when constraints of attached devices might have changed. > + */ Please see kerneldoc documentation for the proper format of these comments. > +static int recalc_constraints(struct dma_buf *dmabuf, > + struct device_dma_parameters *recalc_cons) > +{ > + struct device_dma_parameters calc_cons; > + struct dma_buf_attachment *attach; > + int ret = 0; > + > + init_constraints(&calc_cons); > + > + list_for_each_entry(attach, &dmabuf->attachments, node) { > + ret = calc_constraints(attach->dev, &calc_cons); > + if (ret) > + return ret; > + } > + *recalc_cons = calc_cons; > + return 0; > +} > + > /** > * dma_buf_export_named - Creates a new dma_buf, and associates an anon file > * with this buffer, so it can be exported. > @@ -313,6 +373,9 @@ struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops, > dmabuf->ops = ops; > dmabuf->size = size; > dmabuf->exp_name = exp_name; > + > + init_constraints(&dmabuf->constraints); > + > init_waitqueue_head(&dmabuf->poll); > dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll; > dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0; > @@ -422,7 +485,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, > struct device *dev) > { > struct dma_buf_attachment *attach; > - int ret; > + int ret = 0; > > if (WARN_ON(!dmabuf || !dev)) > return ERR_PTR(-EINVAL); > @@ -436,6 +499,9 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, > > mutex_lock(&dmabuf->lock); > > + if (calc_constraints(dev, &dmabuf->constraints)) > + goto err_constraints; > + > if (dmabuf->ops->attach) { > ret = dmabuf->ops->attach(dmabuf, dev, attach); > if (ret) > @@ -448,6 +514,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, > > err_attach: > kfree(attach); > +err_constraints: > mutex_unlock(&dmabuf->lock); > return ERR_PTR(ret); > } > @@ -470,6 +537,8 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) > if (dmabuf->ops->detach) > dmabuf->ops->detach(dmabuf, attach); > > + recalc_constraints(dmabuf, &dmabuf->constraints); > + To me, this whole thing seems horribly racy. What happens if subsystem X creates a dmabuf, which is passed to userspace. It's then passed to subsystem Y, which starts making use of it, calling dma_buf_map_attachment() on it. The same buffer is also passed (via unix domain sockets) to another program, which then passes it independently into subsystem Z, and subsystem Z has more restrictive DMA constraints. What happens at this point? Subsystems such as DRM cache the scatter table, and return it for subsequent attach calls, so DRM drivers using the default drm_gem_map_dma_buf() implementation would not see the restrictions placed upon the dmabuf. Moreover, the returned scatterlist would not be modified for those restrictions either. What would other subsystems do? This needs more thought before it's merged. For example, in the above situation, should we deny the ability to create a new attachment when a dmabuf has already been mapped by an existing attachment? Should we deny it only when the new attachment has more restrictive DMA constraints? Please consider the possible sequences of use (such as the scenario above) when creating or augmenting an API. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by kanga.kvack.org (Postfix) with ESMTP id 48B066B0038 for ; Thu, 29 Jan 2015 09:39:34 -0500 (EST) Received: by mail-wg0-f47.google.com with SMTP id n12so23346437wgh.6 for ; Thu, 29 Jan 2015 06:39:33 -0800 (PST) Received: from pandora.arm.linux.org.uk (pandora.arm.linux.org.uk. [2001:4d48:ad52:3201:214:fdff:fe10:1be6]) by mx.google.com with ESMTPS id ht7si3924334wib.3.2015.01.29.06.39.31 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 29 Jan 2015 06:39:32 -0800 (PST) Date: Thu, 29 Jan 2015 14:39:08 +0000 From: Russell King - ARM Linux Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Message-ID: <20150129143908.GA26493@n2100.arm.linux.org.uk> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> Sender: owner-linux-mm@kvack.org List-ID: To: Sumit Semwal Cc: linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linaro-kernel@lists.linaro.org, stanislawski.tomasz@googlemail.com, robdclark@gmail.com, daniel@ffwll.ch, robin.murphy@arm.com, m.szyprowski@samsung.com On Tue, Jan 27, 2015 at 01:55:54PM +0530, Sumit Semwal wrote: > +/* > + * recalc_constraints - recalculates constraints for all attached devices; > + * useful for detach() recalculation, and for dma_buf_recalc_constraints() > + * helper. > + * Returns recalculated constraints in recalc_cons, or error in the unlikely > + * case when constraints of attached devices might have changed. > + */ Please see kerneldoc documentation for the proper format of these comments. > +static int recalc_constraints(struct dma_buf *dmabuf, > + struct device_dma_parameters *recalc_cons) > +{ > + struct device_dma_parameters calc_cons; > + struct dma_buf_attachment *attach; > + int ret = 0; > + > + init_constraints(&calc_cons); > + > + list_for_each_entry(attach, &dmabuf->attachments, node) { > + ret = calc_constraints(attach->dev, &calc_cons); > + if (ret) > + return ret; > + } > + *recalc_cons = calc_cons; > + return 0; > +} > + > /** > * dma_buf_export_named - Creates a new dma_buf, and associates an anon file > * with this buffer, so it can be exported. > @@ -313,6 +373,9 @@ struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops, > dmabuf->ops = ops; > dmabuf->size = size; > dmabuf->exp_name = exp_name; > + > + init_constraints(&dmabuf->constraints); > + > init_waitqueue_head(&dmabuf->poll); > dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll; > dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0; > @@ -422,7 +485,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, > struct device *dev) > { > struct dma_buf_attachment *attach; > - int ret; > + int ret = 0; > > if (WARN_ON(!dmabuf || !dev)) > return ERR_PTR(-EINVAL); > @@ -436,6 +499,9 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, > > mutex_lock(&dmabuf->lock); > > + if (calc_constraints(dev, &dmabuf->constraints)) > + goto err_constraints; > + > if (dmabuf->ops->attach) { > ret = dmabuf->ops->attach(dmabuf, dev, attach); > if (ret) > @@ -448,6 +514,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, > > err_attach: > kfree(attach); > +err_constraints: > mutex_unlock(&dmabuf->lock); > return ERR_PTR(ret); > } > @@ -470,6 +537,8 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) > if (dmabuf->ops->detach) > dmabuf->ops->detach(dmabuf, attach); > > + recalc_constraints(dmabuf, &dmabuf->constraints); > + To me, this whole thing seems horribly racy. What happens if subsystem X creates a dmabuf, which is passed to userspace. It's then passed to subsystem Y, which starts making use of it, calling dma_buf_map_attachment() on it. The same buffer is also passed (via unix domain sockets) to another program, which then passes it independently into subsystem Z, and subsystem Z has more restrictive DMA constraints. What happens at this point? Subsystems such as DRM cache the scatter table, and return it for subsequent attach calls, so DRM drivers using the default drm_gem_map_dma_buf() implementation would not see the restrictions placed upon the dmabuf. Moreover, the returned scatterlist would not be modified for those restrictions either. What would other subsystems do? This needs more thought before it's merged. For example, in the above situation, should we deny the ability to create a new attachment when a dmabuf has already been mapped by an existing attachment? Should we deny it only when the new attachment has more restrictive DMA constraints? Please consider the possible sequences of use (such as the scenario above) when creating or augmenting an API. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@arm.linux.org.uk (Russell King - ARM Linux) Date: Thu, 29 Jan 2015 14:39:08 +0000 Subject: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms In-Reply-To: <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> Message-ID: <20150129143908.GA26493@n2100.arm.linux.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Jan 27, 2015 at 01:55:54PM +0530, Sumit Semwal wrote: > +/* > + * recalc_constraints - recalculates constraints for all attached devices; > + * useful for detach() recalculation, and for dma_buf_recalc_constraints() > + * helper. > + * Returns recalculated constraints in recalc_cons, or error in the unlikely > + * case when constraints of attached devices might have changed. > + */ Please see kerneldoc documentation for the proper format of these comments. > +static int recalc_constraints(struct dma_buf *dmabuf, > + struct device_dma_parameters *recalc_cons) > +{ > + struct device_dma_parameters calc_cons; > + struct dma_buf_attachment *attach; > + int ret = 0; > + > + init_constraints(&calc_cons); > + > + list_for_each_entry(attach, &dmabuf->attachments, node) { > + ret = calc_constraints(attach->dev, &calc_cons); > + if (ret) > + return ret; > + } > + *recalc_cons = calc_cons; > + return 0; > +} > + > /** > * dma_buf_export_named - Creates a new dma_buf, and associates an anon file > * with this buffer, so it can be exported. > @@ -313,6 +373,9 @@ struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops, > dmabuf->ops = ops; > dmabuf->size = size; > dmabuf->exp_name = exp_name; > + > + init_constraints(&dmabuf->constraints); > + > init_waitqueue_head(&dmabuf->poll); > dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll; > dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0; > @@ -422,7 +485,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, > struct device *dev) > { > struct dma_buf_attachment *attach; > - int ret; > + int ret = 0; > > if (WARN_ON(!dmabuf || !dev)) > return ERR_PTR(-EINVAL); > @@ -436,6 +499,9 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, > > mutex_lock(&dmabuf->lock); > > + if (calc_constraints(dev, &dmabuf->constraints)) > + goto err_constraints; > + > if (dmabuf->ops->attach) { > ret = dmabuf->ops->attach(dmabuf, dev, attach); > if (ret) > @@ -448,6 +514,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, > > err_attach: > kfree(attach); > +err_constraints: > mutex_unlock(&dmabuf->lock); > return ERR_PTR(ret); > } > @@ -470,6 +537,8 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) > if (dmabuf->ops->detach) > dmabuf->ops->detach(dmabuf, attach); > > + recalc_constraints(dmabuf, &dmabuf->constraints); > + To me, this whole thing seems horribly racy. What happens if subsystem X creates a dmabuf, which is passed to userspace. It's then passed to subsystem Y, which starts making use of it, calling dma_buf_map_attachment() on it. The same buffer is also passed (via unix domain sockets) to another program, which then passes it independently into subsystem Z, and subsystem Z has more restrictive DMA constraints. What happens at this point? Subsystems such as DRM cache the scatter table, and return it for subsequent attach calls, so DRM drivers using the default drm_gem_map_dma_buf() implementation would not see the restrictions placed upon the dmabuf. Moreover, the returned scatterlist would not be modified for those restrictions either. What would other subsystems do? This needs more thought before it's merged. For example, in the above situation, should we deny the ability to create a new attachment when a dmabuf has already been mapped by an existing attachment? Should we deny it only when the new attachment has more restrictive DMA constraints? Please consider the possible sequences of use (such as the scenario above) when creating or augmenting an API. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux Subject: Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms Date: Thu, 29 Jan 2015 14:39:08 +0000 Message-ID: <20150129143908.GA26493@n2100.arm.linux.org.uk> References: <1422347154-15258-1-git-send-email-sumit.semwal@linaro.org> <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from pandora.arm.linux.org.uk (pandora.arm.linux.org.uk [78.32.30.218]) by gabe.freedesktop.org (Postfix) with ESMTP id 07256720BC for ; Thu, 29 Jan 2015 06:39:29 -0800 (PST) Content-Disposition: inline In-Reply-To: <1422347154-15258-2-git-send-email-sumit.semwal@linaro.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Sumit Semwal Cc: linaro-kernel@lists.linaro.org, robin.murphy@arm.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, m.szyprowski@samsung.com, stanislawski.tomasz@googlemail.com, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org T24gVHVlLCBKYW4gMjcsIDIwMTUgYXQgMDE6NTU6NTRQTSArMDUzMCwgU3VtaXQgU2Vtd2FsIHdy b3RlOgo+ICsvKgo+ICsgKiByZWNhbGNfY29uc3RyYWludHMgLSByZWNhbGN1bGF0ZXMgY29uc3Ry YWludHMgZm9yIGFsbCBhdHRhY2hlZCBkZXZpY2VzOwo+ICsgKiAgdXNlZnVsIGZvciBkZXRhY2go KSByZWNhbGN1bGF0aW9uLCBhbmQgZm9yIGRtYV9idWZfcmVjYWxjX2NvbnN0cmFpbnRzKCkKPiAr ICogIGhlbHBlci4KPiArICogIFJldHVybnMgcmVjYWxjdWxhdGVkIGNvbnN0cmFpbnRzIGluIHJl Y2FsY19jb25zLCBvciBlcnJvciBpbiB0aGUgdW5saWtlbHkKPiArICogIGNhc2Ugd2hlbiBjb25z dHJhaW50cyBvZiBhdHRhY2hlZCBkZXZpY2VzIG1pZ2h0IGhhdmUgY2hhbmdlZC4KPiArICovCgpQ bGVhc2Ugc2VlIGtlcm5lbGRvYyBkb2N1bWVudGF0aW9uIGZvciB0aGUgcHJvcGVyIGZvcm1hdCBv ZiB0aGVzZSBjb21tZW50cy4KCj4gK3N0YXRpYyBpbnQgcmVjYWxjX2NvbnN0cmFpbnRzKHN0cnVj dCBkbWFfYnVmICpkbWFidWYsCj4gKwkJCSAgICAgIHN0cnVjdCBkZXZpY2VfZG1hX3BhcmFtZXRl cnMgKnJlY2FsY19jb25zKQo+ICt7Cj4gKwlzdHJ1Y3QgZGV2aWNlX2RtYV9wYXJhbWV0ZXJzIGNh bGNfY29uczsKPiArCXN0cnVjdCBkbWFfYnVmX2F0dGFjaG1lbnQgKmF0dGFjaDsKPiArCWludCBy ZXQgPSAwOwo+ICsKPiArCWluaXRfY29uc3RyYWludHMoJmNhbGNfY29ucyk7Cj4gKwo+ICsJbGlz dF9mb3JfZWFjaF9lbnRyeShhdHRhY2gsICZkbWFidWYtPmF0dGFjaG1lbnRzLCBub2RlKSB7Cj4g KwkJcmV0ID0gY2FsY19jb25zdHJhaW50cyhhdHRhY2gtPmRldiwgJmNhbGNfY29ucyk7Cj4gKwkJ aWYgKHJldCkKPiArCQkJcmV0dXJuIHJldDsKPiArCX0KPiArCSpyZWNhbGNfY29ucyA9IGNhbGNf Y29uczsKPiArCXJldHVybiAwOwo+ICt9Cj4gKwo+ICAvKioKPiAgICogZG1hX2J1Zl9leHBvcnRf bmFtZWQgLSBDcmVhdGVzIGEgbmV3IGRtYV9idWYsIGFuZCBhc3NvY2lhdGVzIGFuIGFub24gZmls ZQo+ICAgKiB3aXRoIHRoaXMgYnVmZmVyLCBzbyBpdCBjYW4gYmUgZXhwb3J0ZWQuCj4gQEAgLTMx Myw2ICszNzMsOSBAQCBzdHJ1Y3QgZG1hX2J1ZiAqZG1hX2J1Zl9leHBvcnRfbmFtZWQodm9pZCAq cHJpdiwgY29uc3Qgc3RydWN0IGRtYV9idWZfb3BzICpvcHMsCj4gIAlkbWFidWYtPm9wcyA9IG9w czsKPiAgCWRtYWJ1Zi0+c2l6ZSA9IHNpemU7Cj4gIAlkbWFidWYtPmV4cF9uYW1lID0gZXhwX25h bWU7Cj4gKwo+ICsJaW5pdF9jb25zdHJhaW50cygmZG1hYnVmLT5jb25zdHJhaW50cyk7Cj4gKwo+ ICAJaW5pdF93YWl0cXVldWVfaGVhZCgmZG1hYnVmLT5wb2xsKTsKPiAgCWRtYWJ1Zi0+Y2JfZXhj bC5wb2xsID0gZG1hYnVmLT5jYl9zaGFyZWQucG9sbCA9ICZkbWFidWYtPnBvbGw7Cj4gIAlkbWFi dWYtPmNiX2V4Y2wuYWN0aXZlID0gZG1hYnVmLT5jYl9zaGFyZWQuYWN0aXZlID0gMDsKPiBAQCAt NDIyLDcgKzQ4NSw3IEBAIHN0cnVjdCBkbWFfYnVmX2F0dGFjaG1lbnQgKmRtYV9idWZfYXR0YWNo KHN0cnVjdCBkbWFfYnVmICpkbWFidWYsCj4gIAkJCQkJICBzdHJ1Y3QgZGV2aWNlICpkZXYpCj4g IHsKPiAgCXN0cnVjdCBkbWFfYnVmX2F0dGFjaG1lbnQgKmF0dGFjaDsKPiAtCWludCByZXQ7Cj4g KwlpbnQgcmV0ID0gMDsKPiAgCj4gIAlpZiAoV0FSTl9PTighZG1hYnVmIHx8ICFkZXYpKQo+ICAJ CXJldHVybiBFUlJfUFRSKC1FSU5WQUwpOwo+IEBAIC00MzYsNiArNDk5LDkgQEAgc3RydWN0IGRt YV9idWZfYXR0YWNobWVudCAqZG1hX2J1Zl9hdHRhY2goc3RydWN0IGRtYV9idWYgKmRtYWJ1ZiwK PiAgCj4gIAltdXRleF9sb2NrKCZkbWFidWYtPmxvY2spOwo+ICAKPiArCWlmIChjYWxjX2NvbnN0 cmFpbnRzKGRldiwgJmRtYWJ1Zi0+Y29uc3RyYWludHMpKQo+ICsJCWdvdG8gZXJyX2NvbnN0cmFp bnRzOwo+ICsKPiAgCWlmIChkbWFidWYtPm9wcy0+YXR0YWNoKSB7Cj4gIAkJcmV0ID0gZG1hYnVm LT5vcHMtPmF0dGFjaChkbWFidWYsIGRldiwgYXR0YWNoKTsKPiAgCQlpZiAocmV0KQo+IEBAIC00 NDgsNiArNTE0LDcgQEAgc3RydWN0IGRtYV9idWZfYXR0YWNobWVudCAqZG1hX2J1Zl9hdHRhY2go c3RydWN0IGRtYV9idWYgKmRtYWJ1ZiwKPiAgCj4gIGVycl9hdHRhY2g6Cj4gIAlrZnJlZShhdHRh Y2gpOwo+ICtlcnJfY29uc3RyYWludHM6Cj4gIAltdXRleF91bmxvY2soJmRtYWJ1Zi0+bG9jayk7 Cj4gIAlyZXR1cm4gRVJSX1BUUihyZXQpOwo+ICB9Cj4gQEAgLTQ3MCw2ICs1MzcsOCBAQCB2b2lk IGRtYV9idWZfZGV0YWNoKHN0cnVjdCBkbWFfYnVmICpkbWFidWYsIHN0cnVjdCBkbWFfYnVmX2F0 dGFjaG1lbnQgKmF0dGFjaCkKPiAgCWlmIChkbWFidWYtPm9wcy0+ZGV0YWNoKQo+ICAJCWRtYWJ1 Zi0+b3BzLT5kZXRhY2goZG1hYnVmLCBhdHRhY2gpOwo+ICAKPiArCXJlY2FsY19jb25zdHJhaW50 cyhkbWFidWYsICZkbWFidWYtPmNvbnN0cmFpbnRzKTsKPiArCgpUbyBtZSwgdGhpcyB3aG9sZSB0 aGluZyBzZWVtcyBob3JyaWJseSByYWN5LgoKV2hhdCBoYXBwZW5zIGlmIHN1YnN5c3RlbSBYIGNy ZWF0ZXMgYSBkbWFidWYsIHdoaWNoIGlzIHBhc3NlZCB0bwp1c2Vyc3BhY2UuIEl0J3MgdGhlbiBw YXNzZWQgdG8gc3Vic3lzdGVtIFksIHdoaWNoIHN0YXJ0cyBtYWtpbmcgdXNlCm9mIGl0LCBjYWxs aW5nIGRtYV9idWZfbWFwX2F0dGFjaG1lbnQoKSBvbiBpdC4KClRoZSBzYW1lIGJ1ZmZlciBpcyBh bHNvIHBhc3NlZCAodmlhIHVuaXggZG9tYWluIHNvY2tldHMpIHRvIGFub3RoZXIKcHJvZ3JhbSwg d2hpY2ggdGhlbiBwYXNzZXMgaXQgaW5kZXBlbmRlbnRseSBpbnRvIHN1YnN5c3RlbSBaLCBhbmQK c3Vic3lzdGVtIFogaGFzIG1vcmUgcmVzdHJpY3RpdmUgRE1BIGNvbnN0cmFpbnRzLgoKV2hhdCBo YXBwZW5zIGF0IHRoaXMgcG9pbnQ/CgpTdWJzeXN0ZW1zIHN1Y2ggYXMgRFJNIGNhY2hlIHRoZSBz Y2F0dGVyIHRhYmxlLCBhbmQgcmV0dXJuIGl0IGZvcgpzdWJzZXF1ZW50IGF0dGFjaCBjYWxscywg c28gRFJNIGRyaXZlcnMgdXNpbmcgdGhlIGRlZmF1bHQKZHJtX2dlbV9tYXBfZG1hX2J1ZigpIGlt cGxlbWVudGF0aW9uIHdvdWxkIG5vdCBzZWUgdGhlIHJlc3RyaWN0aW9ucwpwbGFjZWQgdXBvbiB0 aGUgZG1hYnVmLiAgTW9yZW92ZXIsIHRoZSByZXR1cm5lZCBzY2F0dGVybGlzdCB3b3VsZCBub3QK YmUgbW9kaWZpZWQgZm9yIHRob3NlIHJlc3RyaWN0aW9ucyBlaXRoZXIuCgpXaGF0IHdvdWxkIG90 aGVyIHN1YnN5c3RlbXMgZG8/CgpUaGlzIG5lZWRzIG1vcmUgdGhvdWdodCBiZWZvcmUgaXQncyBt ZXJnZWQuCgpGb3IgZXhhbXBsZSwgaW4gdGhlIGFib3ZlIHNpdHVhdGlvbiwgc2hvdWxkIHdlIGRl bnkgdGhlIGFiaWxpdHkgdG8KY3JlYXRlIGEgbmV3IGF0dGFjaG1lbnQgd2hlbiBhIGRtYWJ1ZiBo YXMgYWxyZWFkeSBiZWVuIG1hcHBlZCBieSBhbgpleGlzdGluZyBhdHRhY2htZW50PyAgU2hvdWxk IHdlIGRlbnkgaXQgb25seSB3aGVuIHRoZSBuZXcgYXR0YWNobWVudApoYXMgbW9yZSByZXN0cmlj dGl2ZSBETUEgY29uc3RyYWludHM/CgpQbGVhc2UgY29uc2lkZXIgdGhlIHBvc3NpYmxlIHNlcXVl bmNlcyBvZiB1c2UgKHN1Y2ggYXMgdGhlIHNjZW5hcmlvCmFib3ZlKSB3aGVuIGNyZWF0aW5nIG9y IGF1Z21lbnRpbmcgYW4gQVBJLgoKLS0gCkZUVEMgYnJvYWRiYW5kIGZvciAwLjhtaWxlIGxpbmU6 IGN1cnJlbnRseSBhdCAxMC41TWJwcyBkb3duIDQwMGticHMgdXAKYWNjb3JkaW5nIHRvIHNwZWVk dGVzdC5uZXQuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpo dHRwOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg==