From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A89EDA0A02 for ; Thu, 25 Mar 2021 17:46:20 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8AB02140D47; Thu, 25 Mar 2021 17:46:20 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id 3D04C140D47 for ; Thu, 25 Mar 2021 17:46:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616690778; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=retwiY/eTsaJJS/UhUEFVoT+aMzikWLoz5L9byNikPU=; b=NekvYXSDsWbJhs5tz0yOf5lKV+LiJl9gmgHrdVG8KmxeX8j9BV+S5Yo1R+U/+tcrtIDYHF 1vmW1M606YOX8VJveRwVjK+XOImxBF5mCmj9G8WqdxHanaeyMJkM3rX3FTIWCI96dCs4g3 6AAY6XZZjVY0toTnSJtKZ0Q3SlEtDCc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-537-QIXUmFi6Owm77Y7LLeoXQA-1; Thu, 25 Mar 2021 12:46:15 -0400 X-MC-Unique: QIXUmFi6Owm77Y7LLeoXQA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6B7A910C7C14; Thu, 25 Mar 2021 16:46:02 +0000 (UTC) Received: from [10.36.115.70] (ovpn-115-70.ams2.redhat.com [10.36.115.70]) by smtp.corp.redhat.com (Postfix) with ESMTP id 782EB1037E83; Thu, 25 Mar 2021 16:45:28 +0000 (UTC) To: Thomas Monjalon , Yunjian Wang Cc: dev@dpdk.org, david.marchand@redhat.com, anatoly.burakov@intel.com, jerry.lilijun@huawei.com, xudingke@huawei.com, stable@dpdk.org, bruce.richardson@intel.com, john.mcnamara@intel.com References: <1602840525-8848-1-git-send-email-wangyunjian@huawei.com> <1607339329-624-1-git-send-email-wangyunjian@huawei.com> <5596810.E6CI0FCbXo@thomas> From: Kevin Traynor Message-ID: <4232fbc1-dcbf-784c-8bc8-c7caafbc7fe8@redhat.com> Date: Thu, 25 Mar 2021 16:45:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <5596810.E6CI0FCbXo@thomas> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=ktraynor@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v4] eal: fix create user mem map repeatedly when it exists X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On 25/03/2021 14:30, Thomas Monjalon wrote: > 07/12/2020 12:08, wangyunjian: >> From: Yunjian Wang >> >> Currently, user mem maps will check if the newly mapped area is adjacent >> to any existing mapping, but will not check if the mapping is identical >> because it assumes that the API will never get called with the same >> mapping twice. This will result in duplicate entries in the user mem >> maps list. >> >> Fix it by also checking for duplicate mappings, and skipping them if >> they are found. > > Sorry, that's still difficult to read, > and it is not clear what is the impact of the bug. > I agree the impact of the bug is not clear from the description. It seems to be explained at a low level in http://inbox.dpdk.org/dev/34EFBCA9F01B0748BEB6B629CE643AE60DB32BD6@DGGEMM533-MBX.china.huawei.com/ that the array size is 256 (VFIO_MAX_USER_MEM_MAPS) and it may fill up due to duplicate mem maps. How about something like: -- New user mem maps are checked if they are adjacent to an existing mem map and if so, the mem map entries are merged. It did not check for duplicate mem maps, so if the API is called with the same mem map multiple times, they will occupy multiple mem map entries. This will reduce the amount of entries available for unique mem maps. Check for duplicate mem maps and merge them into one mem map entry if any found. -- You might want to add something about the possible impact for applications that is being fixed here too. > +Cc some english native speakers for help. (Probably the worst people to ask) > >> Fixes: 0cbce3a167f1 ("vfio: skip DMA map failure if already mapped") >> Cc: stable@dpdk.org >> >> Signed-off-by: Yunjian Wang >> Acked-by: Anatoly Burakov > > >