Received: by 10.223.185.116 with SMTP id b49csp5913335wrg; Wed, 28 Feb 2018 00:28:15 -0800 (PST) X-Google-Smtp-Source: AG47ELuorEVbhT8kzLzaWiEOtg7uvkfDcTQFpEACP6CsWTMo8phQ4sgPNzcxBdsZlzS3lLX91nO6 X-Received: by 10.101.102.21 with SMTP id w21mr3498917pgv.247.1519806495577; Wed, 28 Feb 2018 00:28:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519806495; cv=none; d=google.com; s=arc-20160816; b=sg2GUmb8cwVwS51pl4vlreWGp1i/KbC3crqbrBmkmeFtaEI+sSscQIb0MMOKmYu2Z/ fITDkzqRawj2oUfuVomO+PN9WlxH5Hvy6p5QmpUMtoAVOiJ9YQsZEDWWpkDRKOXYVDFl ey9otgtmPgDyW2/IkV4VMG+TifopKYse1mgBq8FxndAg/Vf5ZjOz/kLEhWMC826tHz9D dvowoIo3ubtevSDx8xfgn5fQ3RIAotNrOE8WvIhl7yfKdFQsY7oDjXZUeIA7POPgHNz8 VpRsvSR5Vi7jrnMgne7b/EtbXwNSxmXOhLuta/qvEkJ4XS8mF1GOBsDZUdN3IyhsjztT F1Bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:reply-to:dkim-signature :arc-authentication-results; bh=pz7S+2IjHMbAwmjlQWx3C2ImTUeBHkbEjAcBGxoS4tI=; b=XOI+JORvK4LW3YOA4BpADyO7tE1eZ4mn5L6hRCiDFCWuVFhGUWEyRGPDbwKVxX1AiS dO9j1eXEZkFxwVR6CRPCvcmZiDQbeVLIqYeKnRXK5o+KnVws3SrNiZSvtd2YusJc6hLm EDih9bnlDRUoRBxdQh5hMlZaroTmIcsrlPaQJBJ1gQZCPWmp32sprGoZsoEAGaN/Ax2Z XUqQO6gcKuiKaU/lWK6NmlwyG0FM9jjumv+DiH1+5IWNWXIpEMvpnabNBSsD+FYgX539 l7w6h7rLIc51jKhjKtrJJcTGlWPIeSO6YJvSGhlXLBLK4dygHfa0HFY3a0Kk7BeSp7h3 efuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Sop3VD7S; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o2si883629pfg.286.2018.02.28.00.27.58; Wed, 28 Feb 2018 00:28:15 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Sop3VD7S; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752119AbeB1I0u (ORCPT + 99 others); Wed, 28 Feb 2018 03:26:50 -0500 Received: from mail-wr0-f193.google.com ([209.85.128.193]:44724 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751800AbeB1I0t (ORCPT ); Wed, 28 Feb 2018 03:26:49 -0500 Received: by mail-wr0-f193.google.com with SMTP id v65so1394672wrc.11 for ; Wed, 28 Feb 2018 00:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=pz7S+2IjHMbAwmjlQWx3C2ImTUeBHkbEjAcBGxoS4tI=; b=Sop3VD7Snol2EicQX2zev2JPfbNdVVTWl61XQ6E6PETY5E2UuslDlj0oUziXv7Prmv Y7rhvzam1thduXQL2UcIzb/+w4ALbIMYsRnk880J97zD40p6oox5wRPD5gf1361iLS3A 4NqFzWaXOSbYgAXbhN69bnzTO0yhyRx4z4OpdUAWgQEpvk0WKRiCKZG4SXQv0F7cokGH 54tPpBpbn+5uVAMMI7u9pu+J1gx2agBrmn9i1F9UwKrQzJajp7XF0+OaOcAuIsu6vPIU osiLmwy7t8wu7SgRtMdsB3TqyrRef17fu/k/ccVMt9Jnp1JdmJJC+bT+R39GX+0YnzrW XdaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=pz7S+2IjHMbAwmjlQWx3C2ImTUeBHkbEjAcBGxoS4tI=; b=mAonK4DgvowH7YjsBS5KcgQxmUORXz75FBszuDocbx1pg2G5kZ79mlgSvMULxD4Eii PSRhKs0+GVxSCoPF2ESeBj9agR4oPUYRNvnfE3ThvlPKKI0y7CjkxaC9Xk3YJ1/ux7lS P7WsvUZ0AvpSNQgg715dScvDDsTui3rKf7An5qkP06sz4yCqGstCRByyAJM4gcmIthaY xjuZCrFGaoE1VHSPhpMG8Ml8g9Bc3eglA8W/6jAaSPuZ3iRne6aXZAi7qLIMEUXgnMId qxxTDqEiQdJQXVMlaIiSxfBVUBRbCCGszbGk1oumRYI/XKsSKKO8vjswiDJATM9bjqjM 2Sig== X-Gm-Message-State: APf1xPB1yR8rpZsNebqHAvtn0He3ydF8VpUVDcfh5QwFx6r+FFx8F83C uC7x7eTWhBVnDaaChrNq0tAC+ODY X-Received: by 10.223.153.215 with SMTP id y81mr15147183wrb.144.1519806407898; Wed, 28 Feb 2018 00:26:47 -0800 (PST) Received: from ?IPv6:2a02:908:1251:8fc0:4c6d:7233:b7e1:3b88? ([2a02:908:1251:8fc0:4c6d:7233:b7e1:3b88]) by smtp.gmail.com with ESMTPSA id j132sm1143145wmd.27.2018.02.28.00.26.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Feb 2018 00:26:47 -0800 (PST) Reply-To: christian.koenig@amd.com Subject: Re: [PATCH] dma-buf/reservation: shouldn't kfree staged when slot available To: Monk Liu , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <1519800242-2442-1-git-send-email-Monk.Liu@amd.com> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: Date: Wed, 28 Feb 2018 09:26:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1519800242-2442-1-git-send-email-Monk.Liu@amd.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 28.02.2018 um 07:44 schrieb Monk Liu: > under below scenario the obj->fence would refer to a wild pointer: > > 1,call reservation_object_reserved_shared > 2,call reservation_object_add_shared_fence > 3,call reservation_object_reserved_shared > 4,call reservation_object_add_shared_fence > > in step 1, staged is allocated, > > in step 2, code path will go reservation_object_add_shared_replace() > and obj->fence would be assigned as staged (through RCU_INIT_POINTER) > > in step 3, obj->staged will be freed(by simple kfree), > which make obj->fence point to a wild pointer... Well that explanation is still nonsense. See reservation_object_add_shared_fence: >         obj->staged = NULL; Among the first things reservation_object_add_shared_fence() does is it sets obj->staged to NULL. So step 3 will not free anything and we never have a wild pointer. Regards, Christian. > > in step 4, code path will go reservation_object_add_shared_inplace() > and inside it the @fobj (which equals to @obj->staged, set by above steps) > is already a wild pointer > > should remov the kfree on staged in reservation_object_reserve_shared() > > Change-Id: If7c01f1b4be3d3d8a81efa90216841f79ab1fc1c > Signed-off-by: Monk Liu > --- > drivers/dma-buf/reservation.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c > index 375de41..b473ccc 100644 > --- a/drivers/dma-buf/reservation.c > +++ b/drivers/dma-buf/reservation.c > @@ -74,12 +74,9 @@ int reservation_object_reserve_shared(struct reservation_object *obj) > old = reservation_object_get_list(obj); > > if (old && old->shared_max) { > - if (old->shared_count < old->shared_max) { > - /* perform an in-place update */ > - kfree(obj->staged); > - obj->staged = NULL; > + if (old->shared_count < old->shared_max) > return 0; > - } else > + else > max = old->shared_max * 2; > } else > max = 4;