search for: block_count

...-451,6 +451,10 @@ static int zero_dev_start(int fd) start = 1024; len -= 1024; #endif + + if (dev_size < len) + return -EIO; + return zero_blocks(fd, start, len); } @@ -572,7 +576,7 @@ int btrfs_prepare_device(int fd, char *file, int zero_end, u64 *block_count_ret, discard_blocks(fd, 0, block_count); } - ret = zero_dev_start(fd); + ret = zero_dev_start(fd, block_count); if (ret) { fprintf(stderr, "failed to zero device start %d\n", ret); exit(1); -- 1.7.7.6 -- To unsu...

...(full_input, skip); > cur_block_offset += skip; > > - if (cur_block->input->eof) { > + if (i_stream_read_eof(cur_block->input)) { > /* go to the next block */ > if (++block_idx == block_count) { > i_assert(i_stream_read_eof(full_input)); Actually, that breaks things. This one should be ok: diff --git a/src/lib-storage/index/index-mail-binary.c b/src/lib-storage/index/index-mail-binary.c index 2577f1afe5..80c319e050 100644 --- a/src/lib-storage/index/...

...i_stream_skip(full_input, skip); cur_block_offset += skip; - if (cur_block->input->eof) { + if (i_stream_read_eof(cur_block->input)) { /* go to the next block */ if (++block_idx == block_count) { i_assert(i_stream_read_eof(full_input)); -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20201110/a5dd5a05/attachment.html>

Hi, I would like to report an issue which is 100% reproducible with a specific mail available in the reproducer attached to Red Hat's bugzilla <https://bugzilla.redhat.com/show_bug.cgi?id=1894418> (https://bugzilla.redhat.com/attachment.cgi?id=1726535): -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Return-Path: <XXXXXXXXX at

...index c5b4281..7d0864e 100644 --- a/utils/isohybrid.c +++ b/utils/isohybrid.c @@ -842,7 +842,7 @@ initialise_apm(uint8_t *gpt, uint32_t start) part->signature = bendian_short(0x504d); part->map_count = bendian_int(apm_parts); part->start_block = bendian_int(1); - part->block_count = bendian_int(0x10); + part->block_count = bendian_int(4); strcpy(part->name, "Apple"); strcpy(part->type, "Apple_partition_map"); part->data_start = bendian_int(0); @@ -854,11 +854,11 @@ initialise_apm(uint8_t *gpt, uint32_t start) part->si...

...he number of extra frames >> + * processed in the request. >> + */ >> +static int vrpmb_handle_write(VuDev *dev, struct virtio_rpmb_frame *frame) >> +{ >> + VuRpmb *r = container_of(dev, VuRpmb, dev.parent); >> + int extra_frames = 0; >> + uint16_t block_count = be16toh(frame->block_count); >> + uint32_t write_counter = be32toh(frame->write_counter); >> + size_t offset; >> + >> + r->last_reqresp = VIRTIO_RPMB_RESP_DATA_WRITE; >> + r->last_address = be16toh(frame->address); >> + offset = r...

Hi, following will be 6 patch proposals for isohybrid.c 1: Encode GPT partition names as UTF-16LE 2: Correct blocking factor in APM partition block counts 3: Correct end block address of first GPT partition 4: Write GPT backup to the very end of the image 5: Change all fseek(3) to fseeko(3) 6: Introduce option --mbr and make isohybrid.c compilable standalone If the form needs adjustments,

...- The block counts in the Apple partitions obviously assume 512 bytes per block, whereas the start block numbers obviously assume 2048 as announced in the APM header. In initialise_apm() i see two occasions where block counts are handled: - This should probably be 4 rather than 0x10: part->block_count = bendian_int(0x10); - These _count variables should probably be divided by 4 before being submitted to bendian_int(): part->block_count = bendian_int(efi_count); part->data_count = bendian_int(efi_count); part->block_count = bendian_int(mac_count); part->data_count =...

...ct apple_part_header { + uint16_t signature; /* expected to be MAC_PARTITION_MAGIC */ + uint16_t res1; + uint32_t map_count; /* # blocks in partition map */ + uint32_t start_block; /* absolute starting block # of partition */ + uint32_t block_count; /* number of blocks in partition */ + char name[32]; /* partition name */ + char type[32]; /* string type description */ + uint32_t data_start; /* rel block # of first data block */ + uint32_t data_count; /* number of data bloc...

...ound a email that my web server send with only one character "=" in the body of the email and it generate a log error in Dovecot log like this: Oct 23 13:16:50 dovecot_2.2.32 dovecot: imap(user at domain): Panic: file index-mail-binary.c: line 358 (blocks_count_lines): assertion failed: (block_count == 0 || block_idx+1 == block_count) Oct 23 13:16:50 dovecot_2.2.32 dovecot: imap(user at domain): Error: Raw backtrace: /usr/local/lib/dovecot/libdovecot.so.0(+0x9a340) [0x7fc22c186340] -> /usr/local/lib/dovecot/libdovecot.so.0(+0x9a41e) [0x7fc22c18641e] -> /usr/local/lib/dovecot/libdovecot.s...

i have a system with panics/crashes and seem to be able to trigger the problem. dovecot version: 2.2.33.2 (from ius rpm-package-repository) maillog: Dec 14 10:55:00 vimap01 dovecot: imap(XXX): Panic: file index-mail-binary.c: line 358 (blocks_count_lines): assertion failed: (block_count == 0 || block_idx+1 == block_count) Dec 14 10:55:00 vimap01 dovecot: imap(XXX): Error: Raw backtrace: /usr/lib64/dovecot/libdovecot.so.0(+0x9f3de) [0x7fa6768ef3de] -> /usr/lib64/dovecot/libdovecot.so.0(+0x9f4be) [0x7fa6768ef4be] -> /usr/lib64/dovecot/libdovecot.so.0(i_fatal+0) [0x7fa67688077c...

...Block0 of an APM is: Byte Range | Value | Meaning (all numbers are stored big endian) ---------- | ---------- | ---------------------------------------------------- 0 - 1 | sig | Signature 0x45 = 'E' , 0x52 = 'R' 2 - 3 | block_size | 0x0800 = 2048 4 - 7 | block_count| Number of blocks covered by APM | | Often some x86-harmless dummy. E.g. 0x9090 = 37008 | | or 0xeb02ffff = 3,942,842,367 8 - 9 | dev_type | obscure: "device type" 10 - 11 | dev_id | obscure: "device id" 12 - 15 | drv_...

Hi, This is an initial implementation of a vhost-user backend for the VirtIO RPMB device. The device is currently in the draft of the next VirtIO specification and describes block device which uses combination of a key, nonce, hashing and a persistent write counter to prevent replay attacks (hence Replay Protected Memory Block). It is implemented as a vhost-user device because we want to

...; Byte Range | Value | Meaning (all numbers are stored big endian) > ---------- | ---------- | ---------------------------------------------------- > 0 - 1 | sig | Signature 0x45 = 'E' , 0x52 = 'R' > 2 - 3 | block_size | 0x0800 = 2048 > 4 - 7 | block_count| Number of blocks covered by APM > | | Often some x86-harmless dummy. E.g. 0x9090 = 37008 > | | or 0xeb02ffff = 3,942,842,367 > 8 - 9 | dev_type | obscure: "device type" > 10 - 11 | dev_id | obscure: "device id&quo...

Hi, Gene Cumm wrote: > it seems the stack format got > set, changed, then mostly reverted back, with this code being the last > piece missing from 2009. The commit to isohdpfx.S of 2009-05-31 looks incomplete. The sequence of the stack pointers was swapped, but the sequence of stack pushes was not.

Hi, The problem we're trying to address: PGO transforms that are based on block counts need some way to answer isHotBlock() query. A simple comparison of the form block_count > N, for some constant N is not useful since even for the same program different profile inputs can cause different answers for isHotBlock() on the same block. This can be addressed by comparing against a reference value that depends on the program and its input. For instance, the indexed profil...

...xl at google.com> > Subject: [llvm-dev] RFC: Hotness thresholds in profile header > > > > Hi, > > The problem we're trying to address: > > PGO transforms that are based on block counts need some way to answer > isHotBlock() query. A simple comparison of the form block_count > N, for > some constant N is not useful since even for the same program different > profile inputs can cause different answers for isHotBlock() on the same > block. This can be addressed by comparing against a reference value that > depends on the program and its input. For instance...

...llvm-dev] RFC: Hotness thresholds in profile header >> >> >> >> Hi, >> >> The problem we're trying to address: >> >> PGO transforms that are based on block counts need some way to answer >> isHotBlock() query. A simple comparison of the form block_count > N, >> for some constant N is not useful since even for the same program >> different profile inputs can cause different answers for isHotBlock() >> on the same block. This can be addressed by comparing against a >> reference value that depends on the program and its inp...

...2 log_blocksize; /* log2 block size in bytes */ + __le32 log_blocks_per_seg; /* log2 # of blocks per segment */ + __le32 segs_per_sec; /* # of segments per section */ + __le32 secs_per_zone; /* # of sections per zone */ + __le32 checksum_offset; /* checksum offset inside super block */ + __le64 block_count; /* total # of user blocks */ + __le32 section_count; /* total # of sections */ + __le32 segment_count; /* total # of segments */ + __le32 segment_count_ckpt; /* # of segments for checkpoint */ + __le32 segment_count_sit; /* # of segments for SIT */ + __le32 segment_count_nat; /* # of segments f...

...he memory footprint sums array which could compounded by the sum hash could be a limiting factor on the size file a given machine can reasonably handle. The second table shows the effect of --block-size=16384 and is indicative of what setting a MAX_BLOCK_SIZE would do. file length block_len block_count s2length xmit sums array_size 50 700 1 2 6 36 831K 920 926 2 5556 32K 1439K 1208 1221 2 7326 42K 2493K 1592 1604...