All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: kexec@lists.infradead.org
Subject: [PATCHv3 1/4] arm64: make phys_offset signed
Date: Fri, 14 Jan 2022 15:35:26 +0100	[thread overview]
Message-ID: <20220114143526.GC16732@vergenet.net> (raw)
In-Reply-To: <20211228132659.40102-2-piliu@redhat.com>

On Tue, Dec 28, 2021 at 09:26:56PM +0800, Pingfan Liu wrote:
> After kernel commit 7bc1a0f9e176 ("arm64: mm: use single quantity to
> represent the PA to VA translation"), phys_offset can be negative if
> running 52-bits kernel on 48-bits hardware.
> 
> So changing phys_offset from unsigned to signed.
> 
> Signed-off-by: Pingfan Liu <piliu@redhat.com>
> Cc: Kairui Song <kasong@tencent.com>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Philipp Rudo <prudo@redhat.com>
> To: kexec at lists.infradead.org
> ---
>  kexec/arch/arm64/kexec-arm64.c | 8 ++++----
>  kexec/arch/arm64/kexec-arm64.h | 2 +-
>  util_lib/elf_info.c            | 2 +-
>  util_lib/include/elf_info.h    | 2 +-
>  4 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
> index 6f572ed..7373fa3 100644
> --- a/kexec/arch/arm64/kexec-arm64.c
> +++ b/kexec/arch/arm64/kexec-arm64.c
> @@ -859,7 +859,7 @@ void add_segment(struct kexec_info *info, const void *buf, size_t bufsz,
>  	add_segment_phys_virt(info, buf, bufsz, base, memsz, 1);
>  }
>  
> -static inline void set_phys_offset(uint64_t v, char *set_method)
> +static inline void set_phys_offset(long v, char *set_method)

Perhaps it would be more in keeping with the current implementation
to use int64_t rather than long ?

>  {
>  	if (arm64_mem.phys_offset == arm64_mem_ngv
>  		|| v < arm64_mem.phys_offset) {
> @@ -928,7 +928,7 @@ static int get_page_offset(void)
>   * from VMCOREINFO note inside 'kcore'.
>   */
>  
> -static int get_phys_offset_from_vmcoreinfo_pt_note(unsigned long *phys_offset)
> +static int get_phys_offset_from_vmcoreinfo_pt_note(long *phys_offset)
>  {
>  	int fd, ret = 0;
>  
> @@ -948,7 +948,7 @@ static int get_phys_offset_from_vmcoreinfo_pt_note(unsigned long *phys_offset)
>   * from PT_LOADs inside 'kcore'.
>   */
>  
> -int get_phys_base_from_pt_load(unsigned long *phys_offset)
> +int get_phys_base_from_pt_load(long *phys_offset)
>  {
>  	int i, fd, ret;
>  	unsigned long long phys_start;
> @@ -997,7 +997,7 @@ static bool to_be_excluded(char *str)
>  int get_memory_ranges(struct memory_range **range, int *ranges,
>  	unsigned long kexec_flags)
>  {
> -	unsigned long phys_offset = UINT64_MAX;
> +	long phys_offset = (long)UINT64_MAX;

Effectively this sets phys_offset to -1.
Is that ok / intended ? If so, perhaps it's clearer to just use -1.

Regardless, can clean up other uses of long with UINT64_MAX introduced
by this patch?

I see the following:

make
...
kexec/arch/arm64/kexec-arm64.c: In function ?get_memory_ranges?:
kexec/arch/arm64/kexec-arm64.c:1022:20: warning: comparison between signed and u
nsigned integer expressions [-Wsign-compare]
    if (phys_offset != UINT64_MAX)
...
kexec/arch/arm64/kexec-arm64.c:1034:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
     if (phys_offset != UINT64_MAX)


>  	FILE *fp;
>  	const char *iomem = proc_iomem();
>  	char line[MAX_LINE], *str;
> diff --git a/kexec/arch/arm64/kexec-arm64.h b/kexec/arch/arm64/kexec-arm64.h
> index ed447ac..1844b67 100644
> --- a/kexec/arch/arm64/kexec-arm64.h
> +++ b/kexec/arch/arm64/kexec-arm64.h
> @@ -58,7 +58,7 @@ extern off_t initrd_size;
>   */
>  
>  struct arm64_mem {
> -	uint64_t phys_offset;
> +	long phys_offset;
>  	uint64_t text_offset;
>  	uint64_t image_size;
>  	uint64_t vp_offset;
> diff --git a/util_lib/elf_info.c b/util_lib/elf_info.c
> index 51d8b92..5574c7f 100644
> --- a/util_lib/elf_info.c
> +++ b/util_lib/elf_info.c
> @@ -1236,7 +1236,7 @@ int read_elf(int fd)
>  	return 0;
>  }
>  
> -int read_phys_offset_elf_kcore(int fd, unsigned long *phys_off)
> +int read_phys_offset_elf_kcore(int fd, long *phys_off)
>  {
>  	int ret;
>  
> diff --git a/util_lib/include/elf_info.h b/util_lib/include/elf_info.h
> index 4bc9279..f550d86 100644
> --- a/util_lib/include/elf_info.h
> +++ b/util_lib/include/elf_info.h
> @@ -28,7 +28,7 @@ int get_pt_load(int idx,
>  	unsigned long long *phys_end,
>  	unsigned long long *virt_start,
>  	unsigned long long *virt_end);
> -int read_phys_offset_elf_kcore(int fd, unsigned long *phys_off);
> +int read_phys_offset_elf_kcore(int fd, long *phys_off);
>  int read_elf(int fd);
>  void dump_dmesg(int fd, void (*handler)(char*, unsigned int));
>  
> -- 
> 2.31.1
> 


  reply	other threads:[~2022-01-14 14:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-28 13:26 [PATCHv3 0/4] arm64: make phys_to_virt() correct Pingfan Liu
2021-12-28 13:26 ` [PATCHv3 1/4] arm64: make phys_offset signed Pingfan Liu
2022-01-14 14:35   ` Simon Horman [this message]
2021-12-28 13:26 ` [PATCHv3 2/4] arm64/crashdump: unify routine to get page_offset Pingfan Liu
2022-01-14 14:41   ` Simon Horman
2021-12-28 13:26 ` [PATCHv3 3/4] arm64: read VA_BITS from kcore for 52-bits VA kernel Pingfan Liu
2021-12-28 13:26 ` [PATCHv3 4/4] arm64: fix PAGE_OFFSET calc for flipped mm Pingfan Liu
2022-01-12  3:39 ` [PATCHv3 0/4] arm64: make phys_to_virt() correct Pingfan Liu
2022-01-14 14:47 ` Simon Horman
2022-01-18  1:52   ` Pingfan Liu

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=20220114143526.GC16732@vergenet.net \
    --to=horms@verge.net.au \
    --cc=kexec@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.