Re: select system call's implementation may have some bug, need your help and confirm !!!

[Alan Jenkins]

On 10/9/09, wu Jianfeng <stormplayer@xxxxxxxxx> 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 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.
>
> see the comments after "##"
>
> int do_select(int n, fd_set_bits *fds, s64 *timeout)
> {
> struct poll_wqueues table;
> poll_table *wait;
> int retval, i;
>
> rcu_read_lock();
> retval = max_select_fd(n, fds);
> rcu_read_unlock();
>
> if (retval < 0)
> return retval;
> n = retval;
>
> poll_initwait(&table);
> wait = &table.pt;
> if (!*timeout)
> wait = NULL;
> retval = 0;
> for (;;) {
> unsigned long *rinp, *routp, *rexp, *inp, *outp, *exp;
> long __timeout;
>
> set_current_state(TASK_INTERRUPTIBLE);
> ## here set the process state TASK_INTERRUPTIBLE
>
>  ## if  the process was scheduled out here, then the process will
> never can be waked up, because it has not been attached to any file 's
> wait queue.

I'm not sure about that, but if you look at the current code (e.g. in
linus' git tree) you will see this code has been changed.  Now
set_current_state() is only called from poll_schedule_timeout(), and
it won't suffer from the problem you suggested:


int poll_schedule_timeout(struct poll_wqueues *pwq, int state,
			  ktime_t *expires, unsigned long slack)
{
	int rc = -EINTR;

	set_current_state(state);
	if (!pwq->triggered)
		rc = schedule_hrtimeout_range(expires, slack, HRTIMER_MODE_ABS);
	__set_current_state(TASK_RUNNING);


I don't know the specific reason this was changed.  Try looking at the
git history if you're still curious.

Regards
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/