Hello Anton, Thanks for reviewing the code.
This would be right, if the c4 could rise an interrupt at this moment ... After a reset with c4_reset(), the card will not generate an interrupt, until firmware has been loaded and the SEND_INIT message has been sent. c4_load_firmware() -> c4_send_init() sets the card number in the card. Therefor it's not an issue. best regards, calle Tue, Aug 15, 2017 at 04:22:16PM +0300, Anton Volkov schrieb: > Hello. > > While searching for races in the Linux kernel I've come across > "drivers/isdn/hardware/avm/c4.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: > c4_probe > ->c4_add_card > request_irq() > c4_interrupt > ->c4_handle_interrupt > ->c4_handle_rx > card->cardnr = ... cidx = f(card->cardnr) > (c4.c: line 1227) (c4.c: line 526) > if (cidx >= card->nlogcontr) cidx = 0; > ctrl = &card->ctrlinfo[cidx].capi_ctrl > > card->cardnr is 0 until it is initialized in c4_add_card(). If at the moment > of read access in c4_handle_rx() it is still 0, cidx may then be assigned an > undesirable value and wrong controller may handle messages. Is this case > feasible from your point of view? > > Thank you for your time. > > -- Anton Volkov > Linux Verification Center, ISPRAS > web: http://linuxtesting.org > e-mail: avol...@ispras.ru
