|
From: | Vladimir Sementsov-Ogievskiy |
Subject: | Re: request_alignment vs file size, how to fix crash? |
Date: | Thu, 30 Jan 2020 13:40:30 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 |
29.01.2020 21:01, Vladimir Sementsov-Ogievskiy wrote:
Hi! I found a crash, which may be simply triggered for images unaligned to request_alignment: # ./qemu-io --image-opts -c 'write 0 512' driver=blkdebug,align=4096,image.driver=null-co,image.size=512 qemu-io: block/io.c:1505: bdrv_aligned_pwritev: Assertion `end_sector <= bs->total_sectors || child->perm & BLK_PERM_RESIZE' failed. Aborted (core dumped) The problem is obvious: 512 is aligned to 4096 and becomes larger than file size. I faced it after rebasing our downstream branches to newer Rhel versions. Seems that after some updates of alignment detection in file-posix.c, it started to detect 4096 alignment in our build environment, and iotest 152 started to crash (as it operates on file of 512 bytes). My question is: What is wrong? Should we restrict images to be aligned to request_alignment, or allow unaligned operations at EOF, if file is unaligned itself?
The problem started with commit commit a6b257a08e3d72219f03e461a52152672fec0612 Author: Nir Soffer <address@hidden> Date: Tue Aug 13 21:21:03 2019 +0300 file-posix: Handle undetectable alignment It sets request_alignment to 4k, if probing of align=1 succeeded.. I think it's wrong logic. It leads to crashes for images unaligned to 4k. If we force alignment to be 4k, we at least should check that file size is aligned to 4k. Otherwise our assumption is definitely wrong. And still, I doubt that it's correct to force alignment to 4k, for devices which doesn't request any alignment.. -- Best regards, Vladimir
[Prev in Thread] | Current Thread | [Next in Thread] |