All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Ric Li <ming3.li@intel.com>
Cc: dmitry.kozliuk@gmail.com, dev@dpdk.org,
	roretzla@linux.microsoft.com,
	Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Subject: Re: [PATCH v4] windows/virt2phys: fix block MDL not updated
Date: Tue, 15 Oct 2024 16:04:46 -0700	[thread overview]
Message-ID: <20241015160446.1928c2df@hermes.local> (raw)
In-Reply-To: <20231204103214.2504017-1-ming3.li@intel.com>

On Mon,  4 Dec 2023 18:32:14 +0800
Ric Li <ming3.li@intel.com> wrote:

> The virt2phys_translate function previously scanned existing blocks,
> returning the physical address from the stored MDL info if present.
> This method was problematic when a virtual address pointed to a freed
> and reallocated memory segment, potentially changing the physical
> address mapping. Yet, virt2phys_translate would consistently return
> the originally stored physical address, which could be invalid.
> 
> This issue surfaced when allocating a memory region larger than 2MB
> using rte_malloc. This action would allocate a new memory segment
> and use virt2phy to set the IOVA. The driver would store the MDL
> and lock the pages initially. When this region was freed, the memory
> segment used as a whole page could be freed, invalidating the virtual
> to physical mapping. Before this fix, the driver would only return the
> initial physical address, leading to illegal IOVA for some pages when
> allocating a new memory region larger than the hugepage size (2MB).
> 
> To address this, a function to check block physical address has been
> added. If a block with the same base address is detected in the
> driver's context, the MDL's physical address is compared with the real
> physical address. If they don't match, the block is removed and a new
> one is created to store the correct mapping. To make the removal action
> clear, the list to store MDL blocks is changed to a double linked list.
> 
> Also fix the printing of PVOID type.
> 
> Bugzilla ID: 1201
> Bugzilla ID: 1213
> 
> Signed-off-by: Ric Li <ming3.li@intel.com>

This looks ok, but I know nothing about windows drivers.
Could we get a review by Dmitry?

  reply	other threads:[~2024-10-15 23:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-11  8:22 [PATCH] windows/virt2phys: fix block MDL not updated Ric Li
2023-09-11 13:09 ` [PATCH v2] " Ric Li
2023-09-11 21:50   ` Dmitry Kozlyuk
2023-09-12 11:13     ` Li, Ming3
2023-09-12 11:17       ` [PATCH v3] " Ric Li
2023-11-27  1:31         ` Li, Ming3
2023-11-30  4:10         ` Dmitry Kozlyuk
2023-12-04 10:22           ` [PATCH v4] " Ric Li
2023-12-04 10:32           ` Ric Li
2024-10-15 23:04             ` Stephen Hemminger [this message]
2024-10-16  6:32               ` Dmitry Kozlyuk
2024-11-20 12:03                 ` Thomas Monjalon
2023-09-12 12:18       ` [PATCH v2] " Dmitry Kozlyuk

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=20241015160446.1928c2df@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=ming3.li@intel.com \
    --cc=roretzla@linux.microsoft.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.