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 759ADC3DA4A for ; Tue, 20 Aug 2024 07:26:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E92006B007B; Tue, 20 Aug 2024 03:26:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E41C36B0083; Tue, 20 Aug 2024 03:26:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D09F06B0085; Tue, 20 Aug 2024 03:26:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B30046B007B for ; Tue, 20 Aug 2024 03:26:42 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D9D001418B1 for ; Tue, 20 Aug 2024 07:26:41 +0000 (UTC) X-FDA: 82471791402.03.87FB676 Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by imf30.hostedemail.com (Postfix) with ESMTP id E896A8000B for ; Tue, 20 Aug 2024 07:26:39 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=x+K2G9TD; spf=pass (imf30.hostedemail.com: domain of surenb@google.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724138721; 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=LN564zYHb/q+BN0L0S3sLo0tgai+pv6UXeCiHGIBfXI=; b=NL4jp5xNhdnET8TvH3JiwuDoGTpp5IRUXDcYAn/0sX5JEttN18DjJdZusMrST/1Y/JlxeA J+ew+wmPUjVXDWgQNTxKg+jQXgTf6UG3gq39LOlP1g2N5jSTWhwZLdpw+xMlS4H6pELJuz IaJVRko/LI6XJnT5WCxz532hXwtiNRc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724138721; a=rsa-sha256; cv=none; b=Be31flntIdjstvlKrMoEOoKdiNo3n0FfUgYOgTxeC6bNU906HbH7kFoRcd1sBY6Gi8sGeb fA1B9V6V8B6W8euHWtxPv+IQTHk5jvVoIZsjeF5tmiQ2mUDPFODS+5nsQyqOIhM7KVoSHF mSK44GcwWUP+QTMFa5U2HSSVMIJKSGs= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=x+K2G9TD; spf=pass (imf30.hostedemail.com: domain of surenb@google.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-6b3afc6cd01so24355747b3.1 for ; Tue, 20 Aug 2024 00:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1724138799; x=1724743599; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=LN564zYHb/q+BN0L0S3sLo0tgai+pv6UXeCiHGIBfXI=; b=x+K2G9TDFG/3I1b2kodoARIzVtVMNphspDeriSrsP13yKOD2e1vACcYJ5hc1Y9Bw0r Q4uU3DoFmcPWtayQjMn8TqvXZfbxyMHnzToREbwmOWgDIYwxDtMilCs4DW0SjJxvHOZE cK6pgO5UuXNHzcIdcNftd6MtOPp9h7iu7POuChVxSh4ZZ3WUKqtsJTKz6z+L4im5/jQ1 N+5Z5pNMOeLrMpGmmRx7W8MCmVwBivyMFCdvn/FitDcwj+uhD0rxP054N+m9XCL8b235 QJ6vOtKuwN6kquBety2+ZYfeiZuZy8GEinuLJ1TIl5RYLzyTM8AZO7OixAteKy75d+z0 OzuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724138799; x=1724743599; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LN564zYHb/q+BN0L0S3sLo0tgai+pv6UXeCiHGIBfXI=; b=EL2ARih1Vm2qId7ee/gdMuFDws0xn/pSDP8sXMKQNfiGVm11oCe/hZNHE9oC5ZerJA v0YJxrYwGxXF2oJoX6DoT4uUFqYB7L62BwPw9nKUNs+UHBYkirK7tx6s2t5wX/LQ9Ce0 EX1Vc925zdv0IMzCY67PUTp8s6A2Kn+u52AiMUniuwTgNlC+H5pxtttTbaF6cHm8/fky Ie5kwZPpWghqt3pi8mjkXOVjppd64Bu7M02HlZJr6ETzEQukQwwy+mmMt43lEWsDKIRR DHUKO9a5ALWcRUpDOKOca0FLjsn06Y3AH7Q7sC9z51tS204ludkMbiFq6X89ZBdswprn brow== X-Forwarded-Encrypted: i=1; AJvYcCU5dXyEPRDlhd35CJWZRx4cZXx9vpgE2vwum6RG6ZP1j2FrtU9tdvMs4w3HSXhQyqJ8YLszMG71DuKfQIq4efOtL1A= X-Gm-Message-State: AOJu0Yw2WFSibczRDFsUjiCTXPCnDmbco0f+z2iXbM093zZUpYYmg8fn VdmxhtUfUxtvsGNjZ5+uj7RvGPP1mJiiNOVAYrhb0gPkk6AwkhhL1PKcu+uDi/dNoIhqEfZhKLO mvZW45JHf1Ie6dHJDA4dHMs1BmwiYmxBLGkXc X-Google-Smtp-Source: AGHT+IEu4NsnZWpz9MZCaZucuLVy0UjltYOjyQoU56+siXBz2tCiizAdvhgvEd1X1U+P3/g9CXL7Rc8N12MGbs0TTZg= X-Received: by 2002:a05:690c:2c92:b0:64b:1eb2:3dd4 with SMTP id 00721157ae682-6bdcf2e6c41mr15550867b3.8.1724138798431; Tue, 20 Aug 2024 00:26:38 -0700 (PDT) MIME-Version: 1.0 References: <20240819151512.2363698-1-surenb@google.com> <20240819151512.2363698-2-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 20 Aug 2024 00:26:25 -0700 Message-ID: Subject: Re: [PATCH 1/5] alloc_tag: load module tags into separate continuous memory To: Mike Rapoport Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev, corbet@lwn.net, arnd@arndb.de, mcgrof@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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E896A8000B X-Stat-Signature: wbiw66rbrkds6yqb1fe3mpm4j8uuxom5 X-HE-Tag: 1724138799-807464 X-HE-Meta: U2FsdGVkX19STu7BQEpSLpH4KSfVdZohiFoqFWCbqJDuf93nwRHYzPU3PrugKHTpEXfgxrumRNBhYANChuHXdDyF+0YBDmkNAyr1CdVpSAMMrBK3Dwx++Aqk0o6rSHFyEeCGPsytQ6maFMm5ln3WdBjfw2wSlrW5dQC8te1r4aqcwU1qpLecqlZP1VipwGxsExCeiS8eRCjFkmhSqEu4ntcbbA3JsIFM3A+Bvp7+24vobz61aiyGseebtWxQagJ0l2WlWSnCH/m+GJ/Li8kE2P4eS1kLJS3DRnqTQGgJ6i0qREEPeR6VtZ8keI1wrUn1epAf+A2mawDkkiTVOpVRjKlrEKfRZI4DHrRKQSTH+aTP5rtJAEjT6UZxVK12dmRP/LFLQnTLJMTGW3bSXE5x1Wfe4bNp7JOxCdkNPpFo4WrRt4alcaJgzyjzPD3Gh1wTyhwBMg97oDSD7P3nVYRdUvIQloraAgfPrsrer3lmUGUL/7WiOdVrLBcj/dYS0n35R7pCF/M50oNFcaxDLC8Hkq9xHZLXRPRer78dtx9/NZdkxZ0YzPy1QuRdbOX3T80Vsngca/gzhaD/fMyfPlJAvC5jxo25wZnXaDoq6lrGnUZ8JxqEN8l3vZu/p5nXfa7KvpWYDZ4VsbCUPR5v0/o5EM33+Q0Dm5fporJozNn/98AGl3uptwXdOcrwa7W17FIWJyi/27qIGtq6cfeiOeaXSSoBNWRD3vbQveVi6eOfaK6XKTVCvW1CMfGcTaCaoTIcP4KbVhWeFr6e7VXyhZlyngdNOyvgFeFJ+r8lETxIViruiFBnPg0vNwg4UYy0nrep2gNKHLXO/82ZbS1mbajszxmtPhkTd4vnWwlc2jeDBO7bXhZ41+rFMdBl3eaF0cBg/poSqWRC77zjVrfLsaAcznidBWyHxp8wlychjEbLoMraAOIy5NX7K7cM5fv9XwywnNCl7dS+406vKjd8W7h LXIlKXRG e79YOlHhx7a39X3NOshyrr6fOmby2o/6W1KIpFS1b+BwAS4onPJieJ5Eb0/cZ5cStpdUK+oEgs1sJzj06yRd/fGZUQ0pSNepB8vXZKIJWURlSCTO9TcKmLGcz5yvieCLbhnyLh6kNbQ1zMOYzDUlSNktV+G80hZd+Sg7U7xv7tFcGtHy81T2a9YRZ/lf/RuvvVbCLRq+VetMXdgJUhpRr14PO9B+e1uLaZ5B8/7+G5cGeqmh7a/gyyjJpgIAOyb5jDYQZCiVpdvPExI1AdsCOx6rowAwg575XWMp5TK8m4Is+5OA= 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 Tue, Aug 20, 2024 at 12:13=E2=80=AFAM Mike Rapoport wr= ote: > > On Mon, Aug 19, 2024 at 08:15:07AM -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 and max_module_alloc_tags kernel > > parameter is introduced to change this size. > > > > Signed-off-by: Suren Baghdasaryan > > --- > > .../admin-guide/kernel-parameters.txt | 4 + > > include/asm-generic/codetag.lds.h | 19 ++ > > include/linux/alloc_tag.h | 13 +- > > include/linux/codetag.h | 35 ++- > > kernel/module/main.c | 67 +++-- > > lib/alloc_tag.c | 245 ++++++++++++++++-- > > lib/codetag.c | 101 +++++++- > > scripts/module.lds.S | 5 +- > > 8 files changed, 429 insertions(+), 60 deletions(-) > > ... > > > diff --git a/include/linux/codetag.h b/include/linux/codetag.h > > index c2a579ccd455..c4a3dd60205e 100644 > > --- a/include/linux/codetag.h > > +++ b/include/linux/codetag.h > > @@ -35,8 +35,13 @@ struct codetag_type_desc { > > size_t tag_size; > > void (*module_load)(struct codetag_type *cttype, > > struct codetag_module *cmod); > > - bool (*module_unload)(struct codetag_type *cttype, > > + void (*module_unload)(struct codetag_type *cttype, > > struct codetag_module *cmod); > > + void (*module_replaced)(struct module *mod, struct module *new_mo= d); > > + bool (*needs_section_mem)(struct module *mod, unsigned long size)= ; > > + void *(*alloc_section_mem)(struct module *mod, unsigned long size= , > > + unsigned int prepend, unsigned long al= ign); > > + void (*free_section_mem)(struct module *mod, bool unused); > > }; > > > > struct codetag_iterator { > > @@ -71,11 +76,31 @@ struct codetag_type * > > codetag_register_type(const struct codetag_type_desc *desc); > > > > #if defined(CONFIG_CODE_TAGGING) && defined(CONFIG_MODULES) > > + > > +bool codetag_needs_module_section(struct module *mod, const char *name= , > > + unsigned long size); > > +void *codetag_alloc_module_section(struct module *mod, const char *nam= e, > > + unsigned long size, unsigned int prepe= nd, > > + unsigned long align); > > +void codetag_free_module_sections(struct module *mod); > > +void codetag_module_replaced(struct module *mod, struct module *new_mo= d); > > void codetag_load_module(struct module *mod); > > -bool codetag_unload_module(struct module *mod); > > -#else > > +void codetag_unload_module(struct module *mod); > > + > > +#else /* defined(CONFIG_CODE_TAGGING) && defined(CONFIG_MODULES) */ > > + > > +static inline bool > > +codetag_needs_module_section(struct module *mod, const char *name, > > + unsigned long size) { return false; } > > +static inline void * > > +codetag_alloc_module_section(struct module *mod, const char *name, > > + unsigned long size, unsigned int prepend, > > + unsigned long align) { return NULL; } > > +static inline void codetag_free_module_sections(struct module *mod) {} > > +static inline void codetag_module_replaced(struct module *mod, struct = module *new_mod) {} > > static inline void codetag_load_module(struct module *mod) {} > > -static inline bool codetag_unload_module(struct module *mod) { return = true; } > > -#endif > > +static inline void codetag_unload_module(struct module *mod) {} > > + > > +#endif /* defined(CONFIG_CODE_TAGGING) && defined(CONFIG_MODULES) */ > > Maybe I'm missing something, but can't alloc_tag::module_unload() just co= py > the tags that cannot be freed somewhere outside of module sections and th= en > free the module? > > The heavy lifting would be localized to alloc_tags rather than spread all > over. Hi Mike, We can't copy those tags because allocations already have references to them. We would have to find and update those references to point to the new locations of these tags. That means potentially scanning all page extensions/pages in the system and updating their tag references in some race-less fashion. So, quite not trivial. Thanks, Suren. > > -- > Sincerely yours, > Mike.