patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Kevin Traynor <ktraynor@redhat.com>
To: Thomas Monjalon <thomas@monjalon.net>,
	Yunjian Wang <wangyunjian@huawei.com>
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
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v4] eal: fix create user mem map repeatedly when it exists
Date: Thu, 25 Mar 2021 16:45:27 +0000	[thread overview]
Message-ID: <4232fbc1-dcbf-784c-8bc8-c7caafbc7fe8@redhat.com> (raw)
In-Reply-To: <5596810.E6CI0FCbXo@thomas>

On 25/03/2021 14:30, Thomas Monjalon wrote:
> 07/12/2020 12:08, wangyunjian:
>> From: Yunjian Wang <wangyunjian@huawei.com>
>>
>> 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 <wangyunjian@huawei.com>
>> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
> 
> 
> 


  reply	other threads:[~2021-03-25 16:46 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-16 13:38 [dpdk-stable] [PATCH 1/1] eal/linux: do not " wangyunjian
2020-07-17 14:19 ` [dpdk-stable] [dpdk-dev] " Burakov, Anatoly
2020-07-17 14:23   ` Burakov, Anatoly
2020-07-20  2:00     ` wangyunjian
2020-07-20 11:46       ` Burakov, Anatoly
2020-07-22 12:47         ` wangyunjian
2020-07-23 14:48 ` [dpdk-stable] [dpdk-dev] [PATCH v2] " wangyunjian
2020-07-24 13:25   ` Burakov, Anatoly
2020-07-25  9:59     ` wangyunjian
2020-07-27  9:24       ` Burakov, Anatoly
2020-07-30 13:16         ` wangyunjian
2020-07-31 11:55           ` Burakov, Anatoly
2020-08-05 12:58             ` wangyunjian
2020-09-17 11:33               ` Burakov, Anatoly
2020-09-17 11:35   ` Burakov, Anatoly
2020-10-15 12:46     ` wangyunjian
2020-10-15 12:54       ` David Marchand
2020-10-16  9:48         ` wangyunjian
2020-10-16  9:28   ` [dpdk-stable] [dpdk-dev] [PATCH v3] eal: fix " wangyunjian
2020-10-20 14:09     ` Thomas Monjalon
2020-11-15 14:23       ` Thomas Monjalon
2020-11-22 18:20         ` Thomas Monjalon
2020-11-23  7:40           ` wangyunjian
2020-11-27 12:54       ` Burakov, Anatoly
2020-12-07 11:08     ` [dpdk-stable] [dpdk-dev] [PATCH v4] " wangyunjian
2021-03-25 13:38       ` wangyunjian
2021-03-25 14:30       ` Thomas Monjalon
2021-03-25 16:45         ` Kevin Traynor [this message]
2021-04-10  9:37     ` [dpdk-stable] [dpdk-dev] [PATCH v5] " wangyunjian
2021-04-19 11:47       ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4232fbc1-dcbf-784c-8bc8-c7caafbc7fe8@redhat.com \
    --to=ktraynor@redhat.com \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=jerry.lilijun@huawei.com \
    --cc=john.mcnamara@intel.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    --cc=wangyunjian@huawei.com \
    --cc=xudingke@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).