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 DF3BD48F01A 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=1788954457; cv=none; b=UrIN2Q0k2/2sltYlKHuqHt96b+KrtQ8qvt4lTFWx0gmH1JsW+6tE1XMuskswWhL2t1E7VuDStuLLZ3EKjXJq6zCXZJFAFQBChCr9C5rKDmpvVYCKzslnNxKQo8SgfR2zDbX/UYHeHwmJjTprNbhou/vSlLDMFECaLMLvD9P9Pug= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788954457; c=relaxed/simple; bh=9H9sRGfp1ZaqJ3S1urVyd0m8mUDJ79HN5v6laHL1394=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=camy5lsb/2AjfxRFE4exePK39s3/SMWazG73HV3ew2aPS8BcQYAcEJKn00j2afl9lBEcS+2mNNnGbN26PUzJOjkLfcIpVn1H+RNpzIUB8wc1uZzgm6ElXeGt7KVan85mnfk7OUNDAG+n1DMsnap+KXTa7ML333zVWRROi0EWdpg= 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-49cd38e0e5dso1416715e9.2 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=SbTm8HtZ1V9ydl4pAZQb1bxDqBwuDPUlBaVc1AHLPEcg1vZY3DRpL3xA8wWFGJ1aM8 +B3AgV4sCbSZf24TOTxSqt3pl2s1ONJ5rioEVMb3xqcvaZEXny78Gicm22qRwOKb4IUk S4lI17nlPv0aInR/RUX9eSlS9MuyvKKWOEMmD9OJb10SpRkr+AH4MifD1hYIi3h86fQv ELtUNXGEaC4MOqq1gkMCD0KvZi8dDzqGZ+laZ+Rtobt9dg5dSlwmdb8bVlvJNGF53ApP sqQL5HbGHVZVoCXvHinmV11X5HfJ6DAsQrljYXSGzRAFOsEiqgJsu5coh3UT87FAx9l4 q5vw== X-Forwarded-Encrypted: i=1; AKwUvByc8WbwGhvEI1PXsUV5ph8xUN43K5scyqYlfVlEjztxzMMgWO97COFMZtiNA3+AO02wmEzYvd8fwNO2Gp8=@vger.kernel.org X-Gm-Message-State: AFuF++lIgBkcKOT4tb7+0pZjlGuukR7rL48vgFS1Osq7qgrg+j8e6FSl mC0ymzafLM+rfCWFu8wjrb5/r0OkanKSxlMAoeUZuv0hJstjZBW8B1WpBB3p3R95z+U= X-Gm-Gg: AYBFou1hoMT3zO3CUuOG4Svu0ipGUjFB87d+jtb+5cMOt4rfOfCX02L88jXbgExYzMK AOw7s7sElG8LZsE2Cp3GZ9yTUN7WBYy9vrLdODCdVjv020rKGY0gV3x3LBjWgwEkwvbT2F36jiR zpWC9LH5GTGz+cYztsWRIPf8eAEpAk/qXp7L3FDlFiNTHzZaA/Vq9QcpFR9XisfF5gjzTNaEune 7pgWnUiNFBIfZ58sAga/MvuJuGryvXTiRC17Q6XB7/iN5GVMZ7GvXMkHT5pl+96OpoMHlk1WPmz iugrRiHStIw7zlN+9UQNwGaBr6Qhad2DewbrtP0oANmLmVWoPsQcwiVsXR1MjAupd11vwgGzS8k KFZ+di573ZIykYy7/R472nuYaF+EH6w9Ca+ospDjrIVnhsI9s9U30t4r+8SmlptemA8whkrnKQA qixlmCVUitsSCuwl4ahZetbpEj1mj/WNAXSOcZWzwBwJMTwLHDeB3xI1kQsbvipodSED4GnqvHR EQMnj4K6m1uSDJaOfen8cmIdDTUQTjwmJ8= 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-kernel@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