Date: Mon, 27 Dec 2021 21:15:53 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Gleb Smirnoff <glebius@freebsd.org> Cc: Alexander Motin <mav@freebsd.org>, Larry Rosenman <ler@lerctr.org>, current@freebsd.org Subject: Re: My -CURRENT crashes.... Message-ID: <YcoQ6T4P9ytRSjWQ@kib.kiev.ua> In-Reply-To: <YcoMupvrXwzEgFkb@FreeBSD.org> References: <286c830efc0e12e3e7a7e9b2ede31c28@lerctr.org> <Ycn4Y7ZUE%2BBWM3tr@FreeBSD.org> <45ee5689-b24c-51b5-d7b7-33fd73ee7dce@FreeBSD.org> <YcoMupvrXwzEgFkb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 27, 2021 at 10:58:02AM -0800, Gleb Smirnoff wrote: > On Mon, Dec 27, 2021 at 01:43:01PM -0500, Alexander Motin wrote: > A> > This allows us to deduct that the callout belongs to proc subsystem and > A> > we can retrieve the proc it points to: c_lock - 0x128 = 0xfffff8030521e548 > A> > It is ccache in PRS_NORMAL state. And the "tmp" in our stack frame is its > A> > p_itcallout. > A> > > A> > So there is something that would zero out most of the p_itcallout while > A> > it is scheduled? > A> > A> So carefully zero it, but keep the lock pointer... The only way that > A> comes to mind is callout_init_mtx() in do_fork() if we assume the > A> process has completed and the struct proc was reused. I guess if we > A> could somehow leak scheduled callout in exit1(). May be we could add > A> some more assertions to try catch callout still being active there. > > Note that _callout_stop_safe(p_itcallout) is the only place in kernel where > CS_EXECUTING is used. I would start asking are there any third-party modules loaded.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YcoQ6T4P9ytRSjWQ>