search for: blkoff

...nclude "isaligned.h" +#include "minmax.h" #define THREAD_MODEL NBDKIT_THREAD_MODEL_PARALLEL @@ -231,43 +233,68 @@ cache_pread (struct nbdkit_next_ops *next_ops, void *nxdata, uint32_t flags, int *err) { CLEANUP_FREE uint8_t *block = NULL; + uint64_t blknum, blkoffs; + int r; assert (!flags); - block = malloc (blksize); - if (block == NULL) { - *err = errno; - nbdkit_error ("malloc: %m"); - return -1; + if (!IS_ALIGNED (count | offset, blksize)) { + block = malloc (blksize); + if (block == NULL) { + *err = errno; + n...

Based on Rich's review of my v1 that touched only cache.c, I have now tried to bring all three filters with alignment rounding in line with one another. There is definitely room for future improvements once we teach nbdkit to let filters and plugins advertise block sizes, but I'm hoping to get NBD_CMD_CACHE implemented first. Eric Blake (2): blocksize: Process requests in linear order

...ests into smaller ones, which @@ -258,12 +261,14 @@ cache_pread (struct nbdkit_next_ops *next_ops, void *nxdata, { ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&lock); - r = blk_read (next_ops, nxdata, blknum, block, err); + r = blk_read (next_ops, nxdata, blknum, + blkoffs || n < blksize ? block : buf, err); } if (r == -1) return -1; - memcpy (buf, &block[blkoffs], n); + if (blkoffs || n < blksize) + memcpy (buf, &block[blkoffs], n); buf += n; count -= n; @@ -282,11 +287,13 @@ cache_pwrite (struct nbdkit_next_ops...

...k_set_size (size)) + pthread_mutex_lock (&lock); + r = blk_set_size (size); + pthread_mutex_unlock (&lock); + if (r == -1) return -1; return size; @@ -179,6 +189,7 @@ cache_pread (struct nbdkit_next_ops *next_ops, void *nxdata, while (count > 0) { uint64_t blknum, blkoffs, n; + int r; blknum = offset / BLKSIZE; /* block number */ blkoffs = offset % BLKSIZE; /* offset within the block */ @@ -186,7 +197,10 @@ cache_pread (struct nbdkit_next_ops *next_ops, void *nxdata, if (n > count) n = count; - if (blk_read (next_ops, nxdata, blk...

...xdata, { uint8_t *block; - block = malloc (blksize); + block = malloc (BLKSIZE); if (block == NULL) { nbdkit_error ("malloc: %m"); return -1; @@ -275,9 +316,9 @@ cow_pread (struct nbdkit_next_ops *next_ops, void *nxdata, while (count > 0) { uint64_t blknum, blkoffs, n; - blknum = offset / blksize; /* block number */ - blkoffs = offset % blksize; /* offset within the block */ - n = blksize - blkoffs; /* max bytes we can read from this block */ + blknum = offset / BLKSIZE; /* block number */ + blkoffs = offset % BLKSIZE; /* offset withi...

Eric, you'll probably find the design "interesting" ... It does work, for me at least. Rich.

...14 insertions(+), 10 deletions(-) > > diff --git a/lib/handle.c b/lib/handle.c > index 1e122ea..9be3b5f 100644 > --- a/lib/handle.c > +++ b/lib/handle.c > @@ -300,10 +300,15 @@ hivex_open (const char *filename, int flags) > int used; > seg_len = block_len (h, blkoff, &used); > if (seg_len <= 4 || (seg_len & 3) != 0) { > - SET_ERRNO (ENOTSUP, > - "%s: block size %" PRIi32 " at 0x%zx, bad registry", > - filename, le32toh (block->seg_len), blkoff); > - goto e...

Hello, The following patches address issues when dealing with hives that have corrupted data in them but are otherwise readable/writable. Those were found on some rather rare Windows installations that seem to work fine but current hivex fails to even open. Those patches change hivex to simply log and ignore such "corrupted" regions instead of aborting because the caller might be

The following patches address issues when dealing with hives that have corrupted data in them but are otherwise readable/writable. Those were found on some rather rare Windows installations that seem to work fine but current hivex fails to even open. Those patches change hivex to simply log and ignore such "corrupted" regions instead of aborting because the caller might be looking at

The following patches address issues when dealing with hives that have corrupted data in them but are otherwise readable/writable. Those were found on some rather rare Windows installations that seem to work fine but current hivex fails to even open. Those patches change hivex to simply log and ignore such "corrupted" regions instead of aborting because the caller might be looking at

...e.c | 11 +++++------ 2 files changed, 14 insertions(+), 10 deletions(-) diff --git a/lib/handle.c b/lib/handle.c index 1e122ea..9be3b5f 100644 --- a/lib/handle.c +++ b/lib/handle.c @@ -300,10 +300,15 @@ hivex_open (const char *filename, int flags) int used; seg_len = block_len (h, blkoff, &used); if (seg_len <= 4 || (seg_len & 3) != 0) { - SET_ERRNO (ENOTSUP, - "%s: block size %" PRIi32 " at 0x%zx, bad registry", - filename, le32toh (block->seg_len), blkoff); - goto error; + if (is_roo...

...@@ -258,12 +261,14 @@ cache_pread (struct nbdkit_next_ops *next_ops, void *nxdata, > > { > ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&lock); > - r = blk_read (next_ops, nxdata, blknum, block, err); > + r = blk_read (next_ops, nxdata, blknum, > + blkoffs || n < blksize ? block : buf, err); > } > if (r == -1) > return -1; > > - memcpy (buf, &block[blkoffs], n); > + if (blkoffs || n < blksize) > + memcpy (buf, &block[blkoffs], n); I've stared at this patch for a while and I don'...

...d *nxdata, uint8_t *block; assert (!flags); - block = malloc (BLKSIZE); + block = malloc (blksize); if (block == NULL) { *err = errno; nbdkit_error ("malloc: %m"); @@ -187,9 +253,9 @@ cache_pread (struct nbdkit_next_ops *next_ops, void *nxdata, uint64_t blknum, blkoffs, n; int r; - blknum = offset / BLKSIZE; /* block number */ - blkoffs = offset % BLKSIZE; /* offset within the block */ - n = BLKSIZE - blkoffs; /* max bytes we can read from this block */ + blknum = offset / blksize; /* block number */ + blkoffs = offset % blksize; /*...

...-1) { + nbdkit_error ("pwrite: %m"); + return -1; + } + return 0; +} + +/* Read data. */ +static int +cow_pread (struct nbdkit_next_ops *next_ops, void *nxdata, + void *handle, void *buf, uint32_t count, uint64_t offset) +{ + while (count > 0) { + uint64_t blknum, blkoffs, n; + + blknum = offset / blksize; /* block number */ + blkoffs = offset % blksize; /* offset within the block */ + n = blksize - blkoffs; /* max bytes we can read from this block */ + if (n > count) + n = count; + + if (blk_read (next_ops, nxdata, blknum) == -1) +...

This adds a cache filter, which works like the COW filter in reverse. For realistic use it needs a bit more work, especially to add limits on the size of the cache, a more sensible cache replacement policy, and perhaps some kind of background worker to write dirty blocks out. Rich.

The following patches address issues when dealing with hives that have corrupted data in them but are otherwise readable/writable. Those were found on some rather rare Windows installations that seem to work fine but current hivex fails to even open. Those patches change hivex to simply log and ignore such "corrupted" regions instead of aborting because the caller might be looking at

v4: https://www.redhat.com/archives/libguestfs/2019-January/msg00032.html v5: - Now we set the block size at run time. I'd like to say that I was able to test this change, but unfortunately I couldn't find any easy way to create a filesystem on x86-64 with a block size > 4K. Ext4 doesn't support it at all, and XFS doesn't support block size > page size (and I

...a read-modify-write operation on the current block. * Hold the lock over the whole operation. */ - pthread_mutex_lock (&lock); + ACQUIRE_LOCK_FOR_CURRENT_SCOPE (&lock); r = blk_read (next_ops, nxdata, blknum, block, err); if (r != -1) { memcpy (&block[blkoffs], buf, n); r = blk_write (next_ops, nxdata, blknum, block, flags, err); } - pthread_mutex_unlock (&lock); if (r == -1) return -1; @@ -371,13 +370,12 @@ cache_zero (struct nbdkit_next_ops *next_ops, void *nxdata, /* Do a read-modify-write operation on the curren...

Hi Rich, There's an unchecked calloc in hivex.c's hive_open: h->bitmap = calloc (1 + h->size / 32, 1); ... This subsequent deref could cause a segfault: BITMAP_SET (h->bitmap, blkoff);

This is, hopefully, a full fix for handling of li-records. See: https://bugzilla.redhat.com/show_bug.cgi?id=717583 https://bugzilla.redhat.com/show_bug.cgi?id=987463 Rich.