On 29.07.25 21:25, Andrew Cooper wrote:
On 29/07/2025 8:21 pm, Andrew Cooper wrote:
On 29/07/2025 12:01 pm, Juergen Gross wrote:
diff --git a/tools/xenstored/lu.c b/tools/xenstored/lu.c
index 77e0d377c5..f2c8b92d07 100644
--- a/tools/xenstored/lu.c
+++ b/tools/xenstored/lu.c
@@ -27,9 +27,11 @@ struct live_update *lu_status;
struct lu_dump_state {
        void *buf;
+       unsigned int buf_size;
        unsigned int size;
-       int fd;
+       unsigned int offset;
        char *filename;
+       FILE *fp;
I know there's already one unsigned int size here, but life is too short
to not use size_t from the get-go.

That said, offset really needs to be an offs64_t if you want 32bit
guests to 9P safely on a modern filesystem.

For 32bit guests I don't see a problem here, as this would mean the Xenstore
state would exceed 4GB, which seems unlikely using an in-memory data base in
a system supporting less than 2GB of memory (the Mini-OS limit for 32bit is
1GB, while a 32bit daemon can use max. 2GB of virtual memory).

Using unsigned int is a potential problem in 64bit mode, though. So switching
to size_t for size and off64_t for offset seems sensible.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to