qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] system/physmem: Where we assume we have a RAM MR, assert it
@ 2024-07-23 17:05 Peter Maydell
  2024-07-23 17:40 ` Peter Xu
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Peter Maydell @ 2024-07-23 17:05 UTC (permalink / raw)
  To: qemu-devel
  Cc: Paolo Bonzini, Peter Xu, David Hildenbrand,
	Philippe Mathieu-Daudé

In the functions invalidate_and_set_dirty() and
cpu_physical_memory_snapshot_and_clear_dirty(), we assume that we
are dealing with RAM memory regions. In this case we know that
memory_region_get_ram_addr() will succeed. Assert this before we
use the returned ram_addr_t in arithmetic.

This makes Coverity happier about these functions: it otherwise
complains that we might have an arithmetic overflow that stems
from the possible -1 return from memory_region_get_ram_addr().

Resolves: Coverity CID 1547629, 1547715

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 system/physmem.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/system/physmem.c b/system/physmem.c
index 9a3b3a76360..87554d68ea4 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -894,13 +894,19 @@ DirtyBitmapSnapshot *cpu_physical_memory_snapshot_and_clear_dirty
     (MemoryRegion *mr, hwaddr offset, hwaddr length, unsigned client)
 {
     DirtyMemoryBlocks *blocks;
-    ram_addr_t start = memory_region_get_ram_addr(mr) + offset;
+    ram_addr_t start, first, last;
     unsigned long align = 1UL << (TARGET_PAGE_BITS + BITS_PER_LEVEL);
-    ram_addr_t first = QEMU_ALIGN_DOWN(start, align);
-    ram_addr_t last  = QEMU_ALIGN_UP(start + length, align);
     DirtyBitmapSnapshot *snap;
     unsigned long page, end, dest;
 
+    start = memory_region_get_ram_addr(mr);
+    /* We know we're only called for RAM MemoryRegions */
+    assert(start != RAM_ADDR_INVALID);
+    start += offset;
+
+    first = QEMU_ALIGN_DOWN(start, align);
+    last  = QEMU_ALIGN_UP(start + length, align);
+
     snap = g_malloc0(sizeof(*snap) +
                      ((last - first) >> (TARGET_PAGE_BITS + 3)));
     snap->start = first;
@@ -2630,7 +2636,11 @@ static void invalidate_and_set_dirty(MemoryRegion *mr, hwaddr addr,
                                      hwaddr length)
 {
     uint8_t dirty_log_mask = memory_region_get_dirty_log_mask(mr);
-    addr += memory_region_get_ram_addr(mr);
+    ram_addr_t ramaddr = memory_region_get_ram_addr(mr);
+
+    /* We know we're only called for RAM MemoryRegions */
+    assert(ramaddr != RAM_ADDR_INVALID);
+    addr += ramaddr;
 
     /* No early return if dirty_log_mask is or becomes 0, because
      * cpu_physical_memory_set_dirty_range will still call
-- 
2.34.1



^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] system/physmem: Where we assume we have a RAM MR, assert it
  2024-07-23 17:05 [PATCH] system/physmem: Where we assume we have a RAM MR, assert it Peter Maydell
@ 2024-07-23 17:40 ` Peter Xu
  2024-07-23 18:33 ` David Hildenbrand
  2024-07-29 16:04 ` Peter Maydell
  2 siblings, 0 replies; 4+ messages in thread
From: Peter Xu @ 2024-07-23 17:40 UTC (permalink / raw)
  To: Peter Maydell
  Cc: qemu-devel, Paolo Bonzini, David Hildenbrand,
	Philippe Mathieu-Daudé

On Tue, Jul 23, 2024 at 06:05:13PM +0100, Peter Maydell wrote:
> In the functions invalidate_and_set_dirty() and
> cpu_physical_memory_snapshot_and_clear_dirty(), we assume that we
> are dealing with RAM memory regions. In this case we know that
> memory_region_get_ram_addr() will succeed. Assert this before we
> use the returned ram_addr_t in arithmetic.
> 
> This makes Coverity happier about these functions: it otherwise
> complains that we might have an arithmetic overflow that stems
> from the possible -1 return from memory_region_get_ram_addr().
> 
> Resolves: Coverity CID 1547629, 1547715
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Reviewed-by: Peter Xu <peterx@redhat.com>

-- 
Peter Xu



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] system/physmem: Where we assume we have a RAM MR, assert it
  2024-07-23 17:05 [PATCH] system/physmem: Where we assume we have a RAM MR, assert it Peter Maydell
  2024-07-23 17:40 ` Peter Xu
@ 2024-07-23 18:33 ` David Hildenbrand
  2024-07-29 16:04 ` Peter Maydell
  2 siblings, 0 replies; 4+ messages in thread
From: David Hildenbrand @ 2024-07-23 18:33 UTC (permalink / raw)
  To: Peter Maydell, qemu-devel
  Cc: Paolo Bonzini, Peter Xu, Philippe Mathieu-Daudé

On 23.07.24 19:05, Peter Maydell wrote:
> In the functions invalidate_and_set_dirty() and
> cpu_physical_memory_snapshot_and_clear_dirty(), we assume that we
> are dealing with RAM memory regions. In this case we know that
> memory_region_get_ram_addr() will succeed. Assert this before we
> use the returned ram_addr_t in arithmetic.
> 
> This makes Coverity happier about these functions: it otherwise
> complains that we might have an arithmetic overflow that stems
> from the possible -1 return from memory_region_get_ram_addr().
> 
> Resolves: Coverity CID 1547629, 1547715
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
Reviewed-by: David Hildenbrand <david@redhat.com>

-- 
Cheers,

David / dhildenb



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] system/physmem: Where we assume we have a RAM MR, assert it
  2024-07-23 17:05 [PATCH] system/physmem: Where we assume we have a RAM MR, assert it Peter Maydell
  2024-07-23 17:40 ` Peter Xu
  2024-07-23 18:33 ` David Hildenbrand
@ 2024-07-29 16:04 ` Peter Maydell
  2 siblings, 0 replies; 4+ messages in thread
From: Peter Maydell @ 2024-07-29 16:04 UTC (permalink / raw)
  To: qemu-devel
  Cc: Paolo Bonzini, Peter Xu, David Hildenbrand,
	Philippe Mathieu-Daudé

On Tue, 23 Jul 2024 at 18:05, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> In the functions invalidate_and_set_dirty() and
> cpu_physical_memory_snapshot_and_clear_dirty(), we assume that we
> are dealing with RAM memory regions. In this case we know that
> memory_region_get_ram_addr() will succeed. Assert this before we
> use the returned ram_addr_t in arithmetic.
>
> This makes Coverity happier about these functions: it otherwise
> complains that we might have an arithmetic overflow that stems
> from the possible -1 return from memory_region_get_ram_addr().
>
> Resolves: Coverity CID 1547629, 1547715
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> --

I'm doing a target-arm pullreq so I'll take this patch
through that, unless you'd prefer otherwise.

thanks
-- PMM


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2024-07-29 16:05 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-07-23 17:05 [PATCH] system/physmem: Where we assume we have a RAM MR, assert it Peter Maydell
2024-07-23 17:40 ` Peter Xu
2024-07-23 18:33 ` David Hildenbrand
2024-07-29 16:04 ` Peter Maydell

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).