3.16.63-rc1 review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit 0a9a4304f3614e25d9de9b63502ca633c01c0d70 upstream.
If an asynchronous connection attempt completes while another task is
in xprt_connect(), then the call to rpc_sleep_on
3.18-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 0a9a4304f3614e25d9de9b63502ca633c01c0d70 ]
If an asynchronous connection attempt completes while another task is
in xprt_connect(), then the call to rpc_sleep_on() could end up
racin
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 0a9a4304f3614e25d9de9b63502ca633c01c0d70 ]
If an asynchronous connection attempt completes while another task is
in xprt_connect(), then the call to rpc_sleep_on() could end up
racin
4.14-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 0a9a4304f3614e25d9de9b63502ca633c01c0d70 ]
If an asynchronous connection attempt completes while another task is
in xprt_connect(), then the call to rpc_sleep_on() could end up
racin
4.9-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 0a9a4304f3614e25d9de9b63502ca633c01c0d70 ]
If an asynchronous connection attempt completes while another task is
in xprt_connect(), then the call to rpc_sleep_on() could end up
racing
4.4-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 0a9a4304f3614e25d9de9b63502ca633c01c0d70 ]
If an asynchronous connection attempt completes while another task is
in xprt_connect(), then the call to rpc_sleep_on() could end up
racing
From: Trond Myklebust
[ Upstream commit 0a9a4304f3614e25d9de9b63502ca633c01c0d70 ]
If an asynchronous connection attempt completes while another task is
in xprt_connect(), then the call to rpc_sleep_on() could end up
racing with the call to xprt_wake_pending_tasks().
So add a second test of the
From: Trond Myklebust
[ Upstream commit 0a9a4304f3614e25d9de9b63502ca633c01c0d70 ]
If an asynchronous connection attempt completes while another task is
in xprt_connect(), then the call to rpc_sleep_on() could end up
racing with the call to xprt_wake_pending_tasks().
So add a second test of the
From: Trond Myklebust
[ Upstream commit 0a9a4304f3614e25d9de9b63502ca633c01c0d70 ]
If an asynchronous connection attempt completes while another task is
in xprt_connect(), then the call to rpc_sleep_on() could end up
racing with the call to xprt_wake_pending_tasks().
So add a second test of the
From: Trond Myklebust
[ Upstream commit 0a9a4304f3614e25d9de9b63502ca633c01c0d70 ]
If an asynchronous connection attempt completes while another task is
in xprt_connect(), then the call to rpc_sleep_on() could end up
racing with the call to xprt_wake_pending_tasks().
So add a second test of the
From: Trond Myklebust
[ Upstream commit 0a9a4304f3614e25d9de9b63502ca633c01c0d70 ]
If an asynchronous connection attempt completes while another task is
in xprt_connect(), then the call to rpc_sleep_on() could end up
racing with the call to xprt_wake_pending_tasks().
So add a second test of the
On 12/4/2016 10:48 PM, Herbert Xu wrote:
On Fri, Dec 02, 2016 at 03:41:04PM -0800, Yang Shi wrote:
When building kernel with RSA enabled with multithreaded, the below
compile failure might be caught:
| /buildarea/kernel-source/crypto/rsa_helper.c:18:28: fatal error:
rsapubkey-asn1.h: No such f
On Fri, Dec 02, 2016 at 03:41:04PM -0800, Yang Shi wrote:
> When building kernel with RSA enabled with multithreaded, the below
> compile failure might be caught:
>
> | /buildarea/kernel-source/crypto/rsa_helper.c:18:28: fatal error:
> rsapubkey-asn1.h: No such file or directory
> | #include "rsa
When building kernel with RSA enabled with multithreaded, the below
compile failure might be caught:
| /buildarea/kernel-source/crypto/rsa_helper.c:18:28: fatal error:
rsapubkey-asn1.h: No such file or directory
| #include "rsapubkey-asn1.h"
| ^
| compilation terminated.
| CC crypto/rsa-pkcs1pad.
On Saturday 03 September 2016 08:53 PM, Jonathan Cameron wrote:
> On 02/09/16 09:05, Pavel Andrianov wrote:
>>
>
>> Hi!
> Hi Pavel,
>>
>> There is a potential race in drivers/iio/adc/vf610_adc.ko. Handlers
>> vf610_set_conversion_mode and vf610_writ
On 05/09/16 07:49, Vaishali Thakkar wrote:
>
>
> On Saturday 03 September 2016 08:53 PM, Jonathan Cameron wrote:
>> On 02/09/16 09:05, Pavel Andrianov wrote:
>>>
>>
>>> Hi!
>> Hi Pavel,
>>>
>>> There is a potential race in drivers/i
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
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
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 pointe
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
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
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
On Saturday 03 September 2016 08:53 PM, Jonathan Cameron wrote:
> On 02/09/16 09:05, Pavel Andrianov wrote:
>>
>
>> Hi!
> Hi Pavel,
>>
>> There is a potential race in drivers/iio/adc/vf610_adc.ko. Handlers
>> vf610_set_conversion_mode and vf610_writ
On 02/09/16 09:05, Pavel Andrianov wrote:
>
> Hi!
Hi Pavel,
>
> There is a potential race in drivers/iio/adc/vf610_adc.ko. Handlers
> vf610_set_conversion_mode and vf610_write_raw are called via
> device_attibute interface, but they are related to different
> attributes,
On Fri, Sep 02, 2016 at 11:05:09AM +0300, Pavel Andrianov wrote:
>
> Hi!
>
> There is a potential race in drivers/iio/adc/vf610_adc.ko.
> Handlers vf610_set_conversion_mode and vf610_write_raw are called via
> device_attibute interface, but they are related to different attri
Hi!
There is a potential race in drivers/iio/adc/vf610_adc.ko.
Handlers vf610_set_conversion_mode and vf610_write_raw are called via
device_attibute interface, but they are related to different attributes,
so may be executed in parallel. vf610_set_conversion_mode acquires the
mutex indio_dev
Hi!
There is a potential data race in drivers/scsi/megaraid.ko
Regards such case:
Thread 1Thread 2
... ...
-> megaraid_probe_one
-> request_irq- now an interrupt may arise
Hi!
There is a potential race in drivers/atm/eni.ko.
In the interrupt handler eni_int the field eni_dev->events is masked
(line 1519) with a spinlock protection. In eni_start eni_dev->events is
initialized (line 1844), but it is done after interrupts are requested
(line 1813). Thu
, Pavel Andrianov wrote:
Hi!
There is a potential race condition between usbvision_v4l2_close and
usbvision_disconnect. The possible scenario may be the following.
usbvision_disconnect starts execution, assigns usbvision->remove_pending = 1,
and is interrupted
(rescheduled) after mutex_unl
On 07/01/2016 05:02 PM, Pavel Andrianov wrote:
> 01.07.2016 19:53, Hans Verkuil пишет:
>> On 07/01/2016 04:39 PM, Pavel Andrianov wrote:
>>> Hi!
>>>
>>> There is a potential race condition between usbvision_v4l2_close and
>>> usbvision_disconnec
01.07.2016 19:53, Hans Verkuil пишет:
On 07/01/2016 04:39 PM, Pavel Andrianov wrote:
Hi!
There is a potential race condition between usbvision_v4l2_close and
usbvision_disconnect. The possible scenario may be the following.
usbvision_disconnect starts execution, assigns usbvision
On 07/01/2016 04:39 PM, Pavel Andrianov wrote:
> Hi!
>
> There is a potential race condition between usbvision_v4l2_close
> <http://lxr.free-electrons.com/source/drivers/media/usb/usbvision/usbvision-video.c#L403>
> and usbvision_disconnect
> <http://lxr.free-electro
On 06/24/2016 09:17 AM, Vaishali Thakkar wrote:
On Friday 10 June 2016 01:51 PM, Pavel Andrianov wrote:
Hi!
There is a potential data race in
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/rtl8188ee.ko.
In the function rtl88ee_gpio_radio_on_off_checking the flag
ppsc->rfchange_inprogress i
On Friday 10 June 2016 01:51 PM, Pavel Andrianov wrote:
> Hi!
>
> There is a potential data race in
> drivers/net/wireless/realtek/rtlwifi/rtl8188ee/rtl8188ee.ko.
>
> In the function rtl88ee_gpio_radio_on_off_checking the flag
> ppsc->rfchange_inprogress is set with a spinlock protection. In
Hi!
There is a potential data race in
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/rtl8188ee.ko.
In the function rtl88ee_gpio_radio_on_off_checking the flag
ppsc->rfchange_inprogress is set with a spinlock protection. In the
function rtl_ps_set_rf_state the flag is read also under a spinlo
On Thu, 15 Mar 2007 15:10:23 +0100 Michal Januszewski <[EMAIL PROTECTED]> wrote:
> On a multiprocessor machine the VT_WAITACTIVE ioctl call may return 0
> if fg_console has already been updated in redraw_screen(), but the
> console switch itself hasn't been completed. Fix this by checking
> fg_co
On a multiprocessor machine the VT_WAITACTIVE ioctl call may return 0
if fg_console has already been updated in redraw_screen(), but the
console switch itself hasn't been completed. Fix this by checking
fg_console in vt_waitactive() with the console sem held.
Signed-off-by: Michal Januszewski <[E
37 matches
Mail list logo
