linux-kernel - Re: 2.6.22-rc[23]: blinking capslock led, stuck keys?

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:	Fri, 15 Jun 2007 23:34:39 -0400
From:	Dmitry Torokhov <dtor@...ightbb.com>
To:	Indan Zupancic <indan@....nu>
Cc:	Pavel Machek <pavel@....cz>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Andi Kleen <ak@...e.de>, Jiri Kosina <jikos@...os.cz>,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.22-rc[23]: blinking capslock led, stuck keys?

On Friday 15 June 2007 22:04, Indan Zupancic wrote:
> On Fri, June 15, 2007 07:41, Dmitry Torokhov wrote:
> >  /*
> > + * Schedule switch for execution. We need to throttle requests,
> > + * otherwise keyboard may become unresponsive.
> > + */
> > +static void atkbd_schedule_event_work(struct atkbd *atkbd, int event_bit)
> > +{
> > +	unsigned long delay = msecs_to_jiffies(50);
> > +
> > +	if (time_after(jiffies, atkbd->event_jiffies + delay))
> > +		delay = 0;
> > +
> > +	atkbd->event_jiffies = jiffies;
> > +	set_bit(event_bit, &atkbd->event_mask);
> > +	wmb();
> > +	schedule_delayed_work(&atkbd->event_work, delay);
> > +}
> 
> I don't know whether schedule_delayed_work() requeues event_work, or if
> it adds more work, but both seem to give wrong behaviour:

Well, my advise would be to research the matter before saying that
it will not work.

> In the first case 
> event_work can be postponed forever if atkbd_schedule_event_work() is
> called repeatedly each time within 50 ms, and for the second case there's a
> delay added, but the number of times the LED is switched stays the same,
> so it's not being throttled.
> 

No, once work is queued for execution subsequent attempts to queue the
same work will be ignored (until work starts executing). Therefore first
time work will be scheduled for execution immediately and then execution
be spaced by ~50 ms.

-- 
Dmitry
-
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/