sched_4bsd: remove dumping from maybe_preempt()

[mchoo]

Summary

'dumping' is true only when kernel is dumping after crash (see
minidumpsys()) so KERNEL_PANICKED() will catch this.

MFC after: 2 weeks
MFC to: stable/14, stable/15
Sponsored by: FreeBSD Foundation

[olce]

Mmm, that's not true since we have been having live (mini)dump. On the contrary, it is perhaps time to put back dumping here and in ULE.

[mchoo]

In D59395#1363961, @olce wrote:

Mmm, that's not true since we have been having live (mini)dump. On the contrary, it is perhaps time to put back dumping here and in ULE.

Makes sense, I'll open a new revision for that.

[mchoo]

Actually, dumping is not set to true during live dump, so I think the patch is still correct.

int
minidumpsys(struct dumperinfo *di, bool livedump)
{
	struct minidumpstate state;
	struct msgbuf mb_copy;
	char *msg_ptr;
	int error;

	if (livedump) {
		KASSERT(!dumping, ("live dump invoked from incorrect context"));

[mchoo]

Update commit message

[mchoo]

Remove duplicated commit message template

[olce]

On second thought, there is a balance between getting a consistent dump image and temporary disruption of the live system for live dumps. It's already the case that they do not guarantee a fully consistent image. And they don't try to stop CPUs, the scheduler, etc. As you point out, minidump is not set, which in this line of thinking is not surprising.

So let's proceed with that.