Re: A potential race in drivers/staging/speakup/speakup.ko
Pavel Andrianov, on Mon 05 Sep 2016 13:33:33 +0300, wrote: > synth_direct_store may be called via device_attributes interface. Ah, right. > In which function the lock should be added? That'd be synth_direct_store then, around the while loop. Samuel
Re: A potential race in drivers/staging/speakup/speakup.ko
Pavel Andrianov, on Mon 05 Sep 2016 13:33:33 +0300, wrote: > synth_direct_store may be called via device_attributes interface. Ah, right. > In which function the lock should be added? That'd be synth_direct_store then, around the while loop. Samuel
Re: A potential race in drivers/staging/speakup/speakup.ko
05.09.2016 12:56, Samuel Thibault пишет: Pavel Andrianov, on Mon 05 Sep 2016 12:54:10 +0300, wrote: 05.09.2016 12:43, Samuel Thibault пишет: Pavel Andrianov, on Mon 05 Sep 2016 11:51:50 +0300, wrote: There is a potential race in drivers/staging/speakup/speakup.ko. All operations with global pointers buff_in and buff_out are performed without any locks. Thus, a simultaneous write (via synth_buffer_clear or synth_buffer_add) to the pointers may lead to inconsistent data. Should a local lock be used here? AIUI, all callers of these functions have speakup_info.spinlock held. Regard a call stack -> synth_direct_store -> synth_printf -> synth_buffer_add The functions have not held speakup_info.spinlock. Apparently there is currently no caller of synth_direct_store and synth_store. But taking the lock here would be needed indeed. Samuel synth_direct_store may be called via device_attributes interface. In which function the lock should be added? -- Pavel Andrianov Linux Verification Center, ISPRAS web: http://linuxtesting.org e-mail: andria...@ispras.ru
Re: A potential race in drivers/staging/speakup/speakup.ko
05.09.2016 12:56, Samuel Thibault пишет: Pavel Andrianov, on Mon 05 Sep 2016 12:54:10 +0300, wrote: 05.09.2016 12:43, Samuel Thibault пишет: Pavel Andrianov, on Mon 05 Sep 2016 11:51:50 +0300, wrote: There is a potential race in drivers/staging/speakup/speakup.ko. All operations with global pointers buff_in and buff_out are performed without any locks. Thus, a simultaneous write (via synth_buffer_clear or synth_buffer_add) to the pointers may lead to inconsistent data. Should a local lock be used here? AIUI, all callers of these functions have speakup_info.spinlock held. Regard a call stack -> synth_direct_store -> synth_printf -> synth_buffer_add The functions have not held speakup_info.spinlock. Apparently there is currently no caller of synth_direct_store and synth_store. But taking the lock here would be needed indeed. Samuel synth_direct_store may be called via device_attributes interface. In which function the lock should be added? -- Pavel Andrianov Linux Verification Center, ISPRAS web: http://linuxtesting.org e-mail: andria...@ispras.ru
Re: A potential race in drivers/staging/speakup/speakup.ko
Pavel Andrianov, on Mon 05 Sep 2016 12:54:10 +0300, wrote: > 05.09.2016 12:43, Samuel Thibault пишет: > >Pavel Andrianov, on Mon 05 Sep 2016 11:51:50 +0300, wrote: > >>There is a potential race in drivers/staging/speakup/speakup.ko. > >>All operations with global pointers buff_in and buff_out are performed > >>without any locks. Thus, a simultaneous write (via synth_buffer_clear or > >>synth_buffer_add) to the pointers may lead to inconsistent data. > >> > >>Should a local lock be used here? > > > >AIUI, all callers of these functions have speakup_info.spinlock held. > > Regard a call stack > > -> synth_direct_store > -> synth_printf > -> synth_buffer_add > > The functions have not held speakup_info.spinlock. Apparently there is currently no caller of synth_direct_store and synth_store. But taking the lock here would be needed indeed. Samuel
Re: A potential race in drivers/staging/speakup/speakup.ko
Pavel Andrianov, on Mon 05 Sep 2016 12:54:10 +0300, wrote: > 05.09.2016 12:43, Samuel Thibault пишет: > >Pavel Andrianov, on Mon 05 Sep 2016 11:51:50 +0300, wrote: > >>There is a potential race in drivers/staging/speakup/speakup.ko. > >>All operations with global pointers buff_in and buff_out are performed > >>without any locks. Thus, a simultaneous write (via synth_buffer_clear or > >>synth_buffer_add) to the pointers may lead to inconsistent data. > >> > >>Should a local lock be used here? > > > >AIUI, all callers of these functions have speakup_info.spinlock held. > > Regard a call stack > > -> synth_direct_store > -> synth_printf > -> synth_buffer_add > > The functions have not held speakup_info.spinlock. Apparently there is currently no caller of synth_direct_store and synth_store. But taking the lock here would be needed indeed. Samuel
Re: A potential race in drivers/staging/speakup/speakup.ko
05.09.2016 12:43, Samuel Thibault пишет: Hello, Pavel Andrianov, on Mon 05 Sep 2016 11:51:50 +0300, wrote: There is a potential race in drivers/staging/speakup/speakup.ko. All operations with global pointers buff_in and buff_out are performed without any locks. Thus, a simultaneous write (via synth_buffer_clear or synth_buffer_add) to the pointers may lead to inconsistent data. Should a local lock be used here? AIUI, all callers of these functions have speakup_info.spinlock held. Samuel Regard a call stack -> synth_direct_store -> synth_printf -> synth_buffer_add The functions have not held speakup_info.spinlock. -- Pavel Andrianov Linux Verification Center, ISPRAS web: http://linuxtesting.org e-mail: andria...@ispras.ru
Re: A potential race in drivers/staging/speakup/speakup.ko
05.09.2016 12:43, Samuel Thibault пишет: Hello, Pavel Andrianov, on Mon 05 Sep 2016 11:51:50 +0300, wrote: There is a potential race in drivers/staging/speakup/speakup.ko. All operations with global pointers buff_in and buff_out are performed without any locks. Thus, a simultaneous write (via synth_buffer_clear or synth_buffer_add) to the pointers may lead to inconsistent data. Should a local lock be used here? AIUI, all callers of these functions have speakup_info.spinlock held. Samuel Regard a call stack -> synth_direct_store -> synth_printf -> synth_buffer_add The functions have not held speakup_info.spinlock. -- Pavel Andrianov Linux Verification Center, ISPRAS web: http://linuxtesting.org e-mail: andria...@ispras.ru
Re: A potential race in drivers/staging/speakup/speakup.ko
Hello, Pavel Andrianov, on Mon 05 Sep 2016 11:51:50 +0300, wrote: > There is a potential race in drivers/staging/speakup/speakup.ko. > All operations with global pointers buff_in and buff_out are performed > without any locks. Thus, a simultaneous write (via synth_buffer_clear or > synth_buffer_add) to the pointers may lead to inconsistent data. > > Should a local lock be used here? AIUI, all callers of these functions have speakup_info.spinlock held. Samuel
Re: A potential race in drivers/staging/speakup/speakup.ko
Hello, Pavel Andrianov, on Mon 05 Sep 2016 11:51:50 +0300, wrote: > There is a potential race in drivers/staging/speakup/speakup.ko. > All operations with global pointers buff_in and buff_out are performed > without any locks. Thus, a simultaneous write (via synth_buffer_clear or > synth_buffer_add) to the pointers may lead to inconsistent data. > > Should a local lock be used here? AIUI, all callers of these functions have speakup_info.spinlock held. Samuel
A potential race in drivers/staging/speakup/speakup.ko
Hi! There is a potential race in drivers/staging/speakup/speakup.ko. All operations with global pointers buff_in and buff_out are performed without any locks. Thus, a simultaneous write (via synth_buffer_clear or synth_buffer_add) to the pointers may lead to inconsistent data. Should a local lock be used here? -- Pavel Andrianov Linux Verification Center, ISPRAS web: http://linuxtesting.org e-mail: andria...@ispras.ru
A potential race in drivers/staging/speakup/speakup.ko
Hi! There is a potential race in drivers/staging/speakup/speakup.ko. All operations with global pointers buff_in and buff_out are performed without any locks. Thus, a simultaneous write (via synth_buffer_clear or synth_buffer_add) to the pointers may lead to inconsistent data. Should a local lock be used here? -- Pavel Andrianov Linux Verification Center, ISPRAS web: http://linuxtesting.org e-mail: andria...@ispras.ru
