netdev - Clarification required about select vs wake

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>] [day] [month] [year] [list]

Date:	Mon, 12 Mar 2007 19:38:10 -0700
From:	"Ravinandan Arakali \(rarakali\)" <rarakali@...co.com>
To:	<netdev@...r.kernel.org>
Subject: Clarification required about select vs wake_up race condition

Hi,
I am facing following problem and was wondering if somebody could help
me out.
I reference our char driver below but the question I really have is
about sleep/wake_up mechanism. So, I thought somebody who is aware of
this can help me. BTW, this is 2.6.10.

Our char driver(pretty much like all other char drivers) does a
poll_wait() 
and returns status depending on whether data is available to be read.
Even though some data is available to be read(verified using one of our
internal 
commands), the select() never wakes up, inspite of any no. of messages
sent.

To understand this, I was looking at the code of select vs
wake_up_interruptible().
I feel I am misunderstanding some part of the kernel code but will be
glad if 
somebody can point it out.

My understanding:
The do_select() sets the state of task to TASK_INTERRUPTIBLE and calls
the driver's poll 
entry point. In our poll(), let's say immediately after we determine
that there's nothing 
to be read, some data arrives causing a wake_up_interruptible() on
another CPU. 
The wake up happens in the context of process sending the data. Since
the receiving process 
was already added to the list of listeners, from looking at the code of
try_to_wake_up(), it 
looks like it can set the state of the receiving process to
TASK_RUNNING(I don't see any lock 
preventing this). After this happens, the receiving process goes to
sleep (because of 
schedule_timeout called by do_select) but state is still set to
TASK_RUNNING. In this state, when another message arrives, the
wake_up_interruptible will not wake the process because of following 
code in try_to_wake_up() ?

old_state = p->state;
if (!(old_state & state))
   goto out;

The above situation seems simplistic so I'm wondering what I am missing
here ?

Thanks,
Ravi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html