All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Vivier <laurent@vivier.eu>
To: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>, riku.voipio@iki.fi
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] linux-user: elf: mmap all the target-pages of hostpage for data segment
Date: Tue, 28 Aug 2018 23:01:45 +0200	[thread overview]
Message-ID: <ed3c0388-a9fe-2fdf-c54e-27d690eb5def@vivier.eu> (raw)
In-Reply-To: <153546966871.75539.10980006517656536139.stgit@lep8c.aus.stglabs.ibm.com>

Le 28/08/2018 à 17:22, Shivaprasad G Bhat a écrit :
> If the hostpage size is greater than the TARGET_PAGESIZE, the
> target-pages of size TARGET_PAGESIZE are marked valid only till the
> length requested during the elfload. The glibc attempts to consume unused
> space in the last page of data segment(__libc_memalign() in
> elf/dl-minimal.c). If PT_LOAD p_align is greater than or
> equal to hostpage size, the GLRO(dl_pagesize) is actually the host pagesize
> as set in the auxillary vectors. So, there is no explicit mmap request for
> the remaining target-pages on the last hostpage. The glibc assumes that
> particular space as available and subsequent attempts to use
> those addresses lead to crash as the target_mmap has not marked them valid
> for target-pages as valid.
> 
> The issue is seen when trying to chroot to 16.04-x86_64 ubuntu on a PPC64
> host where the fork fails to access the thread_id as it is allocated on a
> page not marked valid. The recent glibc doesnt have checks for thread-id in
> fork, but the issue can manifest somewhere else, none the less.
> 
> The fix here is to map all the target-pages of the hostpage during the
> elfload if the p_align is greater than or equal to hostpage size, for
> data segment to allow the glibc for proper consumption.
> 
> Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
> ---
> v1: https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg05730.html
> Changes from v1:
>    - Made the conditionals consistent with the commit "33143c446e" and
>      changed the commit message accordingly.
> 
>  linux-user/elfload.c |   37 +++++++++++++++++++++++++++++--------
>  1 file changed, 29 insertions(+), 8 deletions(-)
> 
> diff --git a/linux-user/elfload.c b/linux-user/elfload.c
> index 8638612aec..cced43f45c 100644
> --- a/linux-user/elfload.c
> +++ b/linux-user/elfload.c
> @@ -1438,9 +1438,23 @@ struct exec
>  
>  /* Necessary parameters */
>  #define TARGET_ELF_EXEC_PAGESIZE TARGET_PAGE_SIZE
> -#define TARGET_ELF_PAGESTART(_v) ((_v) & \
> -                                 ~(abi_ulong)(TARGET_ELF_EXEC_PAGESIZE-1))
> -#define TARGET_ELF_PAGEOFFSET(_v) ((_v) & (TARGET_ELF_EXEC_PAGESIZE-1))
> +#define TARGET_ELF_PAGESTART(_v, _a, _s, _m) \
> +        (((_a & ~_m) != 0) ? \
> +         (_v) & ~(abi_ulong)(TARGET_ELF_EXEC_PAGESIZE - 1) : \
> +         ((TARGET_ELF_EXEC_PAGESIZE > _s) ? \
> +          (_v) & ~(abi_ulong)(TARGET_ELF_EXEC_PAGESIZE - 1) : \
> +          (_v) & ~(abi_ulong)(_s - 1)));
> +#define TARGET_ELF_PAGEOFFSET(_v, _a, _s, _m) \
> +        (((_a & ~_m) != 0) ? \
> +         (_v) & (TARGET_ELF_EXEC_PAGESIZE - 1) : \
> +         ((TARGET_ELF_EXEC_PAGESIZE > _s) ? \
> +          (_v) & (TARGET_ELF_EXEC_PAGESIZE - 1) : \
> +          (_v) & (_s - 1)));
> +#define TARGET_ELF_PAGELENGTH(_v, _a, _s, _m) \
> +        (((_a & ~_m) != 0) ? \
> +         TARGET_PAGE_ALIGN(_v) : \
> +         ((TARGET_ELF_EXEC_PAGESIZE > _s) ? \
> +          TARGET_PAGE_ALIGN(_v) : HOST_PAGE_ALIGN(_v)));

I think you should use eppnt->p_align instead of info->alignment and 
simplify this to:

#define TARGET_ELF_EXEC_PAGESIZE \
        (((eppnt->p_align & ~qemu_host_page_mask) != 0) ? \
         TARGET_PAGE_SIZE : MAX(qemu_host_page_size, TARGET_PAGE_SIZE))
#define TARGET_ELF_PAGELENGTH(_v) ROUND_UP((_v), TARGET_ELF_EXEC_PAGESIZE)

Thanks,
Laurent

      reply	other threads:[~2018-08-28 21:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-28 15:22 [Qemu-devel] [PATCH v2] linux-user: elf: mmap all the target-pages of hostpage for data segment Shivaprasad G Bhat
2018-08-28 21:01 ` Laurent Vivier [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=ed3c0388-a9fe-2fdf-c54e-27d690eb5def@vivier.eu \
    --to=laurent@vivier.eu \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=riku.voipio@iki.fi \
    --cc=sbhat@linux.vnet.ibm.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.