From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34005) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bULs1-0002zo-UE for qemu-devel@nongnu.org; Mon, 01 Aug 2016 18:39:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bULs0-00036l-Vd for qemu-devel@nongnu.org; Mon, 01 Aug 2016 18:39:37 -0400 References: <1469616590-38683-1-git-send-email-vsementsov@virtuozzo.com> <1469616590-38683-2-git-send-email-vsementsov@virtuozzo.com> From: John Snow Message-ID: <9586a77d-3656-94e9-b94c-edb45ea10816@redhat.com> Date: Mon, 1 Aug 2016 18:39:28 -0400 MIME-Version: 1.0 In-Reply-To: <1469616590-38683-2-git-send-email-vsementsov@virtuozzo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 1/3] blockjob: fix dead pointer in txn list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org, qemu-block@nongnu.org Cc: kwolf@redhat.com, famz@redhat.com, mreitz@redhat.com, stefanha@redhat.com, den@openvz.org On 07/27/2016 06:49 AM, Vladimir Sementsov-Ogievskiy wrote: > Job may be freed in block_job_unref and in this case this would break > transaction QLIST. > > Fix this by removing job from this list before unref. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > blockjob.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/blockjob.c b/blockjob.c > index a5ba3be..e045091 100644 > --- a/blockjob.c > +++ b/blockjob.c > @@ -216,6 +216,7 @@ static void block_job_completed_single(BlockJob *job) > } > job->cb(job->opaque, job->ret); > if (job->txn) { > + QLIST_REMOVE(job, txn_list); > block_job_txn_unref(job->txn); > } > block_job_unref(job); > Has this caused actual problems for you? This function is only ever called in a transactional context if the transaction is over -- so we're not likely to use the pointers ever again anyway. Still, it's good practice, and the caller uses a safe iteration of the list, so I think this should be safe. But I don't think this SHOULD fix an actual bug. If it does, I think something else is wrong. Tested-by: John Snow Reviewed-by: John Snow