Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
From:   SeongJae Park <sj@kernel.org>
To:     Yuanchu Xie <yuanchu@google.com>
Cc:     SeongJae Park <sj@kernel.org>, Shuah Khan <shuah@kernel.org>,
        Markus Boehme <markubo@amazon.de>,
        David Rientjes <rientjes@google.com>,
        Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
        linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] selftests/damon: suppress compiler warnings for huge_count_read_write
Date:   Tue, 17 May 2022 09:04:17 -0700
Message-Id: <20220517160417.1096-1-sj@kernel.org>
MIME-Version: 1.0
In-Reply-To: <CAJj2-QGk9DmGhjPsjHwL5uj+cQs6=12iKEffpq+Vxv3=CrMPBA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi Yuanchu,

On Mon, 16 May 2022 21:07:25 -0400 Yuanchu Xie <yuanchu@google.com> wrote:

> SeongJae,
> 
> Do you have a preference on how this should be handled?

Sorry for late response.  I was thinking you were asking Shuah's opinion.  I
have no strong opinion but the approach you made in v2 looks slightly better
for me.


Thanks,
SJ

> 
> Thanks,
> Yuanchu
> 
> On Wed, May 4, 2022 at 6:12 PM Yuanchu Xie <yuanchu@google.com> wrote:
> >
> > Hi SeongJae,
> >
> > On Wed, May 4, 2022 at 11:45 AM SeongJae Park <sj@kernel.org> wrote:
> > >
> > > Hi Yuanchu,
> > >
> > > On Wed, 4 May 2022 18:29:08 +0000 Yuanchu Xie <yuanchu@google.com> wrote:
> > >
> > > > The test case added in commit db7a347b26fe ("mm/damon/dbgfs:
> > > > use '__GFP_NOWARN' for user-specified size buffer allocation")
> > > > intentionally writes and reads with a large count to cause
> > > > allocation failure and check for kernel warnings. We suppress
> > > > the compiler warnings for these calls as they work as intended.
> > > >
> > > > Signed-off-by: Yuanchu Xie <yuanchu@google.com>
> > > > ---
> > >
> > > It would be a good practice to mention the changes from the previous version of
> > > this patch here[1].
> > >
> > > [1] https://docs.kernel.org/process/submitting-patches.html#the-canonical-patch-format
> > >
> > Thank you, I missed this when trying to figure out how to add
> > additional comments for a revision.
> >
> > > >  tools/testing/selftests/damon/huge_count_read_write.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/tools/testing/selftests/damon/huge_count_read_write.c b/tools/testing/selftests/damon/huge_count_read_write.c
> > > > index ad7a6b4cf338..91bd80c75cd9 100644
> > > > --- a/tools/testing/selftests/damon/huge_count_read_write.c
> > > > +++ b/tools/testing/selftests/damon/huge_count_read_write.c
> > > > @@ -2,6 +2,8 @@
> > > >  /*
> > > >   * Author: SeongJae Park <sj@kernel.org>
> > > >   */
> > > > +#pragma GCC diagnostic ignored "-Wstringop-overflow"
> > > > +#pragma GCC diagnostic ignored "-Wstringop-overread"
> > >
> > > I agree that this must be the cleaner way than v2.  But, I get below warning
> > > after applying this:
> > >
> > >     $ sudo make -C tools/testing/selftests/damon run_tests
> > >     make: Entering directory '/home/sjpark/linux/tools/testing/selftests/damon'
> > >     gcc     huge_count_read_write.c  -o /home/sjpark/linux/tools/testing/selftests/damon/huge_count_read_write
> > >     huge_count_read_write.c:6:32: warning: unknown option after ‘#pragma GCC diagnostic’ kind [-Wpragmas]
> > >         6 | #pragma GCC diagnostic ignored "-Wstringop-overread"
> > >           |                                ^~~~~~~~~~~~~~~~~~~~~
> > >
> > > My gcc version is:
> > >
> > >     $ gcc --version
> > >     gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
> > I see, I'm running
> >
> >     $ gcc --version
> >     gcc (Debian 11.2.0-16+build1) 11.2.0
> >
> > I believe this is a new warning for gcc-11 [1], and somewhat
> > unfortunate that it results in a warning for gcc-9.4. I'm not sure
> > what the preference is here.
> > [1] https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/Warning-Options.html
> >
> > Thanks,
> > Yuanchu
>