On 12/14/2012 03:29 PM, Alexander Holler wrote: > Am 14.12.2012 15:15, schrieb Alexander Holler: >> Am 14.12.2012 14:08, schrieb Alexander Holler: >>> Am 14.12.2012 10:42, schrieb Lars-Peter Clausen: >> >>>> And another thing I've overlooked before: >>>> wait_for_completion_interruptible_timeout can either return a positive >>>> number when the completion was completed, 0 in case of an timeout, or a >>>> negative error code in case it was interrupted. You need to handle all >>>> three. E.g. something like this. >>>> >>>> ret = wait_for_completion_interruptible_timeout(...) >>>> if (ret == 0) >>>> return -EIO; >>>> if (ret < 0) >>>> return ret >>>> >>> >>> Hmpf, the only working approach to use some in kernel functions really >>> is to the read source yourself and don't trust anything else. :/ >> >> Anyway, my approach doesn't work as it introduces a race condition: >> >> >> /* get a report with all values through requesting one value */ >> sensor_hub_input_attr_get_raw_value(...) >> >> /* race if this task goes to slepp and the values were >> received before it could call the below wait... >> >> /* wait for all values (event) */ >> if (!wait_for_completion_interruptible_timeout(...)) >> >> >> I'll have to look for a mechanism how to avoid that. So v5 might need >> some time. > > Sorry for the noise. That INIT_COMPLETION() before the sensor...() does > exactly that. So it's enough if I handle the different return situations of > wait_for...(). > > I will just use if(wait...()<=0) return -EIO. > No, that's wrong. You should really return the error code returned by wait_for_completion_interruptible_timeout(). This will make sure that userspace restarts the syscall if necessary. - Lars -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
