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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E579FCDB465 for ; Thu, 19 Oct 2023 10:32:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 09AD880046; Thu, 19 Oct 2023 06:32:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 049B68D0199; Thu, 19 Oct 2023 06:32:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7A0D80046; Thu, 19 Oct 2023 06:32:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D84B38D0199 for ; Thu, 19 Oct 2023 06:32:32 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AC24F1A12D1 for ; Thu, 19 Oct 2023 10:32:32 +0000 (UTC) X-FDA: 81361846944.13.423D79E Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.20]) by imf28.hostedemail.com (Postfix) with ESMTP id 567E5C0009 for ; Thu, 19 Oct 2023 10:32:29 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ME8xhXMr; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf28.hostedemail.com: domain of andrzej.hajda@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=andrzej.hajda@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697711549; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UzWWV6rsMmfikab3jAz9BX6O0Dcgjej4nKDj8tBtvTc=; b=V+3or7/gN1SxmkocLfZ3sCZkEaQA4WRRH/Fh8mOjiHzEvrVWM+gbNrTBcaZlDVD0kJA5qd /Z0lQ3uL+g7V3UPYF0FfkY3E//SwiMgXbYbzhADDOHBkOICO3u+5JOQC9QPaTkEZd1Z/Fj stykvGjXQCL2c3QjdmcnWkH+pybsqHU= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ME8xhXMr; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf28.hostedemail.com: domain of andrzej.hajda@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=andrzej.hajda@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697711549; a=rsa-sha256; cv=none; b=Gg1MjnSNtLDTFPzekcMJv7NcvrpaDtBwGw9RnWo2pHmEwPFjBOBrhfCXLT/RyOYs7fH2sc 8IWo08hnJLSKqBA9Cu9ZNtMUmj3lSQOcJoSCpPpe6c4XdQV5PBPeVXaRYw4t43yZmmCN5i UMuLn0KUkIZi/e3xDkjycyPmQO9GELE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697711549; x=1729247549; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=qRBkCTJbRJlP/rxYmWi5U4pxhGfUHsPS+Zw8MPdhUoY=; b=ME8xhXMr6q6wMIEhUqvIRmsNio/hAFilDZq4dRhLKm1rmroafbrxosSt HQOSh1c2ONnT39y9cnwOrcFVeH27ynwTQxLByh83QKB8zB9taBV5Fl6UC 4OyFxZIjRhv4vqOZE3dQ2nVnJdczskltym+xoj6QwgRLRV8zgvNPPs7J1 Aigf362ZF2T3DYM1JfUaV7e9Dd1opu0n1XjPM5M74E44uwNNfwJmThqHp Pm6Vx19h4nJKn0Hgnuy0885KtOl2dep/V+rPkrAvoJp7Bfa5MxDmpcbd9 RZFtpQTKJ0ThyoMXwCw1uX6Uu4BTJtPahVAdVN3OAe6HL3RLFHkqnUHJ2 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10867"; a="376596457" X-IronPort-AV: E=Sophos;i="6.03,237,1694761200"; d="scan'208";a="376596457" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Oct 2023 03:31:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10867"; a="706807168" X-IronPort-AV: E=Sophos;i="6.03,237,1694761200"; d="scan'208";a="706807168" Received: from ahajda-mobl.ger.corp.intel.com (HELO [10.213.3.232]) ([10.213.3.232]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Oct 2023 03:31:40 -0700 Message-ID: <62e16250-63f4-4fbb-b00e-db808b600664@intel.com> Date: Thu, 19 Oct 2023 12:31:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Intel-gfx] [PATCH v2] debugobjects: stop accessing objects after releasing spinlock Content-Language: en-US To: Thomas Gleixner , linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-mm@kvack.org Cc: Nirmoy Das References: <20230925131359.2948827-1-andrzej.hajda@intel.com> <87v8bak6iy.ffs@tglx> From: Andrzej Hajda Organization: Intel Technology Poland sp. z o.o. - ul. Slowackiego 173, 80-298 Gdansk - KRS 101882 - NIP 957-07-52-316 In-Reply-To: <87v8bak6iy.ffs@tglx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 567E5C0009 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: o15i8ahbmfayer6dthopfdthknfiauqs X-HE-Tag: 1697711549-907756 X-HE-Meta: U2FsdGVkX1+g4rDYDQwi08KazQ+dhTeUcyx3RuPWvVr6IhPwFcHVDmMD16o8YdYs2DDgTI35IzcUPALPcaCq3ZumYjo1UxgSgOivTu5nH7BZqBQVx88xzJDMzyxDNvEUlAuigmKAIREvf5s0ml7WE4e8OHbCxb/YlbPHxH07OTFTdlhwXOpRTRdt/NSWu+DnFQdLYFbHN56ThB7CRX3bpwZQ2CaG8RpvC/3DwYPXKinL2XonJnzhUiRBhirJG5fhf/8GTIJu1YAshqLRWJK80iEygauwilPPL6Q4H3GYCpmii9ifErcGldysze0a444V5XVgnwUAoK5op5PiMqYkI3P7eKH/8U/TZlGhr0syfkaORbGy+K9od+lgojYi7Aol9p34mPBSMFaAkAmNgTLqtAGp3d4gjbKxa62l485l9RdaDAfFEeHn+t9yQxrLBS0KNEOUQX1iiwvwWYHfT3HpAVSAWsCscoALg1NdHpNPK12TPmrBb2GRHEDLC9eT2N01fmc1jVpuDvUMv8cSkakGyUVt9zXgpLGdEvcnSVy79ab32IYUYLG2e8q/X/18XmxpotsVqP0LD+/QCpcbQcX9ifxc25dEnG9AqZezuOL0HvGmYmeGAVGRDa3p5ClAtpdme7VOVYPUtXL+j3cscGCIKnYdRuul3kIkDBKsoBqIEU+wGHVc23LDh91uXWVRxuCwtlvbbwGg4aWcDS+jHM1GCOtzKFLOHFSTYWbsqQmQAKuAdrGYo8PHP+OH+HX5ogXuujEUppKKP8dVfGwxgp/on7DJMTMO6kCADM6sRN1yQxmwQz3w1vt2ibI1pdXhiQyX/k2sNgdCla5QyjcmKv0tEalNDntPaR1Ow3jmOS+2WKA5F7pTpczlD8rc2MX6F05O/G1AFRVHvpdoo5O0uFjnHVAMstQLSCLm1BwCj0zkgHw0OjyNwQiM7IE40JTDMj7oJc+MgEEVkd3Ocz1u5uG M9nuMvx7 m0bHGEZRpQG4r/dsAJ0wA0AiV7lozcyArXrLJscCzHykDL+JalPHSXoggRCaMXOp4tFlYY8PIiZba2dPPUpZr/gJTGQ/pfybxbkLTMH/OYANyl8IYHld5tp2+UYmDH5jjSgJdOmCsu2R2pwWiO7RLbl7Ajpwz+wciSBEoHpO/aZyhNhAkVSFdii7bLOtqnizbfSck3mn8V/079Iqftz1O9Pwhyw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 13.10.2023 15:15, Thomas Gleixner wrote: > On Mon, Sep 25 2023 at 15:13, Andrzej Hajda wrote: >> After spinlock release object can be modified/freed by concurrent thread. >> Using it in such case is error prone, even for printing object state. > > It cannot be freed. If that happens then the calling code will have an > UAF problem on the tracked item too. Yes, and I have assumed that debugobjects are created also for detecting UAFs. They should be able to handle/detect 'issues due to incorrectly serialized concurrent accesses' scenarios as well, at least some of them. And even if it cannot recover it should at least provide reliable reporting. Now we can have scenario: 1. Thread tries to deactivate destroyed object, debugobjects detects it, spin lock is released, thread is preempted. 2. Other thread frees debugobject, then allocates new one on the same memory location, ie 'obj' variable from 1st thread point to it - it is possible because there is no locking. 3. Then preemption occurs, and 1st thread reports error for wrong object. This seems the most drastic for me, but also with lowest chances to happen due to delayed freeing, but there are also other more probable scenarios when we print the same object but in state different from the one when debugobject detected issue, due to modification by concurrent thread. > > If there is a concurrent modification then again, the calling code is > lacking serialization on the tracked object. > > debugobject fundamentally relies on the call site being consistent > simply because it _cannot_ invoke the fixup callbacks with the hash > bucket lock held. Hmm, if call site is consistent then 'fixup' seems unnecessary, together with debugobjects. I guess 'fixup' users should take care of locking on they own in such case, as it is currently, nothing changed. > > What's the actualy problem you are trying to solve here. The changelog > does not explain anything except of handwaving about modified/freed. Presented above. Regards Andrzej > > Thanks, > > tglx