linux-kernel - RE: futex question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DDFD17CC94A9BD49A82147DDF7D545C501FD8752@exchange.ZeugmaSystems.local>
Date:	Mon, 5 Oct 2009 11:11:00 -0700
From:	"Anirban Sinha" <ASinha@...gmasystems.com>
To:	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
	"Thomas Gleixner" <tglx@...utronix.de>
Cc:	"Anirban Sinha" <ani@...rban.org>, "Ingo Molnar" <mingo@...e.hu>,
	<linux-kernel@...r.kernel.org>, "Darren Hart" <dvhltc@...ibm.com>,
	"Kaz Kylheku" <KKylheku@...gmasystems.com>
Subject: RE: futex question


>
>The problem with the patch send my Ani is that it clears the robust
>lists before the point of no return, so on a failing execve() we'd have
>messed up the state.

Ah! yes. I should have added the lines after load_binary() succeeds:

 fs/compat.c |    3 +++
 fs/exec.c   |    3 +++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/fs/compat.c b/fs/compat.c
index 6d6f98f..7d1baf5 100644
--- a/fs/compat.c
+++ b/fs/compat.c
@@ -1539,6 +1539,9 @@ int compat_do_execve(char * filename,
        if (retval < 0)
                goto out;

+#ifdef CONFIG_FUTEX
+       current->compat_robust_list = NULL;
+#endif
        /* execve succeeded */
        current->fs->in_exec = 0;
        current->in_execve = 0;
diff --git a/fs/exec.c b/fs/exec.c
index 172ceb6..d7b4ca3 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1354,6 +1354,9 @@ int do_execve(char * filename,
        if (retval < 0)
                goto out;

+#ifdef CONFIG_FUTEX
+       current->robust_list = NULL;
+#endif
        /* execve succeeded */
        current->fs->in_exec = 0;
        current->in_execve = 0;



btw, by the same token, shouldn't we call sched_exec() after the exec()
actually succeeds and the process has a new mm (thus having a smallest
effective memory and cache footprint)? I know that I could be missing
something subtle.

Ani

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/