All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Laura Abbott <labbott@redhat.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	David Brown <david.brown@linaro.org>,
	Will Deacon <will.deacon@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	kernel-hardening@lists.openwall.com
Subject: [kernel-hardening] Re: [PATCH 1/3] arm64: dump: Make ptdump debugfs a separate option
Date: Fri, 30 Sep 2016 02:27:28 +0100	[thread overview]
Message-ID: <20160930012728.GA4611@remoulade> (raw)
In-Reply-To: <cf3b51d5-f5ad-9fc3-7bea-7e7a5a9798c5@redhat.com>

On Thu, Sep 29, 2016 at 06:11:44PM -0700, Laura Abbott wrote:
> On 09/29/2016 05:48 PM, Mark Rutland wrote:
> >On Thu, Sep 29, 2016 at 05:31:09PM -0700, Laura Abbott wrote:
> >>On 09/29/2016 05:13 PM, Mark Rutland wrote:
> >>>On Thu, Sep 29, 2016 at 02:32:55PM -0700, Laura Abbott wrote:
> >>>>+int ptdump_register(struct ptdump_info *info, const char *name)
> >>>>+{
> >>>>+	ptdump_initialize(info);
> >>>>+	return ptdump_debugfs_create(info, name);
> >>>>}

> >I meant moving ptdump_register into ptdump_debugfs.c, perhaps renamed to make it
> >clear it's debugfs-specific.
> >
> >We could instead update existing users to call ptdump_debugfs_create()
> >directly, and have that call ptdump_initialize(), which could itself become a
> >staic inline in a header.
> 
> Ah okay, I see what you are suggesting. ptdump_initialize should still
> happen regardless of debugfs status though so I guess ptdump_debugfs_create
> would just get turned into just ptdump_initialize
> which seems a little unclear. I'll come up with some other shed
> colors^W^Wfunction names.

Cheers!

FWIW, given ptsump_initialize() is only going to be called with the ptdump core
and debugfs code, I'm not all that concerned by what it's called. A few leading
underscores is about the only thing that comes to mind, but even as-is I think
it should be fine.

Thanks,
Mark.

WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] arm64: dump: Make ptdump debugfs a separate option
Date: Fri, 30 Sep 2016 02:27:28 +0100	[thread overview]
Message-ID: <20160930012728.GA4611@remoulade> (raw)
In-Reply-To: <cf3b51d5-f5ad-9fc3-7bea-7e7a5a9798c5@redhat.com>

On Thu, Sep 29, 2016 at 06:11:44PM -0700, Laura Abbott wrote:
> On 09/29/2016 05:48 PM, Mark Rutland wrote:
> >On Thu, Sep 29, 2016 at 05:31:09PM -0700, Laura Abbott wrote:
> >>On 09/29/2016 05:13 PM, Mark Rutland wrote:
> >>>On Thu, Sep 29, 2016 at 02:32:55PM -0700, Laura Abbott wrote:
> >>>>+int ptdump_register(struct ptdump_info *info, const char *name)
> >>>>+{
> >>>>+	ptdump_initialize(info);
> >>>>+	return ptdump_debugfs_create(info, name);
> >>>>}

> >I meant moving ptdump_register into ptdump_debugfs.c, perhaps renamed to make it
> >clear it's debugfs-specific.
> >
> >We could instead update existing users to call ptdump_debugfs_create()
> >directly, and have that call ptdump_initialize(), which could itself become a
> >staic inline in a header.
> 
> Ah okay, I see what you are suggesting. ptdump_initialize should still
> happen regardless of debugfs status though so I guess ptdump_debugfs_create
> would just get turned into just ptdump_initialize
> which seems a little unclear. I'll come up with some other shed
> colors^W^Wfunction names.

Cheers!

FWIW, given ptsump_initialize() is only going to be called with the ptdump core
and debugfs code, I'm not all that concerned by what it's called. A few leading
underscores is about the only thing that comes to mind, but even as-is I think
it should be fine.

Thanks,
Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Laura Abbott <labbott@redhat.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	David Brown <david.brown@linaro.org>,
	Will Deacon <will.deacon@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	kernel-hardening@lists.openwall.com
Subject: Re: [PATCH 1/3] arm64: dump: Make ptdump debugfs a separate option
Date: Fri, 30 Sep 2016 02:27:28 +0100	[thread overview]
Message-ID: <20160930012728.GA4611@remoulade> (raw)
In-Reply-To: <cf3b51d5-f5ad-9fc3-7bea-7e7a5a9798c5@redhat.com>

On Thu, Sep 29, 2016 at 06:11:44PM -0700, Laura Abbott wrote:
> On 09/29/2016 05:48 PM, Mark Rutland wrote:
> >On Thu, Sep 29, 2016 at 05:31:09PM -0700, Laura Abbott wrote:
> >>On 09/29/2016 05:13 PM, Mark Rutland wrote:
> >>>On Thu, Sep 29, 2016 at 02:32:55PM -0700, Laura Abbott wrote:
> >>>>+int ptdump_register(struct ptdump_info *info, const char *name)
> >>>>+{
> >>>>+	ptdump_initialize(info);
> >>>>+	return ptdump_debugfs_create(info, name);
> >>>>}

> >I meant moving ptdump_register into ptdump_debugfs.c, perhaps renamed to make it
> >clear it's debugfs-specific.
> >
> >We could instead update existing users to call ptdump_debugfs_create()
> >directly, and have that call ptdump_initialize(), which could itself become a
> >staic inline in a header.
> 
> Ah okay, I see what you are suggesting. ptdump_initialize should still
> happen regardless of debugfs status though so I guess ptdump_debugfs_create
> would just get turned into just ptdump_initialize
> which seems a little unclear. I'll come up with some other shed
> colors^W^Wfunction names.

Cheers!

FWIW, given ptsump_initialize() is only going to be called with the ptdump core
and debugfs code, I'm not all that concerned by what it's called. A few leading
underscores is about the only thing that comes to mind, but even as-is I think
it should be fine.

Thanks,
Mark.

  reply	other threads:[~2016-09-30  1:27 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-29 21:32 [kernel-hardening] [PATCH 0/3] WX Checking for arm64 Laura Abbott
2016-09-29 21:32 ` Laura Abbott
2016-09-29 21:32 ` Laura Abbott
2016-09-29 21:32 ` [kernel-hardening] [PATCH 1/3] arm64: dump: Make ptdump debugfs a separate option Laura Abbott
2016-09-29 21:32   ` Laura Abbott
2016-09-29 21:32   ` Laura Abbott
2016-09-30  0:13   ` [kernel-hardening] " Mark Rutland
2016-09-30  0:13     ` Mark Rutland
2016-09-30  0:13     ` Mark Rutland
2016-09-30  0:31     ` [kernel-hardening] " Laura Abbott
2016-09-30  0:31       ` Laura Abbott
2016-09-30  0:31       ` Laura Abbott
2016-09-30  0:48       ` [kernel-hardening] " Mark Rutland
2016-09-30  0:48         ` Mark Rutland
2016-09-30  0:48         ` Mark Rutland
2016-09-30  1:11         ` [kernel-hardening] " Laura Abbott
2016-09-30  1:11           ` Laura Abbott
2016-09-30  1:11           ` Laura Abbott
2016-09-30  1:27           ` Mark Rutland [this message]
2016-09-30  1:27             ` Mark Rutland
2016-09-30  1:27             ` Mark Rutland
2016-09-29 21:32 ` [kernel-hardening] [PATCH 2/3] arm64: dump: Make the page table dumping seq_file optional Laura Abbott
2016-09-29 21:32   ` Laura Abbott
2016-09-29 21:32   ` Laura Abbott
2016-09-30  0:36   ` [kernel-hardening] " Mark Rutland
2016-09-30  0:36     ` Mark Rutland
2016-09-30  0:36     ` Mark Rutland
2016-09-29 21:32 ` [kernel-hardening] [PATCH 3/3] arm64: dump: Add checking for writable and exectuable pages Laura Abbott
2016-09-29 21:32   ` Laura Abbott
2016-09-29 21:32   ` Laura Abbott
2016-09-30  2:08   ` [kernel-hardening] " Mark Rutland
2016-09-30  2:08     ` Mark Rutland
2016-09-30  2:08     ` Mark Rutland
2016-09-30 15:58   ` [kernel-hardening] " Mark Rutland
2016-09-30 15:58     ` Mark Rutland
2016-09-30 15:58     ` Mark Rutland
2016-09-30 16:25     ` [kernel-hardening] " Kees Cook
2016-09-30 16:25       ` Kees Cook
2016-09-30 16:25       ` Kees Cook
2016-09-30 16:41       ` [kernel-hardening] " Mark Rutland
2016-09-30 16:41         ` Mark Rutland
2016-09-30 16:41         ` Mark Rutland
2016-09-30 17:16         ` [kernel-hardening] " Kees Cook
2016-09-30 17:16           ` Kees Cook
2016-09-30 17:16           ` Kees Cook
2016-09-30  1:29 ` [kernel-hardening] [PATCH 0/3] WX Checking for arm64 Kees Cook
2016-09-30  1:29   ` Kees Cook

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=20160930012728.GA4611@remoulade \
    --to=mark.rutland@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=david.brown@linaro.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=labbott@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=takahiro.akashi@linaro.org \
    --cc=will.deacon@arm.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 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.