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 9F5F4D1D876 for ; Tue, 15 Oct 2024 21:08:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D5A6A6B007B; Tue, 15 Oct 2024 17:08:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D0A0B6B0082; Tue, 15 Oct 2024 17:08:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD1AA6B0083; Tue, 15 Oct 2024 17:08:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9F6156B007B for ; Tue, 15 Oct 2024 17:08:55 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8B742418D3 for ; Tue, 15 Oct 2024 21:08:49 +0000 (UTC) X-FDA: 82677075978.26.0FF6726 Received: from out-187.mta0.migadu.com (out-187.mta0.migadu.com [91.218.175.187]) by imf27.hostedemail.com (Postfix) with ESMTP id 835F94000D for ; Tue, 15 Oct 2024 21:08:45 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=XZ2uVbbq; spf=pass (imf27.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.187 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729026390; 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=eSynVCGUx/bo0b2uALTE+vNPBiF1i+qQIdLst2WgqkE=; b=H5oJ3+RpIQrrc1hjuQqQaz5xEDdFPvPm+w257MCfoCOuYJZUZmlHCb1+M8++iiqeGKq6lq hAW/FXhoutCsylK9SAIUWf8LPsdyyR+0qt9aq1ozn1W3ZRG3S2xnxfePDm7JX+t/SzPHuw 4Glf4Z1ON2NEY2eXabtDl3v5/dQPfyU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729026390; a=rsa-sha256; cv=none; b=H0ljyioYlUOkEHyHxcAXMzRfodfsOWDG0HWZufji2zkR+82vsGbusPD3UHVYJBAkAMGZfw UmEE41qrP5LTVb0fHd/dfNyTANn/d/loOgroyxJ+fZ31y3vPgPbko9rO6CtGk7LGKHu9Xb T3YcIi571MH1MI08c6NxWu2Y7SGWnZw= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=XZ2uVbbq; spf=pass (imf27.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.187 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Tue, 15 Oct 2024 14:08:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1729026530; h=from:from: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; bh=eSynVCGUx/bo0b2uALTE+vNPBiF1i+qQIdLst2WgqkE=; b=XZ2uVbbqJA7f6oIYdyRA5IQCTZBHNtxCKfVwUW+gGGJfh9UwP4wYoTAMO2wzcCxYKZ/UTZ TqXufj4xQgoGWWrVNAiLVaOi9ZUUGpGPRe360Wt+GJHPz9foOFziZzPW2LgDB1gmWtG1Wp OFWOS5TLcg1WIfDTJLPlkPjCZrOGd5Y= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Suren Baghdasaryan Cc: Andrew Morton , kent.overstreet@linux.dev, corbet@lwn.net, arnd@arndb.de, mcgrof@kernel.org, rppt@kernel.org, paulmck@kernel.org, thuth@redhat.com, tglx@linutronix.de, bp@alien8.de, xiongwei.song@windriver.com, ardb@kernel.org, david@redhat.com, vbabka@suse.cz, mhocko@suse.com, hannes@cmpxchg.org, roman.gushchin@linux.dev, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, pasha.tatashin@soleen.com, souravpanda@google.com, keescook@chromium.org, dennis@kernel.org, jhubbard@nvidia.com, yuzhao@google.com, vvvvvv@google.com, rostedt@goodmis.org, iamjoonsoo.kim@lge.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v3 2/5] alloc_tag: load module tags into separate contiguous memory Message-ID: References: <20241014203646.1952505-1-surenb@google.com> <20241014203646.1952505-3-surenb@google.com> <20241014165149.6adebbf38fdc0a1f79ded66b@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 835F94000D X-Stat-Signature: 99qtosw1iy1g6993d1sjbbgqgum448k6 X-HE-Tag: 1729026525-789962 X-HE-Meta: U2FsdGVkX18vEFPkwsIFXqfmRwJp/Hz1DJe1tWuoaphS5XerGpIRyq+CMqFDVKS/HpsyHzJcrZA+0lFiwOvOWZji+30V6y4ThYohs2A/L4hM0F3rEKno+t8Zl03qsKSoRCJqKbpwZAid16HnUhz1/zuMoj9k8ySZvdZUhZN/4UllSDeDtL/57UbiLNxUahVoy3TfXZw/rze/CuEnEFZ9UZ+55XMMqH77ZjT0OK1FRdCAJrTi7B6BeIGphl97SUrFiSnWIG96oEUut+b6l7TZp4kOiVtxdQwax7YfDz5O6Ij0fjJbqgIbMzCdnMWSMG+7lJjZAhGTMS8Yy3BzSua1K7e4J4mZrODLxsYcB+8wO2tsfjydSSQ6JsNDFKikdpzgrqCvMtrxIuKovgZAlM1q8iF7y0snztU8icImU4+0uM9xJdfs1lWfrLheCqNtkfqdYcdRiwL+hd74P5FVgexgk3IN25wwR/yjwoTb/vLD5B0GpBhDPMQ8aSDUtze+i1LU9ZaE+88fyN4uS7u+tYsse1ffyN+FHmgVnVtS/sIDCecn/aDhfZFutR0eeq1JfZKI5+6DUBnFgjxoB3gd01CTDoqRbLCzkfqfomOQZuESPAXplbBpI4Uenr0/rQ1k1lCgnh3BYvQ4EglI//FkT+7/Yc4d4ibeEiM91gsqNHGkoq6s6Jy7+YB4odL+pss+4IuzijACZyUAO5sJGNH/bu3dYLlqnzXYQSQ+npXBKUmxJFW/nhn3/3Gn8CgLpHdhdhbxkdwlsS/CD0ip/VT7b/BIW90rirJNR0ZUmAsQJKy+CRHCONZVNIOEHR7uNG00DWhjhnY+P/D/bnf6pfuwyg7FJ4kZYUQMNLADp1vuzuAWmCNIPhCgDa2INTNrsn1H6oimuphiG83b4f/rKbvNf7mkwEgIHNjWot0WmHyrfIzZWMu5kMVlZXvoP1tamCEbtTYtcQhCc64WHNmLl8vcw4l G8fpkanw 6CMTR8z9cfvRUoEOlO3TYNrr8zHTCxsuRRoRJsfle5V6CZLfFtrEaHHeE4APwWYxAK5cmz6V/tNy0C3HDg7foiMmdW3hGDnWFvlNjlzlAhBh7V26b3fgMcIXNwMCgvjohoQEnPY7AT/4vzsf7/UOS3Nyi5EKso5ShXI/Q71RiMFgjPm/+lsuPX9pO+XYS4i7ZC5m732fciciCCstpukEu/pBlp04n3OtyqH+cTdi6NNAh5AuusodkDwezzE8d68k0cCyB/b/HIpSFtn6OvPw3tkme+LWBrfKVaLNBj/jVBbF+OH11vDnyJ2u71A== 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: List-Subscribe: List-Unsubscribe: On Mon, Oct 14, 2024 at 07:10:56PM GMT, Suren Baghdasaryan wrote: > On Mon, Oct 14, 2024 at 4:51 PM Andrew Morton wrote: > > > > On Mon, 14 Oct 2024 13:36:43 -0700 Suren Baghdasaryan wrote: > > > > > When a module gets unloaded there is a possibility that some of the > > > allocations it made are still used and therefore the allocation tags > > > corresponding to these allocations are still referenced. As such, the > > > memory for these tags can't be freed. This is currently handled as an > > > abnormal situation and module's data section is not being unloaded. > > > To handle this situation without keeping module's data in memory, > > > allow codetags with longer lifespan than the module to be loaded into > > > their own separate memory. The in-use memory areas and gaps after > > > module unloading in this separate memory are tracked using maple trees. > > > Allocation tags arrange their separate memory so that it is virtually > > > contiguous and that will allow simple allocation tag indexing later on > > > in this patchset. The size of this virtually contiguous memory is set > > > to store up to 100000 allocation tags. > > > > > > ... > > > > > > --- a/kernel/module/main.c > > > +++ b/kernel/module/main.c > > > @@ -1254,22 +1254,17 @@ static int module_memory_alloc(struct module *mod, enum mod_mem_type type) > > > return 0; > > > } > > > > > > -static void module_memory_free(struct module *mod, enum mod_mem_type type, > > > - bool unload_codetags) > > > +static void module_memory_free(struct module *mod, enum mod_mem_type type) > > > { > > > struct module_memory *mem = &mod->mem[type]; > > > - void *ptr = mem->base; > > > > > > if (mem->is_rox) > > > vfree(mem->rw_copy); > > > > > > - if (!unload_codetags && mod_mem_type_is_core_data(type)) > > > - return; > > > - > > > - execmem_free(ptr); > > > + execmem_free(mem->base); > > > } > > > > The changes around here are dependent upon Mike's "module: make > > module_memory_{alloc,free} more self-contained", which is no longer in > > mm-unstable. I assume Mike is working on a v2 so I'll park this series > > for now. > > Looks like the last update on Mike's patchset was back in May. Let me > check with Mike if he is planning to get it out soon. I would like my > patchset to get into 6.12 if possible. 6.12 or 6.13?