From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
aneesh.kumar@linux.ibm.com
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 01/17] powerpc/mm: Don't BUG() in hugepd_page()
Date: Thu, 2 May 2019 14:11:16 +0200 [thread overview]
Message-ID: <d8e3c5e3-553b-da0a-46d9-b3f555c767d0@c-s.fr> (raw)
In-Reply-To: <87o94lxdxe.fsf@concordia.ellerman.id.au>
Le 02/05/2019 à 14:02, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>> Use VM_BUG_ON() instead of BUG_ON(), as those BUG_ON()
>> are not there to catch runtime errors but to catch errors
>> during development cycle only.
>
> I've dropped this one and the next, because I don't like VM_BUG_ON().
>
> Why not? Because it's contradictory. It's a condition that's so
> important that we should BUG, but only if the kernel has been built
> specially for debugging.
>
> I don't really buy the development cycle distinction, it's not like we
> have a rigorous test suite that we run and then we declare everything's
> gold and ship a product. We often don't find bugs until they're hit in
> the wild.
>
> For example the recent corruption Joel discovered with STRICT_KERNEL_RWX
> could have been caught by a BUG_ON() to check we weren't patching kernel
> text in radix__change_memory_range(), but he wouldn't have been using
> CONFIG_DEBUG_VM. (See 8adddf349fda)
>
> I know Aneesh disagrees with me on this, so maybe you two can convince
> me otherwise.
>
I have no strong oppinion about this. In v1, I replaced them with a
WARN_ON(), and Aneesh suggested to go with VM_BUG_ON() instead.
My main purpose was to reduce the amount of BUG/BUG_ON and I thought
those were good candidates, but if you prefer keeping the BUG(), that's
ok for me. Or maybe you prefered v1 alternatives (series at
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=98170) ?
Christophe
WARNING: multiple messages have this Message-ID (diff)
From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
aneesh.kumar@linux.ibm.com
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 01/17] powerpc/mm: Don't BUG() in hugepd_page()
Date: Thu, 2 May 2019 14:11:16 +0200 [thread overview]
Message-ID: <d8e3c5e3-553b-da0a-46d9-b3f555c767d0@c-s.fr> (raw)
In-Reply-To: <87o94lxdxe.fsf@concordia.ellerman.id.au>
Le 02/05/2019 à 14:02, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>> Use VM_BUG_ON() instead of BUG_ON(), as those BUG_ON()
>> are not there to catch runtime errors but to catch errors
>> during development cycle only.
>
> I've dropped this one and the next, because I don't like VM_BUG_ON().
>
> Why not? Because it's contradictory. It's a condition that's so
> important that we should BUG, but only if the kernel has been built
> specially for debugging.
>
> I don't really buy the development cycle distinction, it's not like we
> have a rigorous test suite that we run and then we declare everything's
> gold and ship a product. We often don't find bugs until they're hit in
> the wild.
>
> For example the recent corruption Joel discovered with STRICT_KERNEL_RWX
> could have been caught by a BUG_ON() to check we weren't patching kernel
> text in radix__change_memory_range(), but he wouldn't have been using
> CONFIG_DEBUG_VM. (See 8adddf349fda)
>
> I know Aneesh disagrees with me on this, so maybe you two can convince
> me otherwise.
>
I have no strong oppinion about this. In v1, I replaced them with a
WARN_ON(), and Aneesh suggested to go with VM_BUG_ON() instead.
My main purpose was to reduce the amount of BUG/BUG_ON and I thought
those were good candidates, but if you prefer keeping the BUG(), that's
ok for me. Or maybe you prefered v1 alternatives (series at
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=98170) ?
Christophe
next prev parent reply other threads:[~2019-05-02 12:11 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-26 5:59 [PATCH v2 00/17] Reduce ifdef mess in hugetlbpage.c Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-04-26 5:59 ` [PATCH v2 01/17] powerpc/mm: Don't BUG() in hugepd_page() Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-05-02 12:02 ` Michael Ellerman
2019-05-02 12:02 ` Michael Ellerman
2019-05-02 12:11 ` Christophe Leroy [this message]
2019-05-02 12:11 ` Christophe Leroy
2019-04-26 5:59 ` [PATCH v2 02/17] powerpc/mm: don't BUG in add_huge_page_size() Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-04-26 5:59 ` [PATCH v2 03/17] powerpc/book3e: drop mmu_get_tsize() Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-05-03 6:59 ` Michael Ellerman
2019-04-26 5:59 ` [PATCH v2 04/17] powerpc/64: only book3s/64 supports CONFIG_PPC_64K_PAGES Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-04-26 5:59 ` [PATCH v2 05/17] powerpc/book3e: hugetlbpage is only for CONFIG_PPC_FSL_BOOK3E Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-04-26 5:59 ` [PATCH v2 06/17] powerpc/mm: move __find_linux_pte() out of hugetlbpage.c Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-04-26 5:59 ` [PATCH v2 07/17] powerpc/mm: make hugetlbpage.c depend on CONFIG_HUGETLB_PAGE Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-04-26 5:59 ` [PATCH v2 08/17] powerpc/mm: make gup_hugepte() static Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-04-26 5:59 ` [PATCH v2 09/17] powerpc/mm: split asm/hugetlb.h into dedicated subarch files Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-04-26 5:59 ` [PATCH v2 10/17] powerpc/mm: add a helper to populate hugepd Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-04-26 5:59 ` [PATCH v2 11/17] powerpc/mm: cleanup ifdef mess in add_huge_page_size() Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-04-26 5:59 ` [PATCH v2 12/17] powerpc/mm: move hugetlb_disabled into asm/hugetlb.h Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-04-26 5:59 ` [PATCH v2 13/17] powerpc/mm: cleanup HPAGE_SHIFT setup Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-04-26 5:59 ` [PATCH v2 14/17] powerpc/mm: cleanup remaining ifdef mess in hugetlbpage.c Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-04-26 5:59 ` [PATCH v2 15/17] powerpc/mm: flatten function __find_linux_pte() step 1 Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-04-26 5:59 ` [PATCH v2 16/17] powerpc/mm: flatten function __find_linux_pte() step 2 Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
2019-04-26 5:59 ` [PATCH v2 17/17] powerpc/mm: flatten function __find_linux_pte() step 3 Christophe Leroy
2019-04-26 5:59 ` Christophe Leroy
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=d8e3c5e3-553b-da0a-46d9-b3f555c767d0@c-s.fr \
--to=christophe.leroy@c-s.fr \
--cc=aneesh.kumar@linux.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.