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

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

[wu Jianfeng]

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.

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

		inp = fds->in; outp = fds->out; exp = fds->ex;
		rinp = fds->res_in; routp = fds->res_out; rexp = fds->res_ex;

		for (i = 0; i < n; ++rinp, ++routp, ++rexp) {
			unsigned long in, out, ex, all_bits, bit = 1, mask, j;
			unsigned long res_in = 0, res_out = 0, res_ex = 0;
			struct file_operations *f_op = NULL;
			struct file *file = NULL;

			in = *inp++; out = *outp++; ex = *exp++;
			all_bits = in | out | ex;
			if (all_bits == 0) {
				i += __NFDBITS;
				continue;
			}

			for (j = 0; j < __NFDBITS; ++j, ++i, bit <<= 1) {
				if (i >= n)
					break;
				if (!(bit & all_bits))
					continue;
				file = fget(i);
				if (file) {
					f_op = file->f_op;
					mask = DEFAULT_POLLMASK;
					if (f_op && f_op->poll)
						mask = (*f_op->poll)(file, retval ? NULL : wait);
					fput(file);
					if ((mask & POLLIN_SET) && (in & bit)) {
						res_in |= bit;
						retval++;
					}
					if ((mask & POLLOUT_SET) && (out & bit)) {
						res_out |= bit;
						retval++;
					}
					if ((mask & POLLEX_SET) && (ex & bit)) {
						res_ex |= bit;
						retval++;
					}
				}
				cond_resched();
			}
			if (res_in)
				*rinp = res_in;
			if (res_out)
				*routp = res_out;
			if (res_ex)
				*rexp = res_ex;
		}
		wait = NULL;
		if (retval || !*timeout || signal_pending(current))
			break;
		if(table.error) {
			retval = table.error;
			break;
		}

		if (*timeout < 0) {
			/* Wait indefinitely */
			__timeout = MAX_SCHEDULE_TIMEOUT;
		} else if (unlikely(*timeout >= (s64)MAX_SCHEDULE_TIMEOUT - 1)) {
			/* Wait for longer than MAX_SCHEDULE_TIMEOUT. Do it in a loop */
			__timeout = MAX_SCHEDULE_TIMEOUT - 1;
			*timeout -= __timeout;
		} else {
			__timeout = *timeout;
			*timeout = 0;
		}
		__timeout = schedule_timeout(__timeout);
		if (*timeout >= 0)
			*timeout += __timeout;
	}
	__set_current_state(TASK_RUNNING);

	poll_freewait(&table);

	return retval;
}

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

[Thomas Gleixner]

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

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

[wu Jianfeng]

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

I don't know why ???
the process state is TASK_INTERRUPTIBLE, and was scheduled out.

if no one wake up it or any signals received, it will sleep for ever.
The process does't entered any file's wait queue at that point, so I
am sure no one will wake up it.

Am i right?


2009/10/9 Thomas Gleixner <tglx@linutronix.de>:
> 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
>

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

[Thomas Gleixner]

On Fri, 9 Oct 2009, wu Jianfeng wrote:

> > Right, but that does not cause the task to be scheduled out for ever.
> 
> I don't know why ???
> the process state is TASK_INTERRUPTIBLE, and was scheduled out.
> 
> if no one wake up it or any signals received, it will sleep for ever.
> The process does't entered any file's wait queue at that point, so I
> am sure no one will wake up it.
> 
> Am i right?

No. Did you actually read, what I wrote further down ?
 
> > 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