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 33CC4C52D6F for ; Tue, 27 Aug 2024 08:48:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51CBF6B007B; Tue, 27 Aug 2024 04:48:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CD136B0082; Tue, 27 Aug 2024 04:48:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3BB526B0083; Tue, 27 Aug 2024 04:48:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1FD006B007B for ; Tue, 27 Aug 2024 04:48:16 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C105E1A16C7 for ; Tue, 27 Aug 2024 08:48:15 +0000 (UTC) X-FDA: 82497398550.01.2868018 Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) by imf17.hostedemail.com (Postfix) with ESMTP id DCB2240008 for ; Tue, 27 Aug 2024 08:48:12 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JPtnDLRS; spf=pass (imf17.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.178 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724748406; 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=8kDKIOwTEd6w8yb+ASnRf9bhshqBEl1pUBH6pCnSK/I=; b=JWrYDMc4xJzD0XVznpdLjrSQIoe1GvzKe3ojl9SE61bnLCVZnXOoFfXrmyHymS0p2levt3 6WkfjWnxJ7gsyZGb3PDT8K82YQGCtRDZ/h0U9DSMK6Xqny+k+vP79Q1GhyZyCEFOidobvA doA3oNiXpyOqpsNAv9oV8Bifmf3QGd0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724748406; a=rsa-sha256; cv=none; b=AF9Tl6v3KeCb3ayWx86/RLcPWI4MmAWXFf9p1yo4TLkK4uWMoqNBMXpkGrTqSGuZsXTJ/i xZd/5mAar72mWCs4mmWOuc+2oileu8leHMsShq4AJAa/DruBq1Ewjroyic5s9WmTVYaCfL zMou81Es8Se+RQlUBYo2zLr/nOeBGvk= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JPtnDLRS; spf=pass (imf17.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.178 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-2f401c20b56so45474911fa.0 for ; Tue, 27 Aug 2024 01:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724748491; x=1725353291; 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=8kDKIOwTEd6w8yb+ASnRf9bhshqBEl1pUBH6pCnSK/I=; b=JPtnDLRSA4pdAbjAX45njvvW0MNakXfNo11B5FAHDJuEy7rmX1mfK/0V4ForDhZ/N+ 3VrUd1M+tNDJZjWPMXfcnzp43nPWxYN5/uv67+CsB+NHYTq9V/pg+ujdYlTC2De/T3F3 QlozSn2paUgvqyDTGC4JJbjUX8UPl6Qmlb8ZyOj/AWs18s1QlXzbJftR6JiKb7OZOxJ9 NQ+hD0QNxOGD4zYQZCb09n7dgqk6EEz2UcV/7bCun8OJRXjCvg0fmX4LTG7mUJ6A9kN8 ZKO/nzY8K7sBDSuZrsbf9wy8AG9vfs+b/JAPH0lYLwsfvG/suu4Sn3iaevejFcMFGomg ojNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724748491; x=1725353291; 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=8kDKIOwTEd6w8yb+ASnRf9bhshqBEl1pUBH6pCnSK/I=; b=De1mBvWghys+jTZz/fKGoTG8+soDbmshATCSkn3KfQe2A8FJUxKOicvAwXm1Fw8HxZ O8YHSJhwA+zBDav3fwI60+zL3s7wndAddZl8AKpRdBqtphooJoPaLv1OAFeiuz7FLmrx lwNzv9D3Odqm9bSMC5ysrpfaAu7Wc0OXmp9Gqxmvd1M+5SYrJCgZ739Lve7jglBDcxkl ES6SDLCMVVrrjf0YfkFLUrpSMUn/l+mggW9wHGWkMjYJohxfLJ5MKQaOkLWgzQJscp00 Xx0fuN9FPwTsMpudITyg6Uf7OyVRDp612r5id2YmDuiFM+RtYhkQZK8Ort8sUCy/cLg1 4DUg== X-Forwarded-Encrypted: i=1; AJvYcCW+SqZiTiLSvFxO98V9ISPKYWWnev8bNn5PB/X/I484s+1gMpZvUEK/9AArO4i27/xfGeqrcSXiRg==@kvack.org X-Gm-Message-State: AOJu0YyDNXZVmavsO+J7pW16AKZIIP58tr8AHjKpiNK9Q2VipA+SLvuB vb45HL7l0y7RsLdT9UBrg9zEPoDlFgpMsyKRWHGWZ00Z+RjsmwCZ8PbUII6y8YImUN19EFZR3An HMEEeh1zf2sD0NVdURhIZehlb/ns= X-Google-Smtp-Source: AGHT+IHfzEjvAa6juUPHsEOAGjLWPcwPUMqsodqfndjPZiVuX++xmoBVqhxYgl03omfSpxoIUvlKwJD7cx+EtDranMw= X-Received: by 2002:a05:651c:b0a:b0:2ef:1c05:6907 with SMTP id 38308e7fff4ca-2f514b7a52bmr8112801fa.5.1724748490547; Tue, 27 Aug 2024 01:48:10 -0700 (PDT) MIME-Version: 1.0 References: <20240819220548.d8f1ea5cf504cfd8feb5780e@linux-foundation.org> In-Reply-To: From: Kairui Song Date: Tue, 27 Aug 2024 16:47:54 +0800 Message-ID: Subject: Re: gcc-8: mm/swapfile.c:863:40: error: array subscript 1 is above array bounds of 'struct list_head[1]' [-Werror=array-bounds] To: Chris Li , Andrew Morton Cc: Naresh Kamboju , linux-mm , open list , lkft-triage@lists.linaro.org, Linux Regressions , Barry Song <21cnbao@gmail.com>, "Huang, Ying" , Hugh Dickins , Kalesh Singh , Ryan Roberts , Anders Roxell Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: gh5js6n89zcri7kpk7f3nipy4wcx6rc5 X-Rspamd-Queue-Id: DCB2240008 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1724748492-119294 X-HE-Meta: U2FsdGVkX1+lPJrlmCgxSaZekRPv1B9Pv/1OkM0mSXTa+l7fZbpo2srW3+4JjhbapZYx9zcuMtxfzd2OTPqG43pfKTrIRwschy3Qex7NFVKTfa7l88168Rs1q8wLldm38P+0fX2EYbsGRxfVP8cYF2V7ELKcPb0QhYeDZOVxjP/dA0Y37NdkTqeHcWj/JQHhadL63r6aot0xUAvdaAYatRUnmq03R5r0CF/O5wMjDpNxKr/BFeNvu17dRNhxERG8VXfMWPcJdVhmsoCSjCqNIq0NaSYSsZ8fnk5Jt2zRsCKMbJy07nnzzefdXruqCT76FPiGwec4VF0LHd3Cjhs4SvaMfzwFzZgc2Biaf3cfOtnhI7mT5bXaZ02ImrFWB4uBBOjcdJ2lJa/4WRwOquXz0CqnKQbOFk1ePOqPA830nWLL5wHKOEf7xGy0Z+gtM42qliGpQkKD4ZBRSpNruTpHHpAdKimqGK8MxVSIuYW1asF8AF5cSN/7M+bpT31k9/heqCQLjd/q4zutY4H6LlOJNchwwAykuNLvRmxVzcsInMqQ63199hf96gYcKcIhiZfmaiy5/i3VLscN26FwK2bKCEW4XelnMzmzrDC+jJKTW/ukvHWILtzeWB3CXUr0f8L6E3vFBiWUd64biYWCwnFwpcDXeEwpqN5MTeBPNnErYwgRAmFPG1ZQInys5riOb+qcrU+Vng31gu0cbuRZNhqqVPoY4XtlHNUK9C/k5xc6eb6hC77UuJ5mWCGOv9c+0VOvAjpriTj6V/cYeGanZAcBmOvyTArEhC9nlQBmFO6wZrveh51JXMav2Tbx8nq8OaRnws4wszZlbqDjrCFJfM885X1CcCUsi+rJmnuivyqObFYvAva7xtXwxDo5jS8QV1VDXn3VP34OcUuxLSHWWinBaTLCCOd9hGj/OFdfPXSfYf9pE+j70wh0myZHzHiL43xxY8w0N4knvQwN7XKTYuf bD6s1NmC 3bkG+wKcsxGq0UiLwQOQ2pIHSYEH9IDzwYBlArTnZ6LS0sONEiTULf7o8m4EMHZKVrc6Hu3uviaYD/PvLCCZzKJGvCHPDRvwn6LwO4QlE4hOFJLJH/AQl4fww9h7cHCV/NmQoQ5lMP+r78iLaCTFNW6CXR7VyL9pRbWCUGpfIV2yY4/oOUVQA4IDhuYJjAH3N0AB5jUHUF8ICYbZ/YrA9ikZk0qiJ+PLJ/3sH+/oYN62/RRfs9pMUsbtCRaRQ0Txhy5PJMf5sCnQWPMR3xwLeP1arm7yFykXjhGQOWexYTzlXVU5PtIMLWozAHGhzQLugbjF5KkwAoA/mMe9AX9sGT69A3HSsG7YyECG6GxS6zvKKGUbbhzuKHpDPrXYe8L5BKxf3A70sz2AKoDwIT6/bcxCdgapCWTAYAWZwth8MKIqTqyR/CZUM/aPTxskrF6KJWfnu4DXScbQ/CGDKAoaVd2GDO1e+Kgkw3NK7COKBfeKaRTI= 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, Aug 20, 2024 at 4:51=E2=80=AFPM Chris Li wrote: > > On Mon, Aug 19, 2024 at 10:05=E2=80=AFPM Andrew Morton > wrote: > > > > On Mon, 19 Aug 2024 19:44:25 +0800 Kairui Song wrote= : > > > > > --- a/mm/swapfile.c > > > +++ b/mm/swapfile.c > > > @@ -836,7 +836,7 @@ static unsigned long cluster_alloc_swap_entry(str= uct swap_info_struct *si, int o > > > goto done; > > > > > > /* Order 0 stealing from higher order */ > > > - for (int o =3D 1; o < PMD_ORDER; o++) { > > > + for (int o =3D 1; o < SWAP_NR_ORDERS; o++) { > > > /* > > > * Clusters here have at least one usable slots and can= 't fail order 0 > > > * allocation, but reclaim may drop si->lock and race w= ith another user. > > > > OK, I got that landed in the right place, but... > > > > The definition of `o' within the for statement isn't typical kernel > > style - I'm surprised we didn't get a warning for this - maybe things > > have changed when I wasn't looking. > > Noted. > > I did use the checkpatch.pl and fixed all the warnings before I sent > the patch out. > The checkpatch.pl script did not complain about this. Sure I can stay > away from it. > BTW, I did a search on the kernel tree: > $ rg 'for \(int' | wc -l > 970 > $ > It seems pretty common in the kernel tree now. Might be off topic from the issue... I believe this issue it's not an upstream problem nowadays after e8c07082a810 ("Kbuild: move to -std=3Dgnu11"), I did notice a GCC error after backporting these commits to an older kernel which still used c89, but for upstream this should be OK? > > > > > Also, this code makes no attempt to honor our "The preferred limit on > > the length of a single line is 80 columns" objective. There's just no > > reason for comment blocks to violate this. > > I was wondering why the checkpatch.pl did not catch this, is there any > config for checkpatch.pl I should apply? > > I typically invoke: > > ./scripts/checkpatch.pl -g HEAD I found checkpatch.pl stopped checking for 80 columns limit after commit bdc48fa11e46 ("checkpatch/coding-style: deprecate 80-column warning") 4 years ago. But the 80 column limit seems still preferred?