linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Luis Rodriguez <mcgrof@kernel.org>,
	Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCH] Kernel hacking menu: Runtime testing: keep tests together
Date: Mon, 2 Oct 2017 11:10:46 -0700	[thread overview]
Message-ID: <CAGXu5jJfpOFs-T7qeGc4tf0GMu54uxNKPZmrTkk5O4kfZx=E4Q@mail.gmail.com> (raw)
In-Reply-To: <c194e5c4-2042-bf94-a2d8-7aa13756e257@infradead.org>

On Mon, Oct 2, 2017 at 10:48 AM, Randy Dunlap <rdunlap@infradead.org> wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Expand the "Runtime testing" menu by including more entries inside
> it instead of after it. This is just Kconfig symbol movement.

Thanks!

Acked-by: Kees Cook <keescook@chromium.org>

-Kees

>
> This causes the (arch-independent) Runtime tests to be presented
> (listed) all in one place instead of in multiple places.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Dave Hansen <dave.hansen@intel.com>
> Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>
> ---
>  lib/Kconfig.debug |  143 +++++++++++++++++++++-----------------------
>  1 file changed, 71 insertions(+), 72 deletions(-)
>
> --- lnx-414-rc3.orig/lib/Kconfig.debug
> +++ lnx-414-rc3/lib/Kconfig.debug
> @@ -1590,6 +1590,54 @@ config LATENCYTOP
>
>  source kernel/trace/Kconfig
>
> +config PROVIDE_OHCI1394_DMA_INIT
> +       bool "Remote debugging over FireWire early on boot"
> +       depends on PCI && X86
> +       help
> +         If you want to debug problems which hang or crash the kernel early
> +         on boot and the crashing machine has a FireWire port, you can use
> +         this feature to remotely access the memory of the crashed machine
> +         over FireWire. This employs remote DMA as part of the OHCI1394
> +         specification which is now the standard for FireWire controllers.
> +
> +         With remote DMA, you can monitor the printk buffer remotely using
> +         firescope and access all memory below 4GB using fireproxy from gdb.
> +         Even controlling a kernel debugger is possible using remote DMA.
> +
> +         Usage:
> +
> +         If ohci1394_dma=early is used as boot parameter, it will initialize
> +         all OHCI1394 controllers which are found in the PCI config space.
> +
> +         As all changes to the FireWire bus such as enabling and disabling
> +         devices cause a bus reset and thereby disable remote DMA for all
> +         devices, be sure to have the cable plugged and FireWire enabled on
> +         the debugging host before booting the debug target for debugging.
> +
> +         This code (~1k) is freed after boot. By then, the firewire stack
> +         in charge of the OHCI-1394 controllers should be used instead.
> +
> +         See Documentation/debugging-via-ohci1394.txt for more information.
> +
> +config DMA_API_DEBUG
> +       bool "Enable debugging of DMA-API usage"
> +       depends on HAVE_DMA_API_DEBUG
> +       help
> +         Enable this option to debug the use of the DMA API by device drivers.
> +         With this option you will be able to detect common bugs in device
> +         drivers like double-freeing of DMA mappings or freeing mappings that
> +         were never allocated.
> +
> +         This also attempts to catch cases where a page owned by DMA is
> +         accessed by the cpu in a way that could cause data corruption.  For
> +         example, this enables cow_user_page() to check that the source page is
> +         not undergoing DMA.
> +
> +         This option causes a performance degradation.  Use only if you want to
> +         debug device drivers and dma interactions.
> +
> +         If unsure, say N.
> +
>  menu "Runtime Testing"
>
>  config LKDTM
> @@ -1749,56 +1797,6 @@ config TEST_PARMAN
>
>           If unsure, say N.
>
> -endmenu # runtime tests
> -
> -config PROVIDE_OHCI1394_DMA_INIT
> -       bool "Remote debugging over FireWire early on boot"
> -       depends on PCI && X86
> -       help
> -         If you want to debug problems which hang or crash the kernel early
> -         on boot and the crashing machine has a FireWire port, you can use
> -         this feature to remotely access the memory of the crashed machine
> -         over FireWire. This employs remote DMA as part of the OHCI1394
> -         specification which is now the standard for FireWire controllers.
> -
> -         With remote DMA, you can monitor the printk buffer remotely using
> -         firescope and access all memory below 4GB using fireproxy from gdb.
> -         Even controlling a kernel debugger is possible using remote DMA.
> -
> -         Usage:
> -
> -         If ohci1394_dma=early is used as boot parameter, it will initialize
> -         all OHCI1394 controllers which are found in the PCI config space.
> -
> -         As all changes to the FireWire bus such as enabling and disabling
> -         devices cause a bus reset and thereby disable remote DMA for all
> -         devices, be sure to have the cable plugged and FireWire enabled on
> -         the debugging host before booting the debug target for debugging.
> -
> -         This code (~1k) is freed after boot. By then, the firewire stack
> -         in charge of the OHCI-1394 controllers should be used instead.
> -
> -         See Documentation/debugging-via-ohci1394.txt for more information.
> -
> -config DMA_API_DEBUG
> -       bool "Enable debugging of DMA-API usage"
> -       depends on HAVE_DMA_API_DEBUG
> -       help
> -         Enable this option to debug the use of the DMA API by device drivers.
> -         With this option you will be able to detect common bugs in device
> -         drivers like double-freeing of DMA mappings or freeing mappings that
> -         were never allocated.
> -
> -         This also attempts to catch cases where a page owned by DMA is
> -         accessed by the cpu in a way that could cause data corruption.  For
> -         example, this enables cow_user_page() to check that the source page is
> -         not undergoing DMA.
> -
> -         This option causes a performance degradation.  Use only if you want to
> -         debug device drivers and dma interactions.
> -
> -         If unsure, say N.
> -
>  config TEST_LKM
>         tristate "Test module loading with 'hello world' module"
>         default n
> @@ -1873,18 +1871,6 @@ config TEST_UDELAY
>
>           If unsure, say N.
>
> -config MEMTEST
> -       bool "Memtest"
> -       depends on HAVE_MEMBLOCK
> -       ---help---
> -         This option adds a kernel parameter 'memtest', which allows memtest
> -         to be set.
> -               memtest=0, mean disabled; -- default
> -               memtest=1, mean do 1 test pattern;
> -               ...
> -               memtest=17, mean do 17 test patterns.
> -         If you are unsure how to answer this question, answer N.
> -
>  config TEST_STATIC_KEYS
>         tristate "Test static keys"
>         default n
> @@ -1894,16 +1880,6 @@ config TEST_STATIC_KEYS
>
>           If unsure, say N.
>
> -config BUG_ON_DATA_CORRUPTION
> -       bool "Trigger a BUG when data corruption is detected"
> -       select DEBUG_LIST
> -       help
> -         Select this option if the kernel should BUG when it encounters
> -         data corruption in kernel memory structures when they get checked
> -         for validity.
> -
> -         If unsure, say N.
> -
>  config TEST_KMOD
>         tristate "kmod stress tester"
>         default n
> @@ -1941,6 +1917,29 @@ config TEST_DEBUG_VIRTUAL
>
>           If unsure, say N.
>
> +endmenu # runtime tests
> +
> +config MEMTEST
> +       bool "Memtest"
> +       depends on HAVE_MEMBLOCK
> +       ---help---
> +         This option adds a kernel parameter 'memtest', which allows memtest
> +         to be set.
> +               memtest=0, mean disabled; -- default
> +               memtest=1, mean do 1 test pattern;
> +               ...
> +               memtest=17, mean do 17 test patterns.
> +         If you are unsure how to answer this question, answer N.
> +
> +config BUG_ON_DATA_CORRUPTION
> +       bool "Trigger a BUG when data corruption is detected"
> +       select DEBUG_LIST
> +       help
> +         Select this option if the kernel should BUG when it encounters
> +         data corruption in kernel memory structures when they get checked
> +         for validity.
> +
> +         If unsure, say N.
>
>  source "samples/Kconfig"
>
>
>



-- 
Kees Cook
Pixel Security

      reply	other threads:[~2017-10-02 18:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-02 17:48 [PATCH] Kernel hacking menu: Runtime testing: keep tests together Randy Dunlap
2017-10-02 18:10 ` Kees Cook [this message]

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='CAGXu5jJfpOFs-T7qeGc4tf0GMu54uxNKPZmrTkk5O4kfZx=E4Q@mail.gmail.com' \
    --to=keescook@chromium.org \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=torvalds@linux-foundation.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 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).