Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Nick Alcock <nick.alcock@oracle.com>
To:     Nick Alcock <nick.alcock@oracle.com>, jeyu@kernel.org,
        masahiroy@kernel.org
Cc:     llvm@lists.linux.dev, kbuild-all@lists.01.org,
        linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
        arnd@arndb.de, eugene.loh@oracle.com, kris.van.hees@oracle.com
Subject: Re: [PATCH v5 6/7] kallsyms: add /proc/kallmodsyms
References: <20211027174706.31010-7-nick.alcock@oracle.com>
        <202110281914.lE4Jfz7P-lkp@intel.com>
Emacs:  or perhaps you'd prefer Russian Roulette, after all?
Date:   Thu, 28 Oct 2021 22:52:13 +0100
In-Reply-To: <202110281914.lE4Jfz7P-lkp@intel.com> (kernel test robot's
        message of "Thu, 28 Oct 2021 19:36:46 +0800")
Message-ID: <878rycrf5e.fsf@esperi.org.uk>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2.50 (gnu/linux)
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?CbuLGPWubd/r2iRmf0qeFGIgSVq3jnK7BdZWqOIoIwoBmkRmUZxL+c6/zcey?=
 =?us-ascii?Q?g+5dNjtQxX/dvZPMI0sWTZ0wQNwrikkW+2xddPskpTnj4utUmukFUE34t0ht?=
 =?us-ascii?Q?5n9snDZtZsLr9n+a46ZqCPfEzeqv7crvWs/5z75vlZY+leJr8GW4MEKV91v7?=
 =?us-ascii?Q?KN1zp5U0rA6xASQTJdDn4WI8Y0xm3VxZp/VATy/LlDeznY3snH2noLt09YWP?=
 =?us-ascii?Q?r0UrGVxGzGfF3370Vv8BxwI6KsfPdKagDYSJJL5XtYLGfyZbBm1oimBUhwJ7?=
 =?us-ascii?Q?/EsL4f/c7oBlPDAc2dnFUQYsn+8GnCYZBfUlB2BUEJYHTbSz9XLykh9YdFAz?=
 =?us-ascii?Q?EGzvODWoBbxiBTshT60rYWiUpD820M0RAyLijhX5sri3aRxRSQ+JZwDufxHE?=
 =?us-ascii?Q?MNX0FLQ4yOPs+Pz9iq51GJiYtIYFhYCFVRwdfgGawSVdSypL/5qGpV2J6Uzy?=
 =?us-ascii?Q?6TguRV9V7KWochOuIXnOnGr23k0QComkHcoS1fqsZ66eU/VcnZNaqbk0kq/d?=
 =?us-ascii?Q?Rq/44wNhZutYSI8MyRloCjqPYLGj7NtNqOM70VkyeVdzc7Ikc4XfSK1qYU3E?=
 =?us-ascii?Q?5roNTi2/aMx7FObSgG3fzp9KOKNYrxIweLf7WQUHvJZALblxgioLjwo4b11d?=
 =?us-ascii?Q?LA5JUawVmrUy7aenaFsPzCAr6NT7vwqnMM/cnJ+kTVpafKi3gDMJQh05ML03?=
 =?us-ascii?Q?5XjgeAT3XVgtIGhII614jl4ySO3D83tjBZ0Z/b901/C96xE6Swu1yadM6qb2?=
 =?us-ascii?Q?pz3WsEW079wGZ+eJeAapv3je6rLgqdDnmG/2NoG/Nw20lrTWZNLclLi8u42F?=
 =?us-ascii?Q?vDgwajyexwMKLQYOhrFKPjk9MaQRJBf/Q/PNl/vVnObudiYOoAv5ow1w/6BQ?=
 =?us-ascii?Q?XFQPNHXn2MWqb2XEBzo8NcKjuI0h8x94cXy3z388qbv7K5ufZ7J4bGtTczmL?=
 =?us-ascii?Q?tbqwZhRxseSyY5JPTVyTcnFwFAo9NlfxgpANV7YP6BxP/qr0RUvqMVTTP8m5?=
 =?us-ascii?Q?vPaWMug2Broic6/SHJlEWeu/pybWqFzFuO82IyB8dSc/7kaWIMmMaL7azrFj?=
 =?us-ascii?Q?D1KS97HtBoYrT0Zjr3w9J2gC2YG2sK0h9uKqqUlf09/S2MMyYA4emycop5hn?=
 =?us-ascii?Q?v7Wg38Q47yAnR0RIaCJ7kkb+2hnCLfr/RJgy1p9cr/6PU3O4H59t4U8EzDag?=
 =?us-ascii?Q?FigFbnANR8JkFM42YlgYA5iTYUjUGvSxoHM0RoGG2cCkZdzQ/0iefZPDzjnI?=
 =?us-ascii?Q?tgFfMULqjotYbMoGPqN7s8uOCcHN/8GvP4Z0h+OjwibE1RTJVXorKN3FS3OX?=
 =?us-ascii?Q?G1bH3AqTYRidc06mHediuip9wR7C5O7ThXcWVx+29nQ4fzjzthLLTUTHp5i4?=
 =?us-ascii?Q?zolIQgZbT1lfMe3C25UcdO42Q4vt8Skh3bY58rNP9Jj6+nFnXLF22Q/vwQJ+?=
 =?us-ascii?Q?WSO6xm/oNDUS40pmJk/LuLGgzB/yL5Bu1i+ngC12H1tDaZydVPnFO+Oz/bU8?=
 =?us-ascii?Q?6KIUDvfFfDPi1VlSU0Y9NPBeQKxY3a7cmPYIi0LUi7w3iBofxEO/JLlyrPmd?=
 =?us-ascii?Q?y0zkgcrC5yX0kpn5fA1bfnx9h75aflB47KJS8BUnnl/WIAvkCd5bLutt2d2P?=
 =?us-ascii?Q?SQlpDwMXqEUu61Ir9f6gz9ZjHQ02V96SF8Rjxy3xq6gQ?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8508f729-6473-49ba-d7eb-08d99a5d37a1
X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4715.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2021 21:52:20.8363
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: JAd7sLt32B85GSYgy0LYZPXpuDrLY6DvaHUC8Gql+BonUaQpHw7HGCmqwO6FoZeRCkEE0p4HF2OOHa0U8p1SNA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR10MB5606
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10151 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=999
 bulkscore=0 phishscore=0 mlxscore=0 spamscore=0 adultscore=0
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2110150000 definitions=main-2110280114
X-Proofpoint-ORIG-GUID: 9cPEcEW13fDA7izW5u95ZhaNdu3uROZP
X-Proofpoint-GUID: 9cPEcEW13fDA7izW5u95ZhaNdu3uROZP
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

For reference, and to be maximally pedantic:

On 28 Oct 2021, kernel test robot said:

> Hi Nick,
>
> Thank you for the patch! Perhaps something to improve:

Nope! This is a (very small) flaw in the !CONFIG_PROC_FS case in
include/linux/proc_fs.h. (I don't think one can seriously call it a
*bug*, as such.)

It's not a problem in this patch.

> config: hexagon-randconfig-r041-20211027 (attached as .config)

This config includes: 

# CONFIG_PROC_FS is not set

> All warnings (new ones prefixed by >>):
[unrelated warnings snipped]
>    static 
>    kernel/kallsyms.c:1054:30: warning: unused variable 'kallsyms_proc_ops' [-Wunused-const-variable]
>    static const struct proc_ops kallsyms_proc_ops = {
>                                 ^

This warning already existed (and doubtless countless others just like
it all over the tree in this configuration).  This is because
proc_create(), in the !CONFIG_PROC_FS case, is a #define that just does
nothing: so the compiler can see that none of its args are used, and
will complain about those that have no other references. The proc_ops is
almost certainly going to be one such.

The new warning is just the same:

>>> kernel/kallsyms.c:1062:30: warning: unused variable 'kallmodsyms_proc_ops' [-Wunused-const-variable]
>    static const struct proc_ops kallmodsyms_proc_ops = {
>                                 ^
>    3 warnings generated.

The kallmodsyms_proc_ops is obviously doing the same thing as
kallsyms_proc_ops (because it has to), so it gets the same warning.

Short of wrapping every single declaration of a proc_ops structure, and
every call to proc_create, in #ifdef CONFIG_PROC_FS (which is obviously
gross and exactly the thing the macro in proc_fs.h is intended to
avoid), there is no way of fixing this warning on its own: it must be
fixed in proc_fs.h. (Perhaps by making a bunch of those macros into
functions with __attribute__((__unused__)) attached to appropriate
args.)

-- 
NULL && (void)