linux-kernel - Re: the select system call's implementation may have some bug in preempt kernel mode

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: <alpine.LFD.2.00.0910090849400.9428@localhost.localdomain>
Date:	Fri, 9 Oct 2009 09:02:37 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	wu Jianfeng <stormplayer@...il.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: the select system call's implementation may have some bug in
 preempt kernel mode

On Fri, 9 Oct 2009, wu Jianfeng wrote:
> A process may sleep for ever when he call select system call.
> In detail, if the process was scheduled out just at the point it set
> its state to TASK_INTERRUPTIBLE.
> 
> The events that may cause the process to be scheduled out is(in
> preempt kernel) :
> 1) time interrupt and the process's time slice is exhausted.
> 2) an interrupt accured, and wake up another process with high priority.

Right, but that does not cause the task to be scheduled out for ever.

> 		set_current_state(TASK_INTERRUPTIBLE);   ######## here set the
> interrupt to  TASK_INTERRUPTIBLE state
> 
>                ########### if the process was schedued out here, it
> will can never been waken up .
>                ########### Because the process wasn't attached to any
> file's waitqueue at this point yet

When the task is scheduled out at that point, it is not
deactivated. It is preempted, which means it stays on the run queue
despite of the TASK_INTERRUPTIBLE state and is scheduled back in later
on.

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/