linux-kernel - Re: [PATCH] Video : Amba: Use in_interrupt() in clcdfb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 11 Mar 2012 17:05:51 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	santosh prasad nayak <santoshprasadnayak@...il.com>
Cc:	FlorianSchandinat@....de, linux-fbdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] Video : Amba: Use in_interrupt() in clcdfb_sleep().

On Sun, Mar 11, 2012 at 10:27:12PM +0530, santosh prasad nayak wrote:
> Russel,
> 
> Is this what you want ?
> 
>  static inline void clcdfb_sleep(unsigned int ms)
>  {
> -       if (in_atomic()) {
>                 mdelay(ms);
> -       } else {
> -               msleep(ms);
> -       }
>  }

"want" is a strong word - I would not say "want" because I don't want the
system busy-spinning for 20ms at a time during normal blank and unblank
events preventing any other thread in the system from running.

Looking at do_unblank_screen() in drivers/tty/vt/vt.c:

/*
 * Called by timer as well as from vt_console_driver
 */
void do_unblank_screen(int leaving_gfx)
{
        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();

There may be another option of changing in_atomic() to be oops_in_progress()
if that comment is to be believed.  However, that comment conflicts with
the comment immediately above the function.  That said, the code is more
authorative than the comment above it because if that comment were true,
we'd see might_sleep() warnings.

So, I suspect:

 static inline void clcdfb_sleep(unsigned int ms)
 {
-       if (in_atomic()) {
+       if (oops_in_progress) {
                mdelay(ms);
        } else {
                msleep(ms);

is about the best that can be hoped for.

However, I think framebuffer people need to comment about what contexts
a framebuffer driver's fb_blank method would be called from (including
when oops-dumping.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/