From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56417) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlavP-0002XI-3n for qemu-devel@nongnu.org; Fri, 24 Apr 2015 06:33:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YlavG-0001uW-Q8 for qemu-devel@nongnu.org; Fri, 24 Apr 2015 06:33:35 -0400 From: Fam Zheng Date: Fri, 24 Apr 2015 18:33:18 +0800 Message-Id: <1429871600-10180-1-git-send-email-famz@redhat.com> Subject: [Qemu-devel] [PATCH v2 0/2] block: Fix unaligned bdrv_aio_write_zeroes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Kevin Wolf , pbonzini@redhat.com, qemu-block@nongnu.org, qemu-stable@nongnu.org, Stefan Hajnoczi An unaligned zero write causes NULL deferencing in bdrv_co_do_pwritev. That path is reachable from bdrv_co_write_zeroes and bdrv_aio_write_zeroes. You can easily trigger through the former with qemu-io, as the test case added by 61815d6e0aa. For bdrv_aio_write_zeroes, in common cases there's always a format driver (which uses 512 alignment), so it would be much rarer to have unaligned requests (only concerning top level here, when the request goes down to bs->file, where for example the alignment is 4k, it would then be calling bdrv_co_write_zeroes because it's in a coroutine). fc3959e4669a1c fixed bdrv_co_write_zeroes but not bdrv_aio_write_zeroes. The lattern is the actually used one by device model. Revert the previous fix, do it in bdrv_co_do_pwritev, to cover both paths. v2: Split to three aligned pwritev. Fam Zheng (2): Revert "block: Fix unaligned zero write" block: Fix NULL deference for unaligned write if qiov is NULL block.c | 121 +++++++++++++++++++++++++++++++++++----------------------------- 1 file changed, 66 insertions(+), 55 deletions(-) -- 1.9.3