[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20081210040417.4EBBFFC362@magilla.sf.frob.com>
Date: Tue, 9 Dec 2008 20:04:17 -0800 (PST)
From: Roland McGrath <roland@...hat.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Oleg Nesterov <oleg@...sign.ru>, Ingo Molnar <mingo@...e.hu>,
LKML <linux-kernel@...r.kernel.org>,
Ulrich Weigand <ulrich.weigand@...ibm.com>
Subject: Re: [PATCH, RFC] revert breakage from "tracehook: exec"
Thanks for the report, good catch. I've written a test case for the bug
(I'll include it with the patch I post momentarily). (Note to testers:
this bug does not manifest on Fedora kernels.)
I still think it's preferable to have the only tracehook calls be in core
code, rather than in binfmt modules. It seems much less error-prone in the
long run. Also, since we no longer export ptrace_notify(), we'd have to
revert that as well to move the calls into binfmt modules when built as
modules (I think your patch will barf on CONFIG_BINFMT_AOUT=m, e.g.).
One option would be to move the call further out, to do_execve (and
compat_do_execve). But I would like to keep the binfmt and bprm pointers
available in tracehook_report_exec() with full information about the binfmt
and bprm->file still available. Even though that's not currently used, it
will clearly be desireable for future tracing facilities to be able to
scavenge details from there.
My fix (next posting) leaves the call in search_binary_handler(),
but makes it only on the outermost call (using bprm->recursion_depth).
Thanks,
Roland
--
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/
Powered by blists - more mailing lists