Date: Mon, 30 Jan 2012 21:27:27 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Dmitry Mikulin <dmitrym@juniper.net> Cc: freebsd-current Current <freebsd-current@freebsd.org>, Marcel Moolenaar <marcelm@juniper.net> Subject: Re: [ptrace] please review follow fork/exec changes Message-ID: <20120130192727.GZ2726@deviant.kiev.zoral.com.ua> In-Reply-To: <4F26E0D1.8040100@juniper.net> References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> <20120125074824.GD2726@deviant.kiev.zoral.com.ua> <4F2094B4.70707@juniper.net> <20120126122326.GT2726@deviant.kiev.zoral.com.ua> <4F22E8FD.6010201@juniper.net> <20120129074843.GL2726@deviant.kiev.zoral.com.ua> <4F26E0D1.8040100@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--0hyMCxJS7FIePeVX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jan 30, 2012 at 10:26:25AM -0800, Dmitry Mikulin wrote:
>=20
>=20
> On 01/28/2012 11:48 PM, Kostik Belousov wrote:
> >On Fri, Jan 27, 2012 at 10:12:13AM -0800, Dmitry Mikulin wrote:
> >>Attached are 4 separate patches for each somewhat independent portion =
of
> >>the kernel work related to the follow-fork implementation.
> >Ok, as I said, I think that vfork-fork.patch is just wrong.
>=20
> Gdb needs to be able to read/write process memory between the time the=20
> child is forked and exec is called (in the vfork case). Without the chang=
e=20
> it causes a kernel panic when gdb tries to read/write process memory. Sin=
ce=20
> my understanding of the kernel is a bit limited, it was the best I could =
do=20
> at the time. I will send more details about the panic once I get a workin=
g=20
> fbsd system again. Maybe there's a better way to deal with the panic.
Please provide more details, I am looking forward for the panic
message and backtrace.
>=20
> >Lets postpone discussion of the orphan.patch for later.
>=20
> OK.
>=20
> >
> >The follow-fork.patch and follow-exec.patch make me wonder, and I
> >already expressed my doubts. IMO, all features, except one bug, are
> >already presented in the stock src.
> >
> >More, suggested follow-{fork,exec} patches break the SCE/SCX tracers
> >notification of fork and exec events, since TDB_FORK and TBD_EXEC flags
> >are consumed before syscall returns (I also said this previously).
>=20
>=20
>=20
>=20
> >
> >Namely, if the process is being debugged, the successfull [f]execve()
> >causes unconditional stop even. This makes PT_FOLLOW_EXEC unneccessary.
> >
> >Existing PT_FOLLOW_FORK implementation indeed has a bug, which was not
> >revealed by my testing during the development, because I only tested
> >SCE/SCX scenario. Namely, if PT_FOLLOW_FORK is requested, but the next
> >stop is not SCX, then follow-fork notification is not sent. After this
> >nit is fixed, PT_FOLLOW_FORK caller gets stops for the child creation.
> >Child is put into stop state as needed to not loose it.
>=20
> I think this will fix only a part of the problem, the one that relates to=
=20
> PT_CONTINUE.
>=20
> I still need the change that forces a stop in both child and parent on=20
> fork(). Without my changes the notification is generated in the child but=
=20
> not in the parent. I need to be able to have both processes stopped in gd=
b=20
> in order to clean up and detach from the parent, and initialize and attac=
h=20
> to the child. The main reason I need both processes stopped is that gdb h=
as=20
> to be able to read/write into both processes address space and registers.=
=20
> Ideally I would like to have a single event generated for fork() at a poi=
nt=20
> where both child and parent are stopped and available for ptrace read/wri=
te=20
> requests. Do you think it's possible?
The lack of the notification for parent is exactly what the patch I
posted fixes. More exactly, it is the lack of notification for parent
with PT_CONTINUE loop. I will commit this today.
Regarding a single notification. Currently, parent arrives at the
syscall return code only after the child is attached to the debugger.
See the cv_wait() in kern_fork.c:739. In other words, if you get the
PL_FLAG_FORK, the child is already attached (at last it shall be). My
scescx.c code illustrates this well, IMO.
You still get a separate stop from the child, but I do not see how is it
harmful.
--0hyMCxJS7FIePeVX
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAk8m7x8ACgkQC3+MBN1Mb4ivfQCg5u5En+NVmD/0ZzPNUvv2AvXX
C2QAoKM1fcZjqnvhOoXCYrL7wFWPlqDS
=MLgx
-----END PGP SIGNATURE-----
--0hyMCxJS7FIePeVX--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120130192727.GZ2726>