mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Michael Olbrich <m.olbrich@pengutronix.de>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] [PATCH] valgrind: add upstream patch to make it work with kernel 4.5+
Date: Thu, 11 Feb 2016 12:26:41 +0100	[thread overview]
Message-ID: <20160211112641.GK32288@pengutronix.de> (raw)
In-Reply-To: <1454340896-1005-1-git-send-email-l.stach@pengutronix.de>

On Mon, Feb 01, 2016 at 04:34:56PM +0100, Lucas Stach wrote:
> The current version of valgrind breaks if it is used together
> with kernel 4.5 running on the machine.
> 
> Upstream already has a fix applied, but that is not found in
> any released version yet. Pick this fix into our local patches
> to allow valgrind to work on recent kernels again.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>

Thanks, applied.

Michael

> ---
>  ...Setting-RLIMIT_DATA-to-zero-breaks-with-l.patch | 141 +++++++++++++++++++++
>  patches/valgrind-3.11.0/series                     |   3 +-
>  2 files changed, 143 insertions(+), 1 deletion(-)
>  create mode 100644 patches/valgrind-3.11.0/0003-Bug-357833-Setting-RLIMIT_DATA-to-zero-breaks-with-l.patch
> 
> diff --git a/patches/valgrind-3.11.0/0003-Bug-357833-Setting-RLIMIT_DATA-to-zero-breaks-with-l.patch b/patches/valgrind-3.11.0/0003-Bug-357833-Setting-RLIMIT_DATA-to-zero-breaks-with-l.patch
> new file mode 100644
> index 000000000000..74246f612acb
> --- /dev/null
> +++ b/patches/valgrind-3.11.0/0003-Bug-357833-Setting-RLIMIT_DATA-to-zero-breaks-with-l.patch
> @@ -0,0 +1,141 @@
> +From: mjw <mjw@a5019735-40e9-0310-863c-91ae7b9d1cf9>
> +Date: Thu, 21 Jan 2016 11:37:43 +0000
> +Subject: [PATCH] Bug #357833 Setting RLIMIT_DATA to zero breaks with linux
> + 4.5+
> +
> +We used to set the process datasize rlimit to zero to prevent
> +any internal use of brk() from having any effect. But later
> +linux kernels redefine RLIMIT_DATA as the size of any data
> +areas, including some dynamic mmap memory allocations.
> +
> +See bug #357833 for the commit that went into linux 4.5
> +changing the definition of RLIMIT_DATA. So don't mess with
> +RLIMIT_DATA anymore. Just remember it for use in the syscall
> +wrappers.
> +
> +This also cleans up some hacks around the execv and spawn wrappers.
> +
> +git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15766 a5019735-40e9-0310-863c-91ae7b9d1cf9
> +---
> + coregrind/m_libcproc.c                | 11 -----------
> + coregrind/m_main.c                    | 15 ++++++++-------
> + coregrind/m_syswrap/syswrap-generic.c |  3 ---
> + coregrind/m_syswrap/syswrap-solaris.c | 12 ------------
> + 4 files changed, 8 insertions(+), 33 deletions(-)
> +
> +diff --git a/coregrind/m_libcproc.c b/coregrind/m_libcproc.c
> +index f314b55eea88..a30f7dc8f0c5 100644
> +--- a/coregrind/m_libcproc.c
> ++++ b/coregrind/m_libcproc.c
> +@@ -450,9 +450,6 @@ void VG_(execv) ( const HChar* filename, const HChar** argv )
> +    HChar** envp;
> +    SysRes res;
> + 
> +-   /* restore the DATA rlimit for the child */
> +-   VG_(setrlimit)(VKI_RLIMIT_DATA, &VG_(client_rlimit_data));
> +-
> +    envp = VG_(env_clone)(VG_(client_envp));
> +    VG_(env_remove_valgrind_env_stuff)( envp, True /*ro_strings*/, NULL );
> + 
> +@@ -511,17 +508,9 @@ Int VG_(spawn) ( const HChar *filename, const HChar **argv )
> + #  undef COPY_CHAR_TO_ARGENV
> + #  undef COPY_STRING_TOARGENV
> + 
> +-   /* HACK: Temporarily restore the DATA rlimit for spawned child. */
> +-   VG_(setrlimit)(VKI_RLIMIT_DATA, &VG_(client_rlimit_data));
> +-
> +    SysRes res = VG_(do_syscall5)(__NR_spawn, (UWord) filename, (UWord) NULL, 0,
> +                                  (UWord) argenv, argenv_size);
> + 
> +-   /* Restore DATA rlimit back to its previous value set in m_main.c. */
> +-   struct vki_rlimit zero = { 0, 0 };
> +-   zero.rlim_max = VG_(client_rlimit_data).rlim_max;
> +-   VG_(setrlimit)(VKI_RLIMIT_DATA, &zero);
> +-
> +    VG_(free)(argenv);
> +    for (HChar **p = envp; *p != NULL; p++) {
> +       VG_(free)(*p);
> +diff --git a/coregrind/m_main.c b/coregrind/m_main.c
> +index 1821c9412fa7..9b659ae564b5 100644
> +--- a/coregrind/m_main.c
> ++++ b/coregrind/m_main.c
> +@@ -1627,7 +1627,6 @@ Int valgrind_main ( Int argc, HChar **argv, HChar **envp )
> +    Bool    logging_to_fd      = False;
> +    const HChar* xml_fname_unexpanded = NULL;
> +    Int     loglevel, i;
> +-   struct vki_rlimit zero = { 0, 0 };
> +    XArray* addr2dihandle = NULL;
> + 
> +    //============================================================
> +@@ -1800,13 +1799,15 @@ Int valgrind_main ( Int argc, HChar **argv, HChar **envp )
> +    VG_(debugLog)(1, "main", "... %s\n", VG_(name_of_launcher));
> + 
> +    //--------------------------------------------------------------
> +-   // Get the current process datasize rlimit, and set it to zero.
> +-   // This prevents any internal uses of brk() from having any effect.
> +-   // We remember the old value so we can restore it on exec, so that
> +-   // child processes will have a reasonable brk value.
> ++   // We used to set the process datasize rlimit to zero to prevent
> ++   // any internal use of brk() from having any effect. But later
> ++   // linux kernels redefine RLIMIT_DATA as the size of any data
> ++   // areas, including some dynamic mmap memory allocations.
> ++   // See bug #357833 for the commit that went into linux 4.5
> ++   // changing the definition of RLIMIT_DATA. So don't mess with
> ++   // RLIMIT_DATA here now anymore. Just remember it for use in
> ++   // the syscall wrappers.
> +    VG_(getrlimit)(VKI_RLIMIT_DATA, &VG_(client_rlimit_data));
> +-   zero.rlim_max = VG_(client_rlimit_data).rlim_max;
> +-   VG_(setrlimit)(VKI_RLIMIT_DATA, &zero);
> + 
> +    // Get the current process stack rlimit.
> +    VG_(getrlimit)(VKI_RLIMIT_STACK, &VG_(client_rlimit_stack));
> +diff --git a/coregrind/m_syswrap/syswrap-generic.c b/coregrind/m_syswrap/syswrap-generic.c
> +index aa60d675218e..061c1e1436b8 100644
> +--- a/coregrind/m_syswrap/syswrap-generic.c
> ++++ b/coregrind/m_syswrap/syswrap-generic.c
> +@@ -3014,9 +3014,6 @@ PRE(sys_execve)
> +       vg_assert(j == tot_args+1);
> +    }
> + 
> +-   /* restore the DATA rlimit for the child */
> +-   VG_(setrlimit)(VKI_RLIMIT_DATA, &VG_(client_rlimit_data));
> +-
> +    /*
> +       Set the signal state up for exec.
> + 
> +diff --git a/coregrind/m_syswrap/syswrap-solaris.c b/coregrind/m_syswrap/syswrap-solaris.c
> +index 25029d4d1d20..76df4692d1b3 100644
> +--- a/coregrind/m_syswrap/syswrap-solaris.c
> ++++ b/coregrind/m_syswrap/syswrap-solaris.c
> +@@ -1539,21 +1539,12 @@ PRE(sys_spawn)
> + #undef COPY_CHAR_TO_ARGENV
> + #undef COPY_STRING_TOARGENV
> + 
> +-   /* HACK: Temporarily restore the DATA rlimit for spawned child.
> +-      This is a terrible hack to provide sensible brk limit for child. */
> +-   VG_(setrlimit)(VKI_RLIMIT_DATA, &VG_(client_rlimit_data));
> +-
> +    /* Actual spawn() syscall. */
> +    SysRes res = VG_(do_syscall5)(__NR_spawn, (UWord) path, (UWord) attrs,
> +                                  attrs_size, (UWord) argenv, argenv_size);
> +    SET_STATUS_from_SysRes(res);
> +    VG_(free)(argenv);
> + 
> +-   /* Restore DATA rlimit back to its previous value set in m_main.c. */
> +-   struct vki_rlimit zero = { 0, 0 };
> +-   zero.rlim_max = VG_(client_rlimit_data).rlim_max;
> +-   VG_(setrlimit)(VKI_RLIMIT_DATA, &zero);
> +-
> +    if (SUCCESS) {
> +       PRINT("   spawn: process %d spawned child %ld\n", VG_(getpid)(), RES);
> +    }
> +@@ -3619,9 +3610,6 @@ PRE(sys_execve)
> +       VG_(sigprocmask)(VKI_SIG_SETMASK, &tst->sig_mask, NULL);
> +    }
> + 
> +-   /* Restore the DATA rlimit for the child. */
> +-   VG_(setrlimit)(VKI_RLIMIT_DATA, &VG_(client_rlimit_data));
> +-
> +    /* Debug-only printing. */
> +    if (0) {
> +       HChar **cpp;
> diff --git a/patches/valgrind-3.11.0/series b/patches/valgrind-3.11.0/series
> index ce22fcaa7c5d..0e52c90ad232 100644
> --- a/patches/valgrind-3.11.0/series
> +++ b/patches/valgrind-3.11.0/series
> @@ -2,4 +2,5 @@
>  #tag:base --start-number 1
>  0001-configure.ac-allow-all-arm-don-t-restrict-to-armv7.patch
>  0002-make-kernel-version-a-autoconf-cache-variable.patch
> -# 740ad5fce41b58864cb7c18bfefd385a  - git-ptx-patches magic
> +0003-Bug-357833-Setting-RLIMIT_DATA-to-zero-breaks-with-l.patch
> +# 7b968526952227e869b8c4514595e382  - git-ptx-patches magic
> -- 
> 2.7.0.rc3
> 
> 
> _______________________________________________
> ptxdist mailing list
> ptxdist@pengutronix.de

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

      reply	other threads:[~2016-02-11 11:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-01 15:34 Lucas Stach
2016-02-11 11:26 ` Michael Olbrich [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=20160211112641.GK32288@pengutronix.de \
    --to=m.olbrich@pengutronix.de \
    --cc=ptxdist@pengutronix.de \
    /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