[PATCH] Fix SAK_work workqueue initialization.
Somewhere in the rewrite of the work queues my cleanup of SAK handling
got broken. Maybe I didn't retest it properly or possibly the API
was changing so fast I missed something. Regardless currently
triggering a SAK now generates an ugly BUG_ON and kills the kernel.
Thanks to Alexey Dobriyan <adobriyan@openvz.org> for spotting this.
This modifies the use of SAK_work to initialize it when the data
structure it resides in is initialized, and to simply call
schedule_work when we need to generate a SAK. I update both
data structures that have a SAK_work member for consistency.
All of the old PREPARE_WORK calls that are now gone.
If we call schedule_work again before it has processed it
has generated the first SAK it will simply ignore the duplicate
schedule_work request.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index 94ce3e7..c3f8e38 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -2635,6 +2635,7 @@
*/
for (currcons = 0; currcons < MIN_NR_CONSOLES; currcons++) {
vc_cons[currcons].d = vc = alloc_bootmem(sizeof(struct vc_data));
+ INIT_WORK(&vc_cons[currcons].SAK_work, vc_SAK);
visual_init(vc, currcons, 1);
vc->vc_screenbuf = (unsigned short *)alloc_bootmem(vc->vc_screenbuf_size);
vc->vc_kmalloced = 0;