Date: Tue, 1 Nov 2016 17:49:37 -0500 From: Eric Badger <badger@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Crashes with 'reboot -d' Message-ID: <5580d308-3e10-76b8-c762-63a69ff2eadb@FreeBSD.org> In-Reply-To: <20161101124030.GC54029@kib.kiev.ua> References: <b2b9dd83-239d-57b9-0f7c-5bbd19b69dde@FreeBSD.org> <20161101124030.GC54029@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/01/2016 07:40, Konstantin Belousov wrote:
> On Mon, Oct 31, 2016 at 05:07:25PM -0500, Eric Badger wrote:
>> I've run into crashes when using 'reboot -d' (or a slightly tweaked
>> version of it in our FreeBSD spin at work). The problem is that dump
>> code is written to run in a panic/crash scenario, when all other CPUs
>> are stopped. In the case of 'reboot -d', all other CPUs are not stoppe=
d.
>> The code in xpt_polled_action runs what would normally be done by the
>> interrupt handler, polling start_ccb->ccb_h.status to see when the
>> operation has been completed. If the real interrupt handler is still
>> running, however, polling start_ccb->ccb_h.status is not sufficient; t=
he
>> ccb may be placed in the cam kproc's doneq after start_ccb->ccb_h.stat=
us
>> has been updated. The dumper will reuse the ccb's memory, but when the
>> cam kproc processes that item in its doneq, it will twiddle bits and
>> corrupt the now reused ccb memory.
>>
>> I fixed this by shutting off other CPUs when doing a dump during reboo=
t
>> (patch below). This seems fine, but perhaps heavy handed. I also
>> experimented with letting the normal interrupt handler and cam kproc d=
o
>> the work when we're not in a SCHEDULER_STOPPED() scenario. This seemed
>> to reduce dump performance and make performance less consistent, but
>> otherwise worked ok.
>>
>> I'd appreciate any comments on things I may have failed to consider. I=
f
>> no objections are raised, I will proceed with the patch here.
>>
>> Thanks,
>> Eric
>>
>> diff --git a/sys/kern/kern_shutdown.c b/sys/kern/kern_shutdown.c
>> index 79c4c30..bdc0182 100644
>> --- a/sys/kern/kern_shutdown.c
>> +++ b/sys/kern/kern_shutdown.c
>> @@ -319,8 +319,9 @@ void
>> kern_reboot(int howto)
>> {
>> static int once =3D 0;
>> +#ifdef SMP
>> + cpuset_t other_cpus;
>>
>> -#if defined(SMP)
>> /*
>> * Bind us to CPU 0 so that all shutdown code runs there. Som=
e
>> * systems don't shutdown properly (i.e., ACPI power off) if w=
e
>> @@ -362,8 +363,28 @@ kern_reboot(int howto)
>> */
>> EVENTHANDLER_INVOKE(shutdown_post_sync, howto);
>>
>> - if ((howto & (RB_HALT|RB_DUMP)) =3D=3D RB_DUMP && !cold && !dumpin=
g)
>> + if ((howto & (RB_HALT|RB_DUMP)) =3D=3D RB_DUMP && !cold && !dumping)=
{
>> +#ifdef SMP
>> + /*
>> + * Dump code assumes that all other CPUs have stopped, and thus
>> + * handles disk interrupts manually. This assumption must be enforce=
d,
>> + * as otherwise the real interrupt handler may race with the dumper.
>> + */
>> + if (!SCHEDULER_STOPPED()) {
>> + spinlock_enter();
>> +
>> + other_cpus =3D all_cpus;
>> + CPU_CLR(PCPU_GET(cpuid), &other_cpus);
>> + stop_cpus_hard(other_cpus);
>> +
>> + curthread->td_stopsched =3D 1;
>> +
>> + /* Module shutdown is no longer safe. */
>> + howto |=3D RB_NOSYNC;
>> + }
>> +#endif
>> doadump(TRUE);
>> + }
>>
>> /* Now that we're going to really halt the system... */
>> EVENTHANDLER_INVOKE(shutdown_final, howto);
>>
>>
>=20
> Such stop heavily relies on the fact that other CPUs do not perform any
> cam-related activity in parallel. It might be not true, e.g. if some
> notifications are supplied by an HBA to OS. Also, other CPUs might
> own some resources which are needed by the io subsystem still, e.g.
> busdma or vm locks. This would reduce the probability of working dump.
My confidence that stopping CPUs was ok was bolstered because this is
the same path taken during a panic, when all CPUs have similarly been
stopped. In such a case, I would also expect us to bypass locking, and
the dump code itself is written to work without interrupts enabled.
However, I haven't examined all the various drivers' dump code; there
certainly could be some drivers that won't work after CPUs have been
stopped but would if they hadn't been stopped.
>=20
> Could the dumper ccb marked by some flag to prevent doneq from freeing
> or modifying the memory and to keep the dumper using it ?
>=20
You could do this. Practically, it avoids my problem on the system where
I see it most. However, the other issue is that the 'sim_poll'
implementations of some drivers don't appear safe to run when the
interrupt handler is also up and running. One or the other would need to
be stopped, or the drivers would need to be changed so that both can
safely be running at the same time. I experimented a little bit here
(stopping sim_poll when SCHEDULER_STOPPED()), but perhaps could find a
more correct solution.
Thanks,
Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5580d308-3e10-76b8-c762-63a69ff2eadb>