From patchwork Thu Jul 9 21:32:42 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 6759961 Return-Path: X-Original-To: patchwork-dri-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id D76B29F46B for ; Thu, 9 Jul 2015 21:30:33 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 084C5207A0 for ; Thu, 9 Jul 2015 21:30:33 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 1AD152078F for ; Thu, 9 Jul 2015 21:30:32 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3AAFD7A08A; Thu, 9 Jul 2015 14:30:31 -0700 (PDT) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by gabe.freedesktop.org (Postfix) with ESMTPS id 03EC97A088 for ; Thu, 9 Jul 2015 14:30:30 -0700 (PDT) Received: by wgjx7 with SMTP id x7so233873677wgj.2 for ; Thu, 09 Jul 2015 14:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=Fb8kZEq+yZqLGQEg5Xqg81jOKTLlovM/SZR+j9GnxZE=; b=Ph9d1M2c39ILOH9QXbm+oGx5dc/7Inagij7xrJj5B/ZrhU276OsfNtb8fw1sb0rgHh rfqIvxH8x/mPqGcX2OYooouT2pPY+xRBLh+2Tgm20bCuaRzUVDmg8kBIQNsY+hpkdhns f/7q2VScXLgtIr3tMYNU648803QswGyXT/jSk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=Fb8kZEq+yZqLGQEg5Xqg81jOKTLlovM/SZR+j9GnxZE=; b=J5d//z98oyPSuBbhHKE7qv97kl7XiszSfZMjawuO7qqM7O23ec8ZU0PPXtDG0It0py Aa6ldzVZljZHfSWcNT95/bQG5pDSwHC85yQrJQVpw3VY1dRI/ZSkYsc8bmurc+Z97Jk8 UgG6uODSZiejJgdTYtxn/flgV9mXTtw8QUIPrWH9C2s4n4pzWqf4tikJjOM1NSktBFVE hyNdTPCUb+8T2xRSzH/axnF1q0VqdPXx8sTx5C2H7vkcHw2sRZxejnYY9LALg8SeUiv9 TrQ6rbJb+Rx+SHxL+zMMxW94Qa/1fGoOyK5aaPlDrfjJc4H10bIuwjAA+UsAfKv4ZYUd njTg== X-Gm-Message-State: ALoCoQk8hooSNwRgxqTF8eIdsWRifBmDoUFAKHo+B0CWD4y2ll2fhVt2+pJzl7afNumLDrmxjSS0 X-Received: by 10.194.121.34 with SMTP id lh2mr34662633wjb.101.1436477428638; Thu, 09 Jul 2015 14:30:28 -0700 (PDT) Received: from phenom.ffwll.local (212-51-149-109.fiber7.init7.net. [212.51.149.109]) by smtp.gmail.com with ESMTPSA id j6sm3004128wix.5.2015.07.09.14.30.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Jul 2015 14:30:27 -0700 (PDT) From: Daniel Vetter To: DRI Development Subject: [PATCH 10/18] drm/rockchip: Don't grab dev->struct_mutex for in mmap offset ioctl Date: Thu, 9 Jul 2015 23:32:42 +0200 Message-Id: <1436477570-4936-11-git-send-email-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1436477570-4936-1-git-send-email-daniel.vetter@ffwll.ch> References: <1436477570-4936-1-git-send-email-daniel.vetter@ffwll.ch> Cc: Daniel Vetter , Daniel Vetter , Intel Graphics Development X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Since David Herrmann's mmap vma manager rework we don't need to grab dev->struct_mutex any more to prevent races when looking up the mmap offset. Drop it and instead don't forget to use the unref_unlocked variant (since the drm core still cares). Aside: I stumbled over the mmap handler which directly does a dma_mmap_attrs. But totally fails to grab a reference on the underlying object and hence looks like it happily just leaks the ptes since there's no guarantee the mmap isn't still around when gem_free_object is called. Which the kerneldoc of dma_mmap_attrs explicitly forbids. Cc: Mark Yao Signed-off-by: Daniel Vetter Reviewed-by: Thierry Reding --- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c index eba5f8a52fbd..ca7b6ebe1145 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c @@ -198,15 +198,11 @@ int rockchip_gem_dumb_map_offset(struct drm_file *file_priv, uint64_t *offset) { struct drm_gem_object *obj; - int ret; - - mutex_lock(&dev->struct_mutex); obj = drm_gem_object_lookup(dev, file_priv, handle); if (!obj) { DRM_ERROR("failed to lookup gem object.\n"); - ret = -EINVAL; - goto unlock; + return -EINVAL; } ret = drm_gem_create_mmap_offset(obj); @@ -217,10 +213,9 @@ int rockchip_gem_dumb_map_offset(struct drm_file *file_priv, DRM_DEBUG_KMS("offset = 0x%llx\n", *offset); out: - drm_gem_object_unreference(obj); -unlock: - mutex_unlock(&dev->struct_mutex); - return ret; + drm_gem_object_unreference_unlocked(obj); + + return 0; } /*