On Wed, 2016-05-18 at 15:48 -0500, Mike Christie wrote:
> Reviewed and tested. Thanks
>
> Acked-by: Mike Christie
Excellent, thanks Mike !
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->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() vari
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->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() vari
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.
M
iscsi_sw_tcp_data_ready() and iscsi_sw_tcp_state_change() were
using read_lock(&sk->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
