On 08/18/2017 05:10 PM, Anton Volkov wrote: > Hello. > > While searching for races in the Linux kernel I've come across > "drivers/iio/adc/xilinx-xadc.ko" module. Here is a question that I came up > with while analyzing results. Lines are given using the info from Linux v4.12. > > Consider the following case: > > Thread 1: Thread 2: > xadc_probe > iio_triggered_buffer_setup > xadc_trigger_handler > ->xadc_read_adc_reg > ->_xadc_read_adc_reg > ->xadc_zynq_read_adc_reg > ->xadc_zynq_setup ->xadc_zynq_update_intmsk > xadc->zynq_intmask = ~0 xadc->zynq_intmask &= ~mask > (xilinx-xadc-core.c: line 340) (xilinx-xadc-core.c: line 152) > xadc_write_reg(xadc->zynq_intmask) xadc_write_reg(xadc->zynq_intmask) > > Judging by the comments to iio_triggered_buffer_setup() the best practice is > to call it after the indio_dev structure had been fully initialized. In the > suggested case xadc_trigger_handler() interferes in the initialization > process. Both xadc_zynq_setup() and xadc_zynq_update_intmsk() will write the > same xadc->zynq_intmask though it should probably be different. Is this race > feasible from your point of view? Hi, Thanks for the report. I don't think there is an issue here. All iio_triggered_buffer_setup() does is store the pointer to the callback function in the iio_poll_func structure of the device. The callback is not live until iio_trigger_attach_poll_func() has been invoked, which can only happen after iio_device_register() has completed. - 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