From: Matthew Wilcox <willy@infradead.org>
To: linke li <lilinke99@gmail.com>
Cc: David Hildenbrand <david@redhat.com>,
Linke Li <lilinke99@foxmail.com>,
linux-mm@kvack.org, llvm@lists.linux.dev,
linux-kernel@vger.kernel.org, trix@redhat.com,
ndesaulniers@google.com, nathan@kernel.org,
muchun.song@linux.dev, mike.kravetz@oracle.com
Subject: Re: [PATCH] hugetlbfs: Fix integer overflow check in hugetlbfs_file_mmap()
Date: Fri, 14 Jul 2023 13:52:40 +0100 [thread overview]
Message-ID: <ZLFFGLQ6H/9RCaVf@casper.infradead.org> (raw)
In-Reply-To: <CAKdjhyBRcCFDiA923x0FLNYzs5vafENm96iAqV2XiDD_eTWBUQ@mail.gmail.com>
On Thu, Jul 13, 2023 at 03:55:55PM +0800, linke li wrote:
> > So we're adding code to handle eventual future compiler bugs? That sounds
> > wrong, but maybe I misunderstood the problem you are trying to solve?
>
> Sorry for not making it clear. My focus is the presence of undefined
> behavior in kernel code.
> Compilers can generate any code for undefined behavior and compiler
> developers will not
> take this as compiler bugs. In my option, kernel should not have
> undefined behavior.
The point that several people have tried to make to you is that
*this is not undefined behaviour*. The kernel is compiled with
-fno-strict-overflow which causes the compiler to define signed arithmetic
overflow to behave as twos-complement. Check the gcc documentation.
next prev parent reply other threads:[~2023-07-14 12:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-10 8:32 [PATCH] hugetlbfs: Fix integer overflow check in hugetlbfs_file_mmap() Linke Li
2023-07-10 16:12 ` Markus Elfring
2023-07-11 11:49 ` David Hildenbrand
2023-07-12 23:58 ` Mike Kravetz
2023-07-13 7:57 ` linke li
2023-07-13 15:10 ` Dan Carpenter
2023-07-19 23:22 ` Mike Kravetz
2023-07-20 6:25 ` linke li
2023-07-13 7:55 ` linke li
2023-07-14 12:52 ` Matthew Wilcox [this message]
2023-07-17 7:33 ` linke li
-- strict thread matches above, loose matches on Subject: below --
2023-07-10 9:02 Alexey Dobriyan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZLFFGLQ6H/9RCaVf@casper.infradead.org \
--to=willy@infradead.org \
--cc=david@redhat.com \
--cc=lilinke99@foxmail.com \
--cc=lilinke99@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=llvm@lists.linux.dev \
--cc=mike.kravetz@oracle.com \
--cc=muchun.song@linux.dev \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=trix@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).