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:	Thu, 08 Mar 2007 14:53:51 +0100
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"linux-os (Dick Johnson)" <linux-os@...logic.com>
Cc:	Luong Ngo <luong.ngo@...il.com>,
	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: Sleeping thread not receive signal until it wakes up

On Thu, 2007-03-08 at 08:01 -0500, linux-os (Dick Johnson) wrote:
> > Anything kernel configuration I need to be aware of to enable
> > preemption in kernel?
> >
> >
> > Thank you,
> > LNgo
> >
> 
> First, in the ioctl, if you need spin-locks, you need to use
> spin_lock_irqsave/spin_unlock/irqrestore. The ones that don't
> save and restore are for the ISR where we know that the interrupts
> are already off and don't intend to turn them on. Further, make

As usual completely wrong:

ioctl code is called with interrupts enabled. So if you need to protect
against interrupts it is completely correct to use spin_lock_irq /
spin_unlock_irq. There is nothing to save and nothing to restore.

> sure that you don't try to schedule() with the interrupts off.
> 
> interruptible_sleep_on(&qu);
>                          ^______ Where is this?

Not included in the pseudo code.

> This must be accessible both in the ISR and in the ioctl(). It
> also needs to have been properly initialized when your module
> was installed (see numerious code samples in the kernel).

Instead of blurbing about obvious things you should point Luong to the
real problems:

include/linux/wait.h:
/*
 * These are the old interfaces to sleep waiting for an event.
 * They are racy.  DO NOT use them, use the wait_event* interfaces above.
 * We plan to remove these interfaces during 2.7.
 */
extern void FASTCALL(sleep_on(wait_queue_head_t *q));
extern long FASTCALL(sleep_on_timeout(wait_queue_head_t *q,
                                      signed long timeout));
extern void FASTCALL(interruptible_sleep_on(wait_queue_head_t *q));
extern long FASTCALL(interruptible_sleep_on_timeout(wait_queue_head_t *q,
                                                    signed long timeout));

Luong, please use wait_event_interruptible() instead.

	spin_lock_irq(dev->lock);
	do_whatever_you_need_to_initialize(dev);
	dev->event_happened = 0;
	spin_unlock_irq(dev->lock);
	
	res = wait_event_interruptible(&dev->queue, dev->event_happened != 0);

Thanks,

	tglx


-
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