Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp399319imn; Fri, 29 Jul 2022 10:13:44 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sNu8IMzaeL6E4x9u5Twz5pyTHgd8ZzxG+Jm7aWhuMTh9zpKaFEXvAaV3c5NeNpgt4sWnHe X-Received: by 2002:a17:907:97d6:b0:72f:97d9:978d with SMTP id js22-20020a17090797d600b0072f97d9978dmr3424746ejc.684.1659114824128; Fri, 29 Jul 2022 10:13:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659114824; cv=none; d=google.com; s=arc-20160816; b=tnQ3GoxTCoCtrXsJp+3wag0gt3FPkVkTwQ+TZGtIIOdjvroVNWcunaP/NGEGSxCShU d+fUVc9w4bqS+8JpxzGMvA5l26Wv8/8ZLLEvxJ3xNIBKrTY59cQQLP2wdOhuBHkrM1oo 9vrKvUsxVJzJnnZx85ypqJZ1KK7YZn6WBYkKHCD2r6hUeviMg0Ef+FDVASj4iCQCyMq6 dBgpUB5HOKQICi7wCDrYct/6LO+1fQR2pcRlbP9Y3rSVJ19/8PLDrlisuX5ZsSMw+9mG 8dw3tbjxfY9b2VzEmoC+mA03RL88TuW44nBXCXrequmh0LfAR42KBMgJht4+wrCNc0iX hCGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=hmNoWNPypWmQWVa+t2NfUq5X6H5GXgtRuGNgsGhG6fI=; b=vHWX3bOxjnLIxwfip0eGGh1iEMKFezvxIeteGuLuAktiOGRuwtfZoLIZxHFdhwF9Vt +POuckN+plXmA7Qy8XeoX4XF8VmgMyO9FQ14YEdCpr5TgTNTBzLxSFLuYJ6CnjgjPOBD IvwILEWecOihDRnyLz/jttuHhSJh9hpdQQXtETFMZevqRdkQ0dLDTiZ2Q01GK+VMpQAQ zvxsTG374kaO0GPfe2NtvyzRU0OUGEv3MqWUxs1mbHkz8ZhTb7BffMCl544KSpWbskG2 neY/LYaIFnELwEIoLwAyJOZIkmeaXGeVVPZUYx/ojDkH2LMIzuIC5LMqjkWpa0Fu6O+y jy6g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=ZuhQjA5T; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hq6-20020a1709073f0600b00726347cbb61si2463113ejc.981.2022.07.29.10.13.18; Fri, 29 Jul 2022 10:13:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=ZuhQjA5T; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238214AbiG2RBK (ORCPT + 99 others); Fri, 29 Jul 2022 13:01:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49210 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238186AbiG2RBI (ORCPT ); Fri, 29 Jul 2022 13:01:08 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21042222A9; Fri, 29 Jul 2022 10:01:08 -0700 (PDT) Received: from [192.168.2.145] (109-252-119-232.nat.spd-mgts.ru [109.252.119.232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dmitry.osipenko) by madras.collabora.co.uk (Postfix) with ESMTPSA id B1EE76601B81; Fri, 29 Jul 2022 18:01:05 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1659114066; bh=0DZzQCDhxMZyj8pa64Uer8N/SjmqS8UbUsoU385WfCg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ZuhQjA5Ti78yA6ymtTc+PGidQGdNkfWdhZNVtn9coYskHQ0beJC/AHZ8aFgw6RoYl gWiWnEQk2mUDJLJZQEZ1/wJt2epg5xkLELVnjTS4EOni/IUgOqA2/XFGJSD4FQlaTb 1m3BsNqBnVZFI+BLjz4P6UbilH0t3Rq8K4Y24FQFQQaz6RfBlKtvNIuQZ3y98j811v 3ZJ9gu9VeS+JfeheipDyJV3HsShOMU5Bo5TAjeYAeRpVJ6oyEBhDuJyNINWYrJoxnG ecfTjeKHwQTY1znUrDFjoN12398bBa6nFFg0/xW/To1DsfyWLevwLjGZFQhYlkEXwp pNg9BC6P/B2wA== Message-ID: <6ceabe5a-a1ff-0717-96f1-0d28167ef649@collabora.com> Date: Fri, 29 Jul 2022 20:01:02 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH v3 09/15] drm/gem: Add LRU/shrinker helper Content-Language: en-US To: Rob Clark Cc: dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, Rob Clark , Daniel Vetter , Thomas Zimmermann , Maarten Lankhorst , Maxime Ripard , David Airlie , open list References: <20220726175043.1027731-1-robdclark@gmail.com> <20220726175043.1027731-10-robdclark@gmail.com> <49fe9ecf-b1bd-a21b-8d8c-e4a33e3fa821@collabora.com> From: Dmitry Osipenko In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/29/22 18:40, Rob Clark wrote: > On Fri, Jul 29, 2022 at 8:27 AM Dmitry Osipenko > wrote: >> >> On 7/26/22 20:50, Rob Clark wrote: >>> +/** >>> + * drm_gem_lru_move_tail_locked - move the object to the tail of the LRU >>> + * >>> + * If the object is already in this LRU it will be moved to the >>> + * tail. Otherwise it will be removed from whichever other LRU >>> + * it is in (if any) and moved into this LRU. >>> + * >>> + * Call with LRU lock held. >>> + * >>> + * @lru: The LRU to move the object into. >>> + * @obj: The GEM object to move into this LRU >>> + */ >>> +void >>> +drm_gem_lru_move_tail_locked(struct drm_gem_lru *lru, struct drm_gem_object *obj) >>> +{ >>> + lockdep_assert_held_once(lru->lock); >>> + >>> + if (obj->lru) >>> + lru_remove(obj); >> >> The obj->lru also needs to be locked if lru != obj->lru, isn't it? And >> then we should add lockdep_assert_held_once(obj->lru->lock). >> > > It is expected (mentioned in comment on drm_gem_lru::lock) that all > lru's are sharing the same lock. Possibly that could be made more > obvious? Having per-lru locks wouldn't really work for accessing the > single drm_gem_object::lru_node. Right, my bad. I began to update the DRM-SHMEM shrinker patches on top of the shrinker helper, but missed that the lock is shared when was looking at this patch again today. Adding comment to the code about the shared lock may help a tad, but it's not really necessary. It was my fault that I forgot about it. Thank you! -- Best regards, Dmitry