From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A38435668 for ; Sat, 6 Jan 2024 07:07:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.44]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4T6WZB4G6Yz29dPn; Sat, 6 Jan 2024 15:05:54 +0800 (CST) Received: from kwepemd100006.china.huawei.com (unknown [7.221.188.47]) by mail.maildlp.com (Postfix) with ESMTPS id E021F14040D; Sat, 6 Jan 2024 15:07:22 +0800 (CST) Received: from [10.174.176.82] (10.174.176.82) by kwepemd100006.china.huawei.com (7.221.188.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.1258.28; Sat, 6 Jan 2024 15:07:21 +0800 Message-ID: <20924c0f-b752-4f58-91ce-21ed3b305481@huawei.com> Date: Sat, 6 Jan 2024 15:07:21 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 0/2] iommu/iova: Make the rcache depot properly flexible To: Ethan Zhao CC: , , , , , , , Ido Schimmel , Robin Murphy References: From: "zhangzekun (A)" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemd100006.china.huawei.com (7.221.188.47) 在 2024/1/6 12:21, Ethan Zhao 写道: > > On 1/2/2024 3:24 PM, Ido Schimmel wrote: >> On Thu, Dec 28, 2023 at 02:23:20PM +0200, Ido Schimmel wrote: >>> On Tue, Sep 12, 2023 at 05:28:04PM +0100, Robin Murphy wrote: >>>> v2: >>>> https://lore.kernel.org/linux-iommu/cover.1692641204.git.robin.murphy@arm.com/ >>>> >>>> Hi all, >>>> >>>> I hope this is good to go now, just fixed the locking (and threw >>>> lockdep at it to confirm, which of course I should have done to begin >>>> with...) and picked up tags. >>> Hi, >>> >>> After pulling the v6.7 changes we started seeing the following memory >>> leaks [1] of 'struct iova_magazine'. I'm not sure how to reproduce it, >>> which is why I didn't perform bisection. However, looking at the >>> mentioned code paths, they seem to have been changed in v6.7 as part of >>> this patchset. I reverted both patches and didn't see any memory leaks >>> when running a full regression (~10 hours), but I will repeat it to be >>> sure. >> FYI, we didn't see the leaks since reverting these two patches whereas >> before we saw them almost everyday, so I'm quite sure they introduced >> the leaks. > > Seems some magazines were not freed when one CPU is dead (hot > unplugged) ? > > static void free_cpu_cached_iovas(unsigned int cpu, struct iova_domain > *iovad) > { >     struct iova_cpu_rcache *cpu_rcache; >     struct iova_rcache *rcache; >     unsigned long flags; >     int i; > >     for (i = 0; i < IOVA_RANGE_CACHE_MAX_SIZE; ++i) { >         rcache = &iovad->rcaches[i]; >         cpu_rcache = per_cpu_ptr(rcache->cpu_rcaches, cpu); >         spin_lock_irqsave(&cpu_rcache->lock, flags); >         iova_magazine_free_pfns(cpu_rcache->loaded, iovad); > > +     iova_magazine_free(cpu_rcache->loaded); > >         iova_magazine_free_pfns(cpu_rcache->prev, iovad); > > +     iova_magazine_free(cpu_rcache->prev); > >         spin_unlock_irqrestore(&cpu_rcache->lock, flags); >     } > } It seems cpu_rcache->loaded and cpu_rcache->prev will be freed in free_iova_rcaches(), and it should not cause memory leak because iova_magazine_free() will be called for each possible cpu. free_cpu_cached_iovas() is used to free cached iovas in magazines. Thanks, Zekun