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
| ||
|
Date: Thu, 01 Mar 2007 15:32:12 +0200 From: Eli Cohen <eli@...lanox.co.il> To: Linux Kernel <linux-kernel@...r.kernel.org> Cc: rdreier@...co.com, "Michael S. Tsirkin" <mst@...lanox.co.il> Subject: wait_for_completion_timeout problem ??? Hi, I have a problem with using this function. I am referring to drivers/infiniband/hw/mthca/mthca_cmd.c line 394. For convenience I quote from this code: init_completion(&context->done); err = mthca_cmd_post(dev, in_param, out_param ? *out_param : 0, in_modifier, op_modifier, op, context->token, 1); if (err) goto out; if (!wait_for_completion_timeout(&context->done, timeout)) { err = -EBUSY; goto out; } timeout is 10 * HZ. Sometimes this function returns 0 which signifies timeout. However I can see that the interrupt handler called complete(&context->done) around 200 usec after calling wait_for_completion_timout(). When the function returns I can see that context->done.done equals 1 which confirms that complete was indeed called. Looking at the implementation of wait_for_completion_timout() it appears that complete() did not succeed to wake the process sleeping. But the timer callback function in schedule_timeout() did manage to wake up the sleeping process. Do you have any idea if there are any known circumstances that can lead to this behaviour. Any idea how to debug this? Thanks Eli - 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