From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm2-f12.google.com (mail-wm2-f12.google.com [74.125.225.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F16E44F646C for ; Wed, 9 Sep 2026 11:47:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.225.140 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788954458; cv=none; b=GEAdLBOZqX+21ZJmaIzjrLouwAUfx1f27qy3WcKwNPm/jt3xAXXHs0oLuGojnmxBkmzGcDZyHA4EM3hGJMU86NSSul/EPGj2GBaXXJriXyLbqFrnjjCyuXWnjc4Slowc2jS1eBewMdKNh8+xeYqPVPvacKowin1YFjVsJCLwsR4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788954458; c=relaxed/simple; bh=9H9sRGfp1ZaqJ3S1urVyd0m8mUDJ79HN5v6laHL1394=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Pc1YVXM2DH92ldGi58Np+WlUSQtb+IQIi5H5BqH9m6l9Riz+BcAWCQRet7HB92eWFJ0wENOV9/pNNasa2/vRLfJKcfSgUk2t7HkpfEwhzdlSA8WPJ3wazxQAAbcTWTK03cWeuSmxgAgy/8CjwF1kUKHeKWb6ET6A+8OGSvvAe08= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=O4pxxQMO; arc=none smtp.client-ip=74.125.225.140 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="O4pxxQMO" Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b91369ef6so864385e9.1 for ; Wed, 09 Sep 2026 04:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1788954454; x=1789559254; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=TIfeIpZ4OJ7Fe6X5EWfuqkVso3+rNzjQrB57cPZXMxU=; b=O4pxxQMO41+iz3VtN/jJVBbJttTgikeiSsv4Ggre72YYrMJ/tDXZ7mOeUN6dOkq6/E E7K0POFY+g45BGV0o17tEoN6NdZr10gTj6YAMXZIuOIPudeASHrRG+J16oT9fCt53AcH gzUqXV4qixX9YI8unNjt9tgolDR5HE8ZvF9XlGYcReqGQQRNMp9DS+Kre8P60QrAnSWE PnauPaWZ9WjN+FEHpxU5nlP4rx3EqBNsD26OKsTY4dJ4fpwMWRI0VflSIbEdmqLEgJge ycZ4y7DuqRIty1H8x1gArtr5vLmagNSOvd+HWjf0sykbdAw9LWjGMbySmEfvU/QWZof2 ff6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788954454; x=1789559254; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=TIfeIpZ4OJ7Fe6X5EWfuqkVso3+rNzjQrB57cPZXMxU=; b=nmTvG9ApaXM1WEisW6TDGd26dC0dRWwU8ZiFwG5KnUSpEuTPD+4iIeALiBGnT5P2Bo ysvTWkntRaJwmtsYf4BakAmAPCPCgzBIJSVHj0+2BwY5QdA0GBUJQ6Xj5/Z+lW1fIswC g5L/EYtuWSMZAAqbmt/OKvYxjhRqGvHQApqywNzytxIRyJwPq5yBzSHxX7AdKnMUO/Tt GwCfju8WwljXJpvTqFZ4SDDpb1DhndxHJZXMdwlEg/h38zXi/RgCA189OqxIgYp+fujC n2ZUFiFToXP+nynOo2rCWIXev8IkDAJt28NoqiqOoZkssKQyFcLrsAt8hbtChzJQ8u/y xzdA== X-Forwarded-Encrypted: i=1; AKwUvBxxs5zeuNjHPX2uTSsB9GbIekpwoALzmWwtHutyg7CmIeMJ9BcWucxISh0OuR75oZ471RlmOWlQt3c1oX30@vger.kernel.org X-Gm-Message-State: AFuF++mp3KnC/Um/BmPwzT5FsdBAx0nHTByySifb6PyqhmmVDiOTnslD QJZpNiUX6VO2YvKVnDtAIKTeTaMGMNQfstpLe+7EF3n/DVE/tkhOEKtzEszp4zCIuK8= X-Gm-Gg: AYBFou2rCZJWHW9iNuaqC0DzLE1DMNmlhYiloJEh+0x6sht+VXEtcNdpZT5C3ZRFGMU 992uTeYHSiG2aUSA/rQjvse1CcWk3fD26iMX8XzgdWnMi9Seq4S+Y3+XWJnFXXjGvNkhXyGEwgG C6vh4YOs/rJDtj6W4bH4UWKcKOYN2zHe7yIhjrWzcMtSgzbELe1hPH5KENnUqLTR1ogWghCjC+2 eDmIol7dSy6vf5dg8l3OPfXpnu240Y7jakb1FhbbLpza1YzQkEBB84kU2lL/XqPC1vnB7MYvXYr fzYll2+0eybAOH0nKLP/XepWoQEGe098YMCXIrp00wbqWGOGjiSkMUhWEhM+Nn1BpMLBp62XH4v D4yctEw745sL75MMFOc3zKhbWkRm7UTWkOaTk9j/4IISK2tL5PdXp4q1TMdu9KM91l4AmjLNPMf uayeDjsZ+XlUiXUj15WU5XHwRaIvZIg6yPvnEprwIW3qnd4kFQ45oflfg5+G1WePQUVNOz2xqeN nWNdhgIuGIuFqrhRXEDN1ycF84DSljz/1E= X-Received: by 2002:a05:600c:5307:b0:49c:f617:7cf with SMTP id 5b1f17b1804b1-49d25871d73mr12852825e9.0.1788954454028; Wed, 09 Sep 2026 04:47:34 -0700 (PDT) Received: from ?IPV6:2a07:de40:8100:0:89a9:fd0e:583d:4a53? ([2001:af0:8000:1409:193:86:92:181]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cf7740d44sm1017732865e9.15.2026.09.09.04.47.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Sep 2026 04:47:33 -0700 (PDT) Message-ID: Date: Wed, 9 Sep 2026 13:47:32 +0200 Precedence: bulk X-Mailing-List: linux-modules@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 4/4] module: allocate codetag sections before the regular module layout To: Hao Ge Cc: Luis Chamberlain , Daniel Gomez , Sami Tolvanen , Aaron Tomlin , Suren Baghdasaryan , Andrew Morton , linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sashiko , stable@vger.kernel.org References: <20260908092412.115953-1-hao.ge@linux.dev> <20260908092412.115953-5-hao.ge@linux.dev> Content-Language: en-US From: Petr Pavlu In-Reply-To: <20260908092412.115953-5-hao.ge@linux.dev> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 9/8/26 11:24 AM, Hao Ge wrote: > Whether a codetag section goes to the codetag region is decided by > layout_sections() and asked again in move_module(). A concurrent > load can shut profiling down in between, and move_module() then > copies the section to offset 0 of its regular destination, > overwriting whatever is there. > > Decide and allocate in one pass, before the layout. Allocation > errors fail the load. On a tag area overflow profiling is already > disabled, so -EAGAIN makes the section fall back to regular module > data and the module still loads. The reservation is released and > module_tags.size rolled back, so a concurrent load which already > passed needs_section_mem() does not skip vm_module_tags_populate() > > An SHT_NOBITS codetag section is zeroed explicitly, the tag area > pages are not zeroed on allocation. > > When profiling was toggled off the overflow check did not run, a > module could load with more tags than the page flags can address, > and re-enabling profiling then silently corrupted /proc/allocinfo. > The check no longer depends on mem_alloc_profiling_enabled(). > > Based on a patch by Petr Pavlu [1]. > > Fixes: 4835f747d3ed ("alloc_tag: support for page allocation tag compression") > Reported-by: Sashiko > Link: https://lore.kernel.org/all/499bb60c-c6e3-43a3-bd92-95a0567ece5e@suse.com/ [1] > Cc: stable@vger.kernel.org > Signed-off-by: Hao Ge This looks ok to me from the module loader's perspective. Reviewed-by: Petr Pavlu -- Thanks, Petr