All of lore.kernel.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2 6/6] arm64: Add support for CONFIG_DEBUG_VIRTUAL
Date: Thu, 3 Nov 2016 15:57:54 +0000	[thread overview]
Message-ID: <20161103155753.GG25852@remoulade> (raw)
In-Reply-To: <a77c2162-6eb9-09c8-e84f-03a207b59c6b@redhat.com>

On Wed, Nov 02, 2016 at 06:05:38PM -0600, Laura Abbott wrote:
> On 11/02/2016 05:06 PM, Mark Rutland wrote:
> >On Wed, Nov 02, 2016 at 03:00:54PM -0600, Laura Abbott wrote:
> >>+CFLAGS_physaddr.o		:= -DTEXT_OFFSET=$(TEXT_OFFSET)
> >>+obj-$(CONFIG_DEBUG_VIRTUAL)	+= physaddr.o

> >>+	/*
> >>+	 * This is intentionally different than above to be a tighter check
> >>+	 * for symbols.
> >>+	 */
> >>+	VIRTUAL_BUG_ON(x < kimage_vaddr + TEXT_OFFSET || x > (unsigned long) _end);
> >
> >Can't we use _text instead of kimage_vaddr + TEXT_OFFSET? That way we don't
> >need CFLAGS_physaddr.o.
> >
> >Or KERNEL_START / KERNEL_END from <asm/memory.h>?
> >
> >Otherwise, this looks good to me (though I haven't grokked the need for
> >__pa_symbol() yet).
> 
> I guess it's a question of what's clearer. I like kimage_vaddr +
> TEXT_OFFSET because it clearly states we are checking from the
> start of the kernel image vs. _text only shows the start of the
> text region. Yes, it's technically the same but a little less
> obvious. I suppose that could be solved with some more elaboration
> in the comment.

Sure, it's arguable either way.

I do think that KERNEL_START/KERNEL_END are a better choice, with the comment
you suggest, and/or renamed to KERNEL_IMAGE_*. They already describe the bounds
of the image (though the naming doesn't make that entirely clear).

Thanks,
Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Laura Abbott <labbott@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Will Deacon <will.deacon@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv2 6/6] arm64: Add support for CONFIG_DEBUG_VIRTUAL
Date: Thu, 3 Nov 2016 15:57:54 +0000	[thread overview]
Message-ID: <20161103155753.GG25852@remoulade> (raw)
In-Reply-To: <a77c2162-6eb9-09c8-e84f-03a207b59c6b@redhat.com>

On Wed, Nov 02, 2016 at 06:05:38PM -0600, Laura Abbott wrote:
> On 11/02/2016 05:06 PM, Mark Rutland wrote:
> >On Wed, Nov 02, 2016 at 03:00:54PM -0600, Laura Abbott wrote:
> >>+CFLAGS_physaddr.o		:= -DTEXT_OFFSET=$(TEXT_OFFSET)
> >>+obj-$(CONFIG_DEBUG_VIRTUAL)	+= physaddr.o

> >>+	/*
> >>+	 * This is intentionally different than above to be a tighter check
> >>+	 * for symbols.
> >>+	 */
> >>+	VIRTUAL_BUG_ON(x < kimage_vaddr + TEXT_OFFSET || x > (unsigned long) _end);
> >
> >Can't we use _text instead of kimage_vaddr + TEXT_OFFSET? That way we don't
> >need CFLAGS_physaddr.o.
> >
> >Or KERNEL_START / KERNEL_END from <asm/memory.h>?
> >
> >Otherwise, this looks good to me (though I haven't grokked the need for
> >__pa_symbol() yet).
> 
> I guess it's a question of what's clearer. I like kimage_vaddr +
> TEXT_OFFSET because it clearly states we are checking from the
> start of the kernel image vs. _text only shows the start of the
> text region. Yes, it's technically the same but a little less
> obvious. I suppose that could be solved with some more elaboration
> in the comment.

Sure, it's arguable either way.

I do think that KERNEL_START/KERNEL_END are a better choice, with the comment
you suggest, and/or renamed to KERNEL_IMAGE_*. They already describe the bounds
of the image (though the naming doesn't make that entirely clear).

Thanks,
Mark.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Laura Abbott <labbott@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Will Deacon <will.deacon@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv2 6/6] arm64: Add support for CONFIG_DEBUG_VIRTUAL
Date: Thu, 3 Nov 2016 15:57:54 +0000	[thread overview]
Message-ID: <20161103155753.GG25852@remoulade> (raw)
In-Reply-To: <a77c2162-6eb9-09c8-e84f-03a207b59c6b@redhat.com>

On Wed, Nov 02, 2016 at 06:05:38PM -0600, Laura Abbott wrote:
> On 11/02/2016 05:06 PM, Mark Rutland wrote:
> >On Wed, Nov 02, 2016 at 03:00:54PM -0600, Laura Abbott wrote:
> >>+CFLAGS_physaddr.o		:= -DTEXT_OFFSET=$(TEXT_OFFSET)
> >>+obj-$(CONFIG_DEBUG_VIRTUAL)	+= physaddr.o

> >>+	/*
> >>+	 * This is intentionally different than above to be a tighter check
> >>+	 * for symbols.
> >>+	 */
> >>+	VIRTUAL_BUG_ON(x < kimage_vaddr + TEXT_OFFSET || x > (unsigned long) _end);
> >
> >Can't we use _text instead of kimage_vaddr + TEXT_OFFSET? That way we don't
> >need CFLAGS_physaddr.o.
> >
> >Or KERNEL_START / KERNEL_END from <asm/memory.h>?
> >
> >Otherwise, this looks good to me (though I haven't grokked the need for
> >__pa_symbol() yet).
> 
> I guess it's a question of what's clearer. I like kimage_vaddr +
> TEXT_OFFSET because it clearly states we are checking from the
> start of the kernel image vs. _text only shows the start of the
> text region. Yes, it's technically the same but a little less
> obvious. I suppose that could be solved with some more elaboration
> in the comment.

Sure, it's arguable either way.

I do think that KERNEL_START/KERNEL_END are a better choice, with the comment
you suggest, and/or renamed to KERNEL_IMAGE_*. They already describe the bounds
of the image (though the naming doesn't make that entirely clear).

Thanks,
Mark.

  reply	other threads:[~2016-11-03 15:57 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-02 21:00 [PATCHv2 0/6] CONFIG_DEBUG_VIRTUAL for arm64 Laura Abbott
2016-11-02 21:00 ` Laura Abbott
2016-11-02 21:00 ` Laura Abbott
2016-11-02 21:00 ` [PATCHv2 1/6] lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL Laura Abbott
2016-11-02 21:00   ` Laura Abbott
2016-11-02 21:00   ` Laura Abbott
2016-11-02 21:00 ` [PATCHv2 2/6] mm/cma: Cleanup highmem check Laura Abbott
2016-11-02 21:00   ` Laura Abbott
2016-11-02 21:00   ` Laura Abbott
2016-11-02 21:00 ` [PATCHv2 3/6] arm64: Move some macros under #ifndef __ASSEMBLY__ Laura Abbott
2016-11-02 21:00   ` Laura Abbott
2016-11-02 21:00   ` Laura Abbott
2016-11-02 21:00 ` [PATCHv2 4/6] arm64: Add cast for virt_to_pfn Laura Abbott
2016-11-02 21:00   ` Laura Abbott
2016-11-02 21:00   ` Laura Abbott
2016-11-02 21:00 ` [PATCHv2 5/6] arm64: Use __pa_symbol for _end Laura Abbott
2016-11-02 21:00   ` Laura Abbott
2016-11-02 21:00   ` Laura Abbott
2016-11-02 22:52   ` Mark Rutland
2016-11-02 22:52     ` Mark Rutland
2016-11-02 22:52     ` Mark Rutland
2016-11-02 23:56     ` Laura Abbott
2016-11-02 23:56       ` Laura Abbott
2016-11-02 23:56       ` Laura Abbott
2016-11-03 15:51       ` Mark Rutland
2016-11-03 15:51         ` Mark Rutland
2016-11-03 15:51         ` Mark Rutland
2016-11-14 18:19         ` Catalin Marinas
2016-11-14 18:19           ` Catalin Marinas
2016-11-14 18:19           ` Catalin Marinas
2016-11-14 18:41           ` Laura Abbott
2016-11-14 18:41             ` Laura Abbott
2016-11-14 18:41             ` Laura Abbott
2016-11-15 18:35             ` Catalin Marinas
2016-11-15 18:35               ` Catalin Marinas
2016-11-15 18:35               ` Catalin Marinas
2016-11-16  0:09               ` Laura Abbott
2016-11-16  0:09                 ` Laura Abbott
2016-11-16  0:09                 ` Laura Abbott
2016-11-16 17:32                 ` Catalin Marinas
2016-11-16 17:32                   ` Catalin Marinas
2016-11-16 17:32                   ` Catalin Marinas
2016-11-18 10:23                   ` Ard Biesheuvel
2016-11-18 10:23                     ` Ard Biesheuvel
2016-11-18 10:23                     ` Ard Biesheuvel
2016-11-02 21:00 ` [PATCHv2 6/6] arm64: Add support for CONFIG_DEBUG_VIRTUAL Laura Abbott
2016-11-02 21:00   ` Laura Abbott
2016-11-02 21:00   ` Laura Abbott
2016-11-02 23:06   ` Mark Rutland
2016-11-02 23:06     ` Mark Rutland
2016-11-02 23:06     ` Mark Rutland
2016-11-03  0:05     ` Laura Abbott
2016-11-03  0:05       ` Laura Abbott
2016-11-03  0:05       ` Laura Abbott
2016-11-03 15:57       ` Mark Rutland [this message]
2016-11-03 15:57         ` Mark Rutland
2016-11-03 15:57         ` Mark Rutland
2016-11-02 23:07 ` [PATCHv2 0/6] CONFIG_DEBUG_VIRTUAL for arm64 Mark Rutland
2016-11-02 23:07   ` Mark Rutland
2016-11-02 23:07   ` Mark Rutland

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=20161103155753.GG25852@remoulade \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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.