Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp555912pxb; Wed, 13 Jan 2021 10:01:18 -0800 (PST) X-Google-Smtp-Source: ABdhPJxfiO2b5cDrycy8kHXC7D5auI00MKFFj5D2pwThfvL6glmQsMxD9Tpl4ofiLbEDiT0V+sVp X-Received: by 2002:a05:6402:2207:: with SMTP id cq7mr2786318edb.310.1610560878023; Wed, 13 Jan 2021 10:01:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610560878; cv=none; d=google.com; s=arc-20160816; b=Hh00s2Etj6AT4yCzcb8YbZxcro3Xi0FWJFmffO0lyMhc02yuZ0k2bSWO3DwnJCCdjP 5EZpsTnrh0SvGu4l00QyJoITpjoUMQc+EZSAO+RapE5Vb/Rmcup0Z2UlS7N3j58egceo AlhmJqy64x2iAcBiLQUSw/QBkMSHfBxPar/TqAQH74anRMjLey91EQMQNtaYmLRo8GmT FqsctmluguFjBl9emmUSHIr6f2b4afbeBdxncXu/XBpEpq/ZlMGi41QgvZ60URFRCVBv wEpVficGu/IjYVRGNlrbfXAZXiiDJ4G5jVrZB3J/dmJkZ59cluQUHCjHQMc6r4PyLx8A JRqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=K3lJSkAmIONPcPf9xd+9VR4Fox3bOonPKOs/UyGeHBg=; b=ElDDDjWH0N3+BXdsAg6dr4u1MFT+gQcFTpJy6qbvjTJQn+nokZqUcoGsF1WGB5ymyG +o976xGIXkerh3l54wxcvve2zg0VELfdUt+1THlrOq3VAbSxbJNpkh6jOxe4b5V+FDkL aM1nNjBaf0yE0rYsSRLCnWKQiGBwO4RP1k3uwFBHj3HyKjADFkMm4Z97ubmHSmN/AtLw RCfg1S0aNkSIfsMsbZvSCrLGhC0hp9jg9WA5NWnAfeKtzWPRHVOBQQLn6H1kT93jpGpp IHZyqWlkbNVTnT1zbK5JE3+GclNjLW5rykC7SNrB4VDtQ/xT02LOJgEmscfbEwKDUPcP WyEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IiVJwDFj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id c7si1340989edr.193.2021.01.13.10.00.54; Wed, 13 Jan 2021 10:01:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IiVJwDFj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1727808AbhAMR7y (ORCPT + 99 others); Wed, 13 Jan 2021 12:59:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54632 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727198AbhAMR7y (ORCPT ); Wed, 13 Jan 2021 12:59:54 -0500 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0237C061786; Wed, 13 Jan 2021 09:59:13 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id e18so4305905ejt.12; Wed, 13 Jan 2021 09:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=K3lJSkAmIONPcPf9xd+9VR4Fox3bOonPKOs/UyGeHBg=; b=IiVJwDFjknV0MCeRm+zflcNlKRlgNisAvliRi4aqQzoHrZbPMoS9Wf7DwhquZZTKrM Y0mg8t8ESlugD2Je3+BvIi3QmnBK5kzzgAxlWWR9VJNm7HcCj7/nRVsFMAlx/n1Cnp/a fpAwe5Zn1Y0IDz4CyEwFeLkybolvmLxhXEkxXAbQGA0cvfOET9iIvxawE1ner/q6Kf87 Qr15Ikh5cOQK20+X/3GZa3vcDOVtmp1uz3abAfzzSNrctw50jdUmRc5hTGpdPQZYgqgM Xz4CZgOQLgp7/sls8INl4Hx8rxaHSIkHhKhlVaEGaMEa4NWdLeImdrSfPwPy8joUq5hj dD/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=K3lJSkAmIONPcPf9xd+9VR4Fox3bOonPKOs/UyGeHBg=; b=MrMcgjMfXho/Pe5mPDeg6K4IAhf0auYOxwB8WNsap2MSdLNGu9AiFlrqo+1iE6nYC8 k2XLlxhP8d+6MXGXYK3G1dWgnnPRvbc6eoEW82yaTgy0RRdXaS/MsvYGYnC4u2IHoqK9 e18OUaqC6kUJFQHdFWrU9/8ht4gA41vFVCW5J7Mx8LsHaG9yO/uLmgeZj8xiZCrLIE0J VOjR/0mhUoDLvgMAPHIBFTmJvLesTJyDELzYLQ0OeaIe9NIU1maLyd7iyuemQBVvBcyh WjAWMvpXK8kpdLQl/yvQaDUfQjbreyDIXLIee+iN50T9AYQO/4hQIdoBCUpZFcnIVpS1 s+Hg== X-Gm-Message-State: AOAM530Wa0KM2JiWNMPAKnGsjja5J5LfODzCZWhImqFtinolSB5F2iap RmFebWBY7Y91Ne7zrtOSseg= X-Received: by 2002:a17:907:20a6:: with SMTP id pw6mr2503938ejb.73.1610560752516; Wed, 13 Jan 2021 09:59:12 -0800 (PST) Received: from [192.168.178.40] (ipbcc05d1b.dynamic.kabel-deutschland.de. [188.192.93.27]) by smtp.gmail.com with ESMTPSA id x9sm989146ejd.99.2021.01.13.09.59.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Jan 2021 09:59:11 -0800 (PST) Subject: Re: [PATCH] scsi: target: tcmu: Fix wrong uio handling causing big memory leak To: Mike Christie , linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, linux-kernel@vger.kernel.org, "Martin K. Petersen" Cc: Greg Kroah-Hartman References: <20201218141534.9918-1-bostroesser@gmail.com> <73dc2d01-6398-c1d1-df47-66034d184eec@oracle.com> From: Bodo Stroesser Message-ID: Date: Wed, 13 Jan 2021 18:59:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <73dc2d01-6398-c1d1-df47-66034d184eec@oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12.01.21 19:36, Mike Christie wrote: > On 12/18/20 8:15 AM, Bodo Stroesser wrote: >> tcmu calls uio_unregister_device from tcmu_destroy_device. >> After that uio will never call tcmu_release for this device. >> If userspace still had the uio device open and / or mmap'ed >> during uio_unregister_device, tcmu_release will not be called and >> udev->kref will never go down to 0. >> > > I didn't get why the release function is not called if you call > uio_unregister_device while a device is open. Does the device_destroy call in > uio_unregister_device completely free the device or does it set some bits so > uio_release is not called later? uio_unregister_device() resets the pointer (idev->info) to the struct uio_info which tcmu provided in uio_register_device(). The uio device itself AFAICS is kept while it is open / mmap'ed. But no matter what userspace does, uio will not call tcmu's callbacks since info pointer now is NULL. When userspace finally closes the uio device, uio_release is called, but tcmu_release can not be called. > > Do other drivers hit this? Should uio have refcounting so uio_release is called > when the last ref (from userspace open/close/mmap calls and from the kernel by > drivers like target_core_user) is done? > To be honest I don't know exactly. tcmu seems to be a special case in that is has it's own mmap callback. That allows us to map pages allocated by tcmu. As long as userspace still holds the mapping, we should not unmap those pages, because userspace then could get killed by SIGSEGV. So we have to wait for userspace closing uio before we may unmap and free the pages.