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]
Message-Id: <200706152334.40387.dtor@insightbb.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ