Re: [PATCH net-next 1/4] scsi_tcp: block BH in TCP callbacks

2016-05-18 Thread Eric Dumazet
On Wed, 2016-05-18 at 15:48 -0500, Mike Christie wrote: > Reviewed and tested. Thanks > > Acked-by: Mike Christie Excellent, thanks Mike !

Re: [PATCH net-next 1/4] scsi_tcp: block BH in TCP callbacks

2016-05-18 Thread Mike Christie
On 05/17/2016 07:44 PM, Eric Dumazet wrote: > iscsi_sw_tcp_data_ready() and iscsi_sw_tcp_state_change() were > using read_lock(>sk_callback_lock) which is fine if caller > disabled BH. > > TCP stack no longer has this requirement and can run from > process context. > > Use read_lock_bh() variant

Re: [PATCH net-next 1/4] scsi_tcp: block BH in TCP callbacks

2016-05-18 Thread Mike Christie
On 05/17/2016 07:44 PM, Eric Dumazet wrote: > iscsi_sw_tcp_data_ready() and iscsi_sw_tcp_state_change() were > using read_lock(>sk_callback_lock) which is fine if caller > disabled BH. > > TCP stack no longer has this requirement and can run from > process context. > > Use read_lock_bh() variant

Re: [PATCH net-next 1/4] scsi_tcp: block BH in TCP callbacks

2016-05-18 Thread Eric Dumazet
On Wed, 2016-05-18 at 12:21 -0500, Mike Christie wrote: > Can I just confirm that nested bh lock calls like: > > spin_lock_bh(lock1); > spin_lock_bh(lock2); > > do something > > spin_unlock_bh(lock2); > spin_unlock_bh(lock1); > > is ok? It seems smatch sometimes warns about this. It is ok.

[PATCH net-next 1/4] scsi_tcp: block BH in TCP callbacks

2016-05-17 Thread Eric Dumazet
iscsi_sw_tcp_data_ready() and iscsi_sw_tcp_state_change() were using read_lock(>sk_callback_lock) which is fine if caller disabled BH. TCP stack no longer has this requirement and can run from process context. Use read_lock_bh() variant to restore previous assumption. Ideally this code could