From nobody Fri Apr 3 11:10:03 2026 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) (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 8994D2AE68 for ; Thu, 26 Feb 2026 05:47:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772084839; cv=none; b=rHAW68w9UysUcFWPSL4192tDCqCPoWZeQ5ngAgvLeAEng/ZvPVcbYwUOM//ACvvTQ+kxY0PZbxPNdkrECCNIIJa7qSVmRDcDDM+CPAT7crCP8uj53nBUy/wKyOZc2vxVJ4IHGDSfUC8rtlepLMCK1TFtdV2lxT4rSib1sadWKY8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772084839; c=relaxed/simple; bh=c9l0UHG14AIH+Po1eA6ZIQAPObRrzm8jIgoOTdACxKM=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=Mldz8Xr2/OXEf3I4+KVtOK3x+RdXCrP3IOtMDvLLzuvXwYnOjxr6iuRRYz+SBN1occzJDtbX3w0FKNPfFGMETSayFNoaTKfRS6g0M84dNuNWfenvyUYmf6wg50/vdbp26Rm23Xpi7gJVaaM8TBUo752OVoSrA5WotJyzvjjz8MY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=aMvjdYNj; arc=none smtp.client-ip=209.85.216.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="aMvjdYNj" Received: by mail-pj1-f52.google.com with SMTP id 98e67ed59e1d1-358eac0571aso241507a91.2 for ; Wed, 25 Feb 2026 21:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772084838; x=1772689638; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=m90N85NLQCkdCZjrPAkhaouebwaruDVu5ZveDlIpaQQ=; b=aMvjdYNjNjbKSwgFeyysCzAoVfRvji32Ipm0HT+gPQFHsdmXW24U484jwdB0n6+Qe5 aEjSgsCGFRjp8UovsQl/WJ/TsFy+Xfl+3U98K/dyd89/0w5Py4mPfAsAIVoWLWghvk7o oj2is1pZp17a803PsEm9dbT45RVZ4GD9JkurYS/Zgl/alzDt5h5U9QqcznGutKbSbpqO pGj//EmePCV+DbXLd7swLhqOxafY4p4T6USgRyJWfkGZKPRuifgAyBU2xIIQgorwdGe3 /guvuxUGTQo2wWGPjp/WrtW8/G+3idEbPNT8mWHsVp5FvGiFl3eWEp9TyLZXUxjCuaNa q/HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772084838; x=1772689638; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=m90N85NLQCkdCZjrPAkhaouebwaruDVu5ZveDlIpaQQ=; b=i/yjGlZnlzVSEA0uKNmjZTEB/842ZKpj7wjc9qPwfJ/Ia/WQ6utP/ui8S+4IRyLbw8 jWYG/2zCKiv/UW0O7gDMIlK72lNweY6oJQRZLDtHqanuYWINtlQGOIJsMkrmxmXhsCae lnQh9aogtBtK1LHSqOHaB3SSZkPkqfrNFbVuJ0d5k8hAxQ9mJRr4W/IqvMd+chgnGKmO gk0N5Jx3Uf24pCHPlEuvgUyZZfBrRazXbqNe2HYKo3rThhQ65vghKTg3PbeWDJhAYdjm 1huzW7xMt0vn4nBDR1zzuuignl8IVIcNdZ7/eGbFBMM47Ojf4te5zvyX1WjwOlM4W8cF sblQ== X-Forwarded-Encrypted: i=1; AJvYcCWIPGZTmEGZ5bmH9ezh2ftoBzWhZI8k0saWurLdbLJ19RtNfDz96wjbrVWgZhPT3y5mNiA1OLizQvgXSPw=@vger.kernel.org X-Gm-Message-State: AOJu0Yygq2iPEANaZF6j79oZPhkTzi57ShfqYeF0XHOGvz2HJlV7n2fX B6Gj3hQyVdOGvpVgfDQv72qRj/z22fRFGyTuM+uOGi3LxKnD3h3tgKor X-Gm-Gg: ATEYQzyBWS79wAcxuamQTsRg517LoYR45iej/Qd71N2P4wYOOZZVYFAR6yNG4CUr1bs 0Wg9oTSNn+MwqVx+PUSc7ywH0h3rTnglMrqpci2GYH++u4oQwohWTvtjcu5cGfuxex5MhudRi+y 4+QctpgzQqNB5zR8qP3wdvyoLXZsGISphcunV7M+cnvRRfUjkgfyLknxdQVbnEjUiJIXx8BWWDH QJE5c35rxzVsPD5CLoQsTsD1sFVJt9Qgff5A0Kahcc5BTwkonvfyqsRX6/sEmIm6GKsFnibGPx/ Yf6Lg7LQE1JoxnMKV/FwmXiHEyhc2z0LXYMrRS+jrWua/rLZ26X5gMY5++BxIMmtFhCClB4cNtD O7931Hh4WR9qcnttsaD86RwUqu3JYfUk80SLcDd15I1oUbgPCC5S3tvQNtO9BCX/Z3VpwLHNOn0 dCTd4CWKn8YRnHJp/IkWbs7qli73xh6LHAZs79fzUWKL8BAMB4IYLar2Xr4bo= X-Received: by 2002:a17:90a:f94e:b0:354:c629:efaf with SMTP id 98e67ed59e1d1-35928c4bbc3mr2519336a91.35.1772084837867; Wed, 25 Feb 2026 21:47:17 -0800 (PST) Received: from hu-ckantibh-hyd.qualcomm.com ([202.46.23.25]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-359037afe31sm4471199a91.16.2026.02.25.21.47.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Feb 2026 21:47:17 -0800 (PST) From: Sanjay Chitroda X-Google-Original-From: Sanjay Chitroda To: Vlastimil Babka , Andrew Morton Cc: Christoph Lameter , David Rientjes , Roman Gushchin , Harry Yoo , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Sanjay Chitroda Subject: [PATCH v2] mm/slub: drop duplicate kernel-doc for ksize() Date: Thu, 26 Feb 2026 11:17:12 +0530 Message-Id: <20260226054712.3610744-1-sanjayembedded@gmail.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sanjay Chitroda The implementation of ksize() was updated with kernel-doc by commit fab0694646d7 ("mm/slab: move [__]ksize and slab_ksize() to mm/slub.c") However, the public header still contains a kernel-doc comment attached to the ksize() prototype. Having documentation both in the header and next to the implementation causes Sphinx to treat the function as being documented twice, resulting in the warning: WARNING: Duplicate C declaration, also defined at core-api/mm-api:521 Declaration is '.. c:function:: size_t ksize(const void *objp)' Kernel-doc guidelines recommend keeping the documentation with the function implementation. Therefore remove the redundant kernel-doc block from include/linux/slab.h so that the implementation in slub.c remains the canonical source for documentation. No functional change. Fixes: fab0694646d7 ("mm/slab: move [__]ksize and slab_ksize() to mm/slub.c= ") Signed-off-by: Sanjay Chitroda --- Changes in v2: - Instead of removing the doc comment from slub.c, remove it from the public header as suggested by reviewers. - Follow the guideline that kernel-doc should stay with the implementation. - Updated commit message accordingly. - Link to v1 https://lore.kernel.org/all/20260220124243.3264133-1-sanjayem= bedded@gmail.com/ --- include/linux/slab.h | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/include/linux/slab.h b/include/linux/slab.h index c5fde8740281..1c8c53b068b6 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -517,18 +517,6 @@ void kfree_sensitive(const void *objp); DEFINE_FREE(kfree, void *, if (!IS_ERR_OR_NULL(_T)) kfree(_T)) DEFINE_FREE(kfree_sensitive, void *, if (_T) kfree_sensitive(_T)) =20 -/** - * ksize - Report actual allocation size of associated object - * - * @objp: Pointer returned from a prior kmalloc()-family allocation. - * - * This should not be used for writing beyond the originally requested - * allocation size. Either use krealloc() or round up the allocation size - * with kmalloc_size_roundup() prior to allocation. If this is used to - * access beyond the originally requested allocation size, UBSAN_BOUNDS - * and/or FORTIFY_SOURCE may trip, since they only know about the - * originally allocated size via the __alloc_size attribute. - */ size_t ksize(const void *objp); =20 #ifdef CONFIG_PRINTK --=20 2.34.1