removal of sync in panic

I can imagine several changes but I am not sure if this is a problem which must be fixed and which fix is the best.
Here are my alternatives:

1. remove sys_sync completely: syslogd and klogd use fsync. No need to help them. Furthermore we have a severe problem which is worth a panic, so we better dont do any I/O.

3. Add an

        if (doing_io())
                printk(KERN_EMERG "In I/O routine - not syncing\n");

check like in_interrupt check. Unfortunately I have no clue how this can be achieved and it looks quite ugly.

Quoted 3 lines

1. remove sys_sync completely: syslogd and klogd use fsync. No need to help them. Furthermore we have a severe problem which is worth a panic, so we better dont do any I/O.

I've seen exactly the behaviour you describe and would be inclined to go for this option too.

Quoted 6 lines · Lars Marowsky-Bree

Quoted 3 lines

1. remove sys_sync completely: syslogd and klogd use fsync. No need to help them. Furthermore we have a severe problem which is worth a panic, so we better dont do any I/O.

I've seen exactly the behaviour you describe and would be inclined to go for this option too.

As this problem definitely exists, here is a patch.

kernel/panic.c 2004-07-14 19:37:02.000000000 +0200 renamed from kernel/panic.c 2004-06-16 07:20:04.000000000 +0200 +0 -1

@@ -59,13 +59,7 @@ NORET_TYPE void panic(const char * fmt,
        va_start(args, fmt);
        vsnprintf(buf, sizeof(buf), fmt, args);
        va_end(args);
-       printk(KERN_EMERG "Kernel panic: %s\n",buf);

I agree with the patch in principle, but I'd be interested in what observed problem motivated it?

I have seen panic failing two times lately on an SMP system. The box panic'ed but was running happily on the other cpus. The culprit of this failure is the fact, that these panics have been caused by a block device or a filesystem (e.g. using errors=panic). In these cases the likelihood of a failure/hang of sys_sync() is high. This is exactly what happened in both cases I have seen. Meanwhile the other cpus are happily continuing destroying data as the kernel has a severe problem but its not aware of that as smp_send_stop happens after sys_sync.

Quoted 2 lines · Andrew Morton

I agree with the patch in principle, but I'd be interested in what observed problem motivated it?

see the first posting.

-----------snip--------------
I have seen panic failing two times lately on an SMP system. The box panic'ed but was running happily on the other cpus. The culprit of this failure is the fact, that these panics have been caused by a block device or a filesystem (e.g. using errors=panic). In these cases the likelihood of a failure/hang of sys_sync() is high. This is exactly what happened in both cases I have seen. Meanwhile the other cpus are happily continuing destroying data as the kernel has a severe problem but its not aware of that as smp_send_stop happens after sys_sync.

I can imagine several changes but I am not sure if this is a problem which must be fixed and which fix is the best.
Here are my alternatives:

1. remove sys_sync completely: syslogd and klogd use fsync. No need to help them. Furthermore we have a severe problem which is worth a panic, so we better dont do any I/O.
2. move smp_send_stop before sys_sync. This at least prevents other cpus of doing harm if sys_sync hangs. Here I am not sure if this is really working.
3. Add an

        if (doing_io())
                printk(KERN_EMERG "In I/O routine - not syncing\n");

check like in_interrupt check. Unfortunately I have no clue how this can be achieved and it looks quite ugly.
---------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Yes, I've seen this multiple times.
I also agree that it seems a sensible patch. I have one dumb question. Given that we're panicing and we know things are "bad", is there any reason not to call smp_send_stop() as early as possible, rather than as the last thing which we currently do? As you say, the other cpus are happily continuing, potentially destroying data, and it seems that stopping this as quickly as possible would be desirable.