[PATCH] don't call unblank at irq time

From: Benjamin Herrenschmidt (benh_at_kernel.crashing.org)
Date: 03/11/05

  • Next message: DHollenbeck: "[PATCH] sealevel 8 port RS-232/RS-422/RS-485 board"
    To: Andrew Morton <akpm@osdl.org>
    Date:	Fri, 11 Mar 2005 16:37:14 +1100
    
    

    Hi !

    This patch removes the call to unblank() from printk, and avoids calling
    unblank at irq() time _unless_ oops_in_progress is 1. I also export
    oops_in_progress() so drivers who care like radeonfb can test it and
    know what to do. I audited call sites of unblank_screen(),
    console_unblank(), etc... and I _hope_ I got them all, the patch
    includes a small patch to the s390 bust_spinlocks code that sets
    oops_in_progress back to 0 _after_ unblanking for example.

    I added a few might_sleep() to help us catch possible remaining callers.

    I'll soon write a document explaining fbdev locking. The current
    situation after this patch is that:

     - All callbacks have console_semaphore held (fbdev's are fully
    serialised).

     - Everything is called in schedule'able context, except the cfb_*
    rendering operations and cursor operations, with the special case of
    unblank who can be called at any time when "oops_in_progress" is true. A
    driver that needs to sleep in it's unblank implementation is welcome to
    test that variable and use a fallback path (or just do nothing if it's
    not simple).

    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

    Index: linux-work/kernel/printk.c
    ===================================================================
    --- linux-work.orig/kernel/printk.c 2005-03-10 11:37:34.000000000 +1100
    +++ linux-work/kernel/printk.c 2005-03-11 14:51:42.000000000 +1100
    @@ -54,7 +54,12 @@
     
     EXPORT_SYMBOL(console_printk);
     
    +/*
    + * Low lever drivers may need that to know if they can schedule in
    + * their unblank() callback or not. So let's export it.
    + */
     int oops_in_progress;
    +EXPORT_SYMBOL(oops_in_progress);
     
     /*
      * console_sem protects the console_drivers list, and also
    @@ -744,12 +749,15 @@
             struct console *c;
     
             /*
    - * Try to get the console semaphore. If someone else owns it
    - * we have to return without unblanking because console_unblank
    - * may be called in interrupt context.
    + * console_unblank can no longer be called in interrupt context unless
    + * oops_in_progress is set to 1..
              */
    - if (down_trylock(&console_sem) != 0)
    - return;
    + if (oops_in_progress) {
    + if (down_trylock(&console_sem) != 0)
    + return;
    + } else
    + acquire_console_sem();
    +
             console_locked = 1;
             console_may_schedule = 0;
             for (c = console_drivers; c != NULL; c = c->next)
    Index: linux-work/arch/s390/mm/fault.c
    ===================================================================
    --- linux-work.orig/arch/s390/mm/fault.c 2005-01-24 17:09:26.000000000 +1100
    +++ linux-work/arch/s390/mm/fault.c 2005-03-11 14:46:21.000000000 +1100
    @@ -62,8 +62,8 @@
                     oops_in_progress = 1;
             } else {
                     int loglevel_save = console_loglevel;
    - oops_in_progress = 0;
                     console_unblank();
    + oops_in_progress = 0;
                     /*
                      * OK, the message is on the console. Now we call printk()
                      * without oops_in_progress set so that printk will give klogd
    Index: linux-work/drivers/char/vt.c
    ===================================================================
    --- linux-work.orig/drivers/char/vt.c 2005-03-10 11:37:24.000000000 +1100
    +++ linux-work/drivers/char/vt.c 2005-03-11 14:54:05.000000000 +1100
    @@ -2220,9 +2220,6 @@
             }
             set_cursor(vc);
     
    - if (!oops_in_progress)
    - poke_blanked_console();
    -
     quit:
             clear_bit(0, &printing);
     }
    @@ -2823,6 +2820,13 @@
     {
             struct vc_data *vc;
     
    + /* This should now always be called from a "sane" (read: can schedule)
    + * context for the sake of the low level drivers, except in the special
    + * case of oops_in_progress
    + */
    + if (!oops_in_progress)
    + might_sleep();
    +
             WARN_CONSOLE_UNLOCKED();
     
             ignore_poke = 0;
    @@ -2879,6 +2883,14 @@
     {
             WARN_CONSOLE_UNLOCKED();
     
    + /* Add this so we quickly catch whoever might call us in a non
    + * safe context. Nowadays, unblank_screen() isn't to be called in
    + * atomic contexts and is allowed to schedule (with the special case
    + * of oops_in_progress, but that isn't of any concern for this
    + * function. --BenH.
    + */
    + might_sleep();
    +
             /* This isn't perfectly race free, but a race here would be mostly harmless,
              * at worse, we'll do a spurrious blank and it's unlikely
              */

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: DHollenbeck: "[PATCH] sealevel 8 port RS-232/RS-422/RS-485 board"

    Relevant Pages

    • [-mm PATCH] neofb: enable LCD properly on unblank
      ... has been removed from the -mm tree. ... This patch was probably dropped from -mm because ... Reading those again on unblank will simply not reactivate the LCD, ... unsigned char PanelDispCntlReg1; ...
      (Linux-Kernel)
    • [05/11] Fix i2c messsage flags in video drivers
      ... The drivers improperly copy the i2c client ... flags as the message flags, while both sets are mostly unrelated. ... I think this patch qualifies hands down as a "critical bug fix" to be ... To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - ...
      (Linux-Kernel)
    • Re: [PATCH 0/23] reboot-fixes
      ... >> Presumably it unfixes Pavel's patch? ... > the suspend path. ... > But those are among the few drivers that do anything in either ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11
      ... the patch should be okay. ... Perhaps most of the USB drivers don't care whether interrupts ... are enabled or not in their completion routines. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: RT patch acceptance
      ... Look at the patch. ... You're the one spreading FUD that preempt-RT is as good as RTAI, ... even worse than local_irq_disable isn't used in drivers or not safe to ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)