From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: dmaengine: avoid map_cnt overflow with CONFIG_DMA_ENGINE_RAID From: Vinod Koul Message-Id: <20180112165648.GP18649@localhost> Date: Fri, 12 Jan 2018 22:26:48 +0530 To: Zi Yan , Dan Williams Cc: dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, Zi Yan List-ID: T24gTW9uLCBKYW4gMDgsIDIwMTggYXQgMTA6NTA6NTBBTSAtMDUwMCwgWmkgWWFuIHdyb3RlOgo+ IEZyb206IFppIFlhbiA8emkueWFuQGNzLnJ1dGdlcnMuZWR1Pgo+IAo+IFdoZW4gQ09ORklHX0RN QV9FTkdJTkVfUkFJRCBpcyBlbmFibGVkLCB1bm1hcCBwb29sIHNpemUgY2FuIHJlYWNoIHRvCj4g MjU2LiBCdXQgaW4gc3RydWN0IGRtYWVuZ2luZV91bm1hcF9kYXRhLCBtYXBfY250IGlzIG9ubHkg dTgsIHdyYXBwaW5nCj4gdG8gMCwgaWYgdGhlIHVubWFwIHBvb2wgaXMgbWF4aW1hbGx5IHVzZWQu IFRoaXMgdHJpZ2dlcnMgQlVHKCkgd2hlbgo+IHN0cnVjdCBkbWFlbmdpbmVfdW5tYXBfZGF0YSBp cyBmcmVlZC4gVXNlIHUxNiB0byBmaXggdGhlIHByb2JsZW0uCj4gCj4gU2lnbmVkLW9mZi1ieTog WmkgWWFuIDx6aS55YW5AY3MucnV0Z2Vycy5lZHU+Cj4gLS0tCj4gIGluY2x1ZGUvbGludXgvZG1h ZW5naW5lLmggfCA0ICsrKysKPiAgMSBmaWxlIGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygrKQo+IAo+ IGRpZmYgLS1naXQgYS9pbmNsdWRlL2xpbnV4L2RtYWVuZ2luZS5oIGIvaW5jbHVkZS9saW51eC9k bWFlbmdpbmUuaAo+IGluZGV4IGY4Mzg3NjQ5OTNlYi4uODYxYmU1Y2FiMWRmIDEwMDY0NAo+IC0t LSBhL2luY2x1ZGUvbGludXgvZG1hZW5naW5lLmgKPiArKysgYi9pbmNsdWRlL2xpbnV4L2RtYWVu Z2luZS5oCj4gQEAgLTQ3MCw3ICs0NzAsMTEgQEAgdHlwZWRlZiB2b2lkICgqZG1hX2FzeW5jX3R4 X2NhbGxiYWNrX3Jlc3VsdCkodm9pZCAqZG1hX2FzeW5jX3BhcmFtLAo+ICAJCQkJY29uc3Qgc3Ry dWN0IGRtYWVuZ2luZV9yZXN1bHQgKnJlc3VsdCk7Cj4gIAo+ICBzdHJ1Y3QgZG1hZW5naW5lX3Vu bWFwX2RhdGEgewo+ICsjaWYgSVNfRU5BQkxFRChDT05GSUdfRE1BX0VOR0lORV9SQUlEKQo+ICsJ dTE2IG1hcF9jbnQ7Cj4gKyNlbHNlCj4gIAl1OCBtYXBfY250Owo+ICsjZW5kaWYKPiAgCXU4IHRv X2NudDsKPiAgCXU4IGZyb21fY250Owo+ICAJdTggYmlkaV9jbnQ7CgpXb3VsZCB0aGF0IGNhdXNl IGFkdmVyc2UgcGVyZm9ybWFuY2UsIHRoZSBkYXRhIHN0cnVjdHVyZSBpcyBub3QgYWxpZ25lZAph bnltb3JlLiBEYW4gd2FzIHRoYXQgYSBjb25zaWRlcmF0aW9uIHdoaWxlIGFkZGluZyB0aGlzPwo= From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965001AbeALQwe (ORCPT + 1 other); Fri, 12 Jan 2018 11:52:34 -0500 Received: from mga09.intel.com ([134.134.136.24]:16511 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964832AbeALQwd (ORCPT ); Fri, 12 Jan 2018 11:52:33 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,349,1511856000"; d="scan'208";a="20493723" Date: Fri, 12 Jan 2018 22:26:48 +0530 From: Vinod Koul To: Zi Yan , Dan Williams Cc: dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, Zi Yan Subject: Re: [PATCH] dmaengine: avoid map_cnt overflow with CONFIG_DMA_ENGINE_RAID Message-ID: <20180112165648.GP18649@localhost> References: <20180108155050.7387-1-zi.yan@sent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180108155050.7387-1-zi.yan@sent.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Mon, Jan 08, 2018 at 10:50:50AM -0500, Zi Yan wrote: > From: Zi Yan > > When CONFIG_DMA_ENGINE_RAID is enabled, unmap pool size can reach to > 256. But in struct dmaengine_unmap_data, map_cnt is only u8, wrapping > to 0, if the unmap pool is maximally used. This triggers BUG() when > struct dmaengine_unmap_data is freed. Use u16 to fix the problem. > > Signed-off-by: Zi Yan > --- > include/linux/dmaengine.h | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h > index f838764993eb..861be5cab1df 100644 > --- a/include/linux/dmaengine.h > +++ b/include/linux/dmaengine.h > @@ -470,7 +470,11 @@ typedef void (*dma_async_tx_callback_result)(void *dma_async_param, > const struct dmaengine_result *result); > > struct dmaengine_unmap_data { > +#if IS_ENABLED(CONFIG_DMA_ENGINE_RAID) > + u16 map_cnt; > +#else > u8 map_cnt; > +#endif > u8 to_cnt; > u8 from_cnt; > u8 bidi_cnt; Would that cause adverse performance, the data structure is not aligned anymore. Dan was that a consideration while adding this? -- ~Vinod