system/physmem.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-)
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
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
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
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
© 2016 - 2024 Red Hat, Inc.