| Message ID | 1414671976-5353-3-git-send-email-kwolf@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Thu, Oct 30, 2014 at 01:26:14PM +0100, Kevin Wolf wrote: > The only image format driver that even potentially accesses anything > after 512 bytes in its bdrv_probe() implementation is VMDK, which reads > a plain-text descriptor file. In practice, the field it's looking for > seems to come first and will be well within the first 512 bytes, too. > > Signed-off-by: Kevin Wolf <kwolf@redhat.com> > --- > block.c | 2 +- > include/block/block_int.h | 2 ++ > 2 files changed, 3 insertions(+), 1 deletion(-) I tried to find a logical reason for the historical 1024 and 2048 byte sizes but it's not clear. 512 should be fine. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
diff --git a/block.c b/block.c index 8da6e61..8006685 100644 --- a/block.c +++ b/block.c @@ -678,7 +678,7 @@ static int find_image_format(BlockDriverState *bs, const char *filename, BlockDriver **pdrv, Error **errp) { BlockDriver *drv; - uint8_t buf[2048]; + uint8_t buf[BLOCK_PROBE_BUF_SIZE]; int ret = 0; /* Return the raw BlockDriver * to scsi-generic devices or empty drives */ diff --git a/include/block/block_int.h b/include/block/block_int.h index 8898c6c..697cd5d 100644 --- a/include/block/block_int.h +++ b/include/block/block_int.h @@ -57,6 +57,8 @@ #define BLOCK_OPT_REDUNDANCY "redundancy" #define BLOCK_OPT_NOCOW "nocow" +#define BLOCK_PROBE_BUF_SIZE 512 + typedef struct BdrvTrackedRequest { BlockDriverState *bs; int64_t offset;
The only image format driver that even potentially accesses anything after 512 bytes in its bdrv_probe() implementation is VMDK, which reads a plain-text descriptor file. In practice, the field it's looking for seems to come first and will be well within the first 512 bytes, too. Signed-off-by: Kevin Wolf <kwolf@redhat.com> --- block.c | 2 +- include/block/block_int.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-)