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 068E4C54E65 for ; Tue, 20 May 2025 23:48:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D9CE6B008A; Tue, 20 May 2025 19:48:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6642E6B008C; Tue, 20 May 2025 19:48:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52B636B0092; Tue, 20 May 2025 19:48:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2FB316B008A for ; Tue, 20 May 2025 19:48:38 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 934E51218BD for ; Tue, 20 May 2025 23:48:37 +0000 (UTC) X-FDA: 83464928274.01.5B518AD Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf12.hostedemail.com (Postfix) with ESMTP id 7010A40007 for ; Tue, 20 May 2025 23:48:35 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=purestorage.com header.s=google2022 header.b=LQJ3ii2K; spf=pass (imf12.hostedemail.com: domain of cachen@purestorage.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=cachen@purestorage.com; dmarc=pass (policy=reject) header.from=purestorage.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747784915; 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=gmpPIOGdXeTJJ62xMcZcuRvAyBH/dJfC/scejZBoQNw=; b=2SFDwlw5nt1/cm+kXxh4guLEixb5DQzPTxSPGEWUggygk4Cmkzi+QUZ3ViWhpYabfEVh2h CmfeCqTMptpenxppi1Bk0oI4ILukBdMaWDbdmfcYrrSRSiX/OS4R2H88/Gh8yi9b9ng4vJ uLMPMlDVJwTPccNRBy47pmvLEqyoT3Y= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=purestorage.com header.s=google2022 header.b=LQJ3ii2K; spf=pass (imf12.hostedemail.com: domain of cachen@purestorage.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=cachen@purestorage.com; dmarc=pass (policy=reject) header.from=purestorage.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747784915; a=rsa-sha256; cv=none; b=OPmjedb0f9QjGMniPU3EaQrAfrfXsCeJCJLkTl2JYN1zaVYVIbBpJh6NX7YJjEzscUVWj1 GjIaTRwisfUZ6oKvmZQoJip9Oowj07Cu49aF0gFviW+D4SpFa12oGCA2mOmDdeRbtgbMA2 SPItQrWDXiTJj3mFrWxKC8VwzTgJsQ8= Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-23228a8acb0so4068915ad.0 for ; Tue, 20 May 2025 16:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1747784914; x=1748389714; 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=gmpPIOGdXeTJJ62xMcZcuRvAyBH/dJfC/scejZBoQNw=; b=LQJ3ii2Kr+ORACSP0gt7AVxuYRAOiH6Qat2eUdh7LnfNB/Ei9PvpIAZONZUOgw/RVq +KewBv69fece9moeJKsUYqHT1V2torx9QJB4/QvaFBeIz49UOWb6vpBKVTadg7Q+Sbmn O1s5U1eIL7l472dcGAKXASqUeWLIeHULBd6pa+JCPKBkm07oh+58qn3QU9IBnfewCcfK SZH6niJmVxU5EK3l6lA4gmzOyIOIb5HNLtSDGq1YYPYc3x6+zNZYMpYivmuEOGSxgQD3 ozOeqrYSIcV9xy8DQLmBQVaEnfXVrg2sigFdZ5iGPd4Why3mRmSnHe3fe7JMeEZBwiwn VGHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747784914; x=1748389714; 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=gmpPIOGdXeTJJ62xMcZcuRvAyBH/dJfC/scejZBoQNw=; b=d0+SjjWSPwXgee3/BaS7AzxHpy9X8ojya56v+V2z/GgDBQzBkrvARtLmE8LeJulsio 99MTnE/sKbb0QrBcKZv4wiGCZN/MD6XECNUMw0tK+AYrgITzCMDFZnGrg9PqvyyeKgo7 1fpnDbVeB7jB915JQSD/SJwajqW5N0xUPIsAGdgwcV2bP5f+IlQlroGwKsGTtOl6LnFx 97fk2DluxwuwcZsvQMf50ZC50fLEWGJN/ac5CTGDK0kRKI6HS9ckBZKveUEEETFsHE/g 9UjgfLsxlc3XoTotgvsf+cASUbgqgwr2Cdk3xcWfC5Gjahe4AXJEept50D7l7MQPAbVx 81Aw== X-Forwarded-Encrypted: i=1; AJvYcCUbGt+hmg7d0y2fKgubHysHKlj3VMvFj+VOV7GGdA0L99gLEHoFIjYmmbcpkhFRvoYl1z/gaz1Zmg==@kvack.org X-Gm-Message-State: AOJu0YzWId9PX45ToB57ARTVrmFEHc9cItraSwhzyQ4oBEgBIrf8O41n 6BSW+OPah6rswz+6xIvFYrRadXhjzyJQHVWxxEhbOwlDqfGYDrexNO1xslCzSeojlBJZ86VtX9+ PhiMKIOZC04srn7FyoTJMVgEUXzYJWbN4x1TuGfCgdA== X-Gm-Gg: ASbGncvc4iRjFr5q7DRbMvMwkJHzly0d1W8k9SXorUUmJqrLdHu708bpd07k29Ecgv4 hMjr5WUs/yHS2BX+H+wkLyHE+ndFrb9OW0sGvBtYPYN7ZJ1MP05B3i/NJ5tb5wyDs0yJlsuSU6Q y0qqS0N/eUOYaD1dKFzPG3kkjDAenXvd61 X-Google-Smtp-Source: AGHT+IGnevNpj9MhG/oplR3edPx4N1vkZ8r3DvX/Pt/hh1ZLYZjWA4tQx71kE9lTxzjC6FvCFNltEPHGjgkNsHUuIoE= X-Received: by 2002:a17:902:ea0a:b0:224:c46:d164 with SMTP id d9443c01a7336-231d43891f9mr87560745ad.2.1747784914214; Tue, 20 May 2025 16:48:34 -0700 (PDT) MIME-Version: 1.0 References: <20250517000739.5930-1-surenb@google.com> <20250520231620.15259-1-cachen@purestorage.com> In-Reply-To: From: Casey Chen Date: Tue, 20 May 2025 16:48:23 -0700 X-Gm-Features: AX0GCFvk7QHDVRdeo5JApsfMv5EqqQlf5IszkCZmZujS6DHh02jCluKF1iE26XI Message-ID: Subject: Re: comments on patch "alloc_tag: allocate percpu counters for module tags dynamically" To: Suren Baghdasaryan Cc: 00107082@163.com, akpm@linux-foundation.org, cl@gentwo.org, dennis@kernel.org, kent.overstreet@linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org, pasha.tatashin@soleen.com, tj@kernel.org, yzhong@purestorage.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam10 X-Stat-Signature: wwpzt7tq93df6fr1dx4zxsokqrkxwq6f X-Rspamd-Queue-Id: 7010A40007 X-Rspam-User: X-HE-Tag: 1747784915-582730 X-HE-Meta: U2FsdGVkX1/FEJnRr68SZ2id1qprmxi19VvYCsCUxI4jKKCh9gulj2dgOIrEB4jfk8P3jVxRxcsuFfdEJCTZKF+E8d6pbd9nnGA/AMNsCxL9Cyx7TUMB/qQedTSxyc/8jinq3+rC7D4OEG8f+bbyQ5RyIT8clbrPk0EVOxTiSn/lCDkFIasxkwfv1T08Cf5m54phOfvCbjkFFoyxAldDD/0xCXvLTTMR4oZ3D76ACCc8sj2gh38Y4ydb6a8EHtSkriLHn1u3ebVskam9b58ajS2gFKy/Sh1GLrvp/TxUErEviQC7b1NOqbFQceAeG0ST7DS83YA3fs3eNc5CUCW2iMQFjgrJZIGV4oo+l/IqlLQ9TMLJ73orUu8Ii+ZrSqJhlneSVUGzd4DIwiURyFt3gTN3I/tjQQ7c+TxI7T2p9hyPcC0WRvV+ihjAb6bCRXgP2z59hOAlEm1ZkpyCo3S4lA2OgS1vXbgBOM+rg7fbhv3LY4EU1zuY7zOUaKdsR4eQlrJBLv3fP/pdjpVmMD3/Ey0T9fN6aS/hbjxo3M0CKUlEe2kkDX2rdboWQ6wJwbLFptCcrABC04EEraE0ppwd+lIVuAEF4uD44DMJcA4Fs0q1BMt5092yRGl+qAk4R6MsoSq+vZqjZDnfTI6MgFaSPfQgZ5QqDseMq0tMqXv3E5/IrOhSOfR9354bprbFB3QEgXfv5aDBVag+NJG2Ofx0oaqUStZecoogP0iMan0VB5k5CkNts4KWy+qvySqe1WBDcbnU8lIBkmzAb8bzqYjOqFyJ8UT4NO2d4qNMZ4M+Bt5oOxunk9TnjZZf805zUuaIy1QJ/dhZOSwNVw7Caa8BOSEm2Dnn5GSZu3HumQUC+nu11g1LYvbeWNBbS5AJ6FrCdB/mAtdfgvFIiVzutGN/OonoYHM06+W+2AtPkVYPIYlTtTfDnlWoUXrmXo3qL1auRnj5Wt7LBpVLvl4Otyg 0V/Z2cIc MqZvWhY7MEfa2Sry3U+m+iP+dzO4lhg+6ukse36m4kHVdGTVYASeqb9LgGWrbfA+qtZDLF3f1Y4/iUyB2LrYgFpCtu0ZKk/+MUV/vVc6dMj4DObZ72Z6PQkpx8mfyH8T3HgzmnKmUrqJBBtTh6dVjvO28Jnnp8ktZGD+OZu1VhqnKZ69M+Z17BeSuvh5UB3HIff/wqNvJ47Lk/2gWD7pfzBvW3PVCvp8n/duE/P22sSORnIdu0G5z3eevROyniwijrra+nkIlYZS7ahOl4Xex6r4rwN3JGHbL/maf+CIYzH/Z15ChLGRf2hT5QR2BK/ATxEbQqed9nuR2vzqt5kh3IrSaVsoORnBVFKIJ3NVnobrOe4JUEtTfD6lX3Qm1XXGh+Gz2jU8q2SrKgl4= 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, May 20, 2025 at 4:26=E2=80=AFPM Suren Baghdasaryan wrote: > > On Tue, May 20, 2025 at 4:16=E2=80=AFPM Casey Chen wrote: > > > > Hi Suren, > > Hi Casey, > > > > > I have two questions on this patch. > > 1. If load_module() fails to allocate memory for percpu counters, shoul= d we call codetag_free_module_sections() to clean up module tags memory ? > > Does this address your question: > https://lore.kernel.org/all/20250518101212.19930-1-00107082@163.com/ > module_deallocate() is called in error handling of load_module(). And codetag_load_module() is at the very end of load_module(). If counter allocation fails, it doesn't go to the error path to clean up module tag memory. My code base is at a5806cd506af ("Linux 6.15-rc7") 3250 /* 3251 * Allocate and load the module: note that size of section 0 is always 3252 * zero, and we rely on this for optional sections. 3253 */ 3254 static int load_module(struct load_info *info, const char __user *uarg= s, 3255 int flags) 3256 { ... 3403 3404 codetag_load_module(mod); 3405 3406 /* Done! */ 3407 trace_module_load(mod); 3408 3409 return do_init_module(mod); ... 3445 free_module: 3446 mod_stat_bump_invalid(info, flags); 3447 /* Free lock-classes; relies on the preceding sync_rcu() */ 3448 for_class_mod_mem_type(type, core_data) { 3449 lockdep_free_key_range(mod->mem[type].base, 3450 mod->mem[type].size); 3451 } 3452 3453 module_memory_restore_rox(mod); 3454 module_deallocate(mod, info); > > 2. How about moving percpu counters allocation to move_module() where c= odetag_alloc_module_section() is called ? So they can be cleaned up togethe= r. > > That would not work because tag->counters are initialized with NULL > after move_module() executes, so if we allocate there our allocations > will be overridden. We have to do that at the end of load_module() > where codetag_load_module() is. codetag_alloc_module_section() is called in move_module() to allocate module tag memory. I mean we can also allocate memory for percpu counters inside move_module(). We have implemented such a thing in our code base and it works fine. Just do it right after copying ELF sections to memory. If it fails it goes to the error path and calls codetag_free_module_sections() to clean up. 2650 if (codetag_needs_module_section(mod, sname, shdr->sh_size)) { 2651 dest =3D codetag_alloc_module_section(mod, sname, shdr->sh_size, 2652 arch_mod_section_prepend(mod, i), shdr->sh_addralign); > Thanks, > Suren. > > > > > Thanks, > > Casey