From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B5578C433EF for ; Wed, 11 May 2022 23:15:23 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1922A10E789; Wed, 11 May 2022 23:15:23 +0000 (UTC) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id A81DF10E789 for ; Wed, 11 May 2022 23:15:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652310921; x=1683846921; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=sevAom88DlmQgnkQtY3hWeh70JGjrEZ03PhK7db+Q5M=; b=f6dpBJG8hZorrwW4OXIwLKDxZrgw9T0yy141EkjJrWiNxBPokwqvhAdo 1FDVUXOG74Am0zX4xuzi5jOjxLXx9eLQJ+No1a05gZQ5543qssz8gzv+j PvlSyEIyYmxHIGXZUxPvELGRGApN6+XwVFB9wgF5wcJxSyPIwy1qiLcW7 8Eu2wsF/zatDAH6GLvyiVX/mkZ6hB8wxcGIMwP7UnhJaz5JK9lh6DzFJ2 PALIC3uQekWKRCr9kTmZOYtlCtmQhFXS9e9qvGFLEDCqVUA2IcEJIQFB5 N4LnvLMn9C48gwNWmEeHW8ooRKuNLgpiM4DihRYp6W6Ij/FZW2Tik+MI1 g==; X-IronPort-AV: E=McAfee;i="6400,9594,10344"; a="295082768" X-IronPort-AV: E=Sophos;i="5.91,218,1647327600"; d="scan'208";a="295082768" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 May 2022 16:15:21 -0700 X-IronPort-AV: E=Sophos;i="5.91,218,1647327600"; d="scan'208";a="566402811" Received: from adixit-mobl1.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.252.130.105]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 May 2022 16:15:20 -0700 Date: Wed, 11 May 2022 16:15:20 -0700 Message-ID: <87fslf7jav.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Andrzej Hajda In-Reply-To: References: <06685e6216a1afc79bdf76bd1cfafbc929d4e376.1651261886.git.ashutosh.dixit@intel.com> <91a24f6c-4eb6-cc40-f252-d2d45673f932@linux.intel.com> <9f1f6c83-67ad-b222-97ff-ec3905e68eeb@linux.intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [Intel-gfx] [PATCH 6/8] drm/i915/gt: Fix memory leaks in per-gt sysfs X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx@lists.freedesktop.org, Andi Shyti Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, 10 May 2022 03:41:57 -0700, Andrzej Hajda wrote: > On 10.05.2022 11:48, Tvrtko Ursulin wrote: > > On 10/05/2022 10:39, Andrzej Hajda wrote: > >> On 10.05.2022 10:18, Tvrtko Ursulin wrote: > >>>>> > >>>>> Was there closure/agreement on the matter of whether or not there is > >>>>> a potential race between "kfree(gt)" and sysfs access (last put from > >>>>> sysfs that is)? I've noticed Andrzej and Ashutosh were discussing it > >>>>> but did not read all the details. > >>>>> > >>>> > >>>> Not really :) > >>>> IMO docs are against this practice, Ashutosh shows examples of this > >>>> practice in code and according to his analysis it is safe. > >>>> I gave up looking for contradictions :) Either it is OK, kobject is > >>>> not fully shared object, docs are obsolete and needs update, either > >>>> the patch is wrong. > >>>> Anyway finally I tend to accept this solution, I failed to prove it is > >>>> wrong :) > >>> > >>> Like a question of whether hotunplug can be triggered while userspace > >>> is sitting in a sysfs hook? Final kfree then has to be delayed until > >>> userspace exists. > >>> > >>> Btw where is the "kfree(gt)" for the tiles on the PCI remove path? I > >>> can't find it.. Do we have a leak? > >> > >> intel_gt_tile_cleanup ? > > > > Called from intel_gt_release_all, whose only caller is the failure path > > of i915_driver_probe. Feels like something is missing? > > This is final proof this patch is safe - no kfree, no UAF :) > > Apparently it is broken in internal branch as well. > Should I take care of it? See Daniele's comment here: https://patchwork.freedesktop.org/patch/478856/?series=101551&rev=1 We clean up the gt sysfs during PCI device remove (i915_driver_remove -> i915_driver_unregister -> intel_gt_driver_unregister -> intel_gt_sysfs_unregister (added in this patch)). But from Daniele's mail it appears that "kfree(gt)" can only be done from i915_driver_release(). So as long as i915_driver_release() always happens after i915_driver_remove() (which seems to be the case though I couldn't figure out why (i.e. who is putting the final reference of the drm device)) there is no UAF and no race. Thanks!