From: Mike Christie <michaelc@cs.wisc.edu>
To: Eric Dumazet <edumazet@google.com>,
"David S . Miller" <davem@davemloft.net>
Cc: netdev <netdev@vger.kernel.org>,
Venkatesh Srinivas <venkateshs@google.com>,
Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [PATCH net-next 1/4] scsi_tcp: block BH in TCP callbacks
Date: Wed, 18 May 2016 12:21:03 -0500 [thread overview]
Message-ID: <573CA47F.10304@cs.wisc.edu> (raw)
In-Reply-To: <1463532249-20850-2-git-send-email-edumazet@google.com>
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() variant to restore previous assumption.
>
> Ideally this code could use RCU instead...
>
> Fixes: 5413d1babe8f ("net: do not block BH while processing socket backlog")
> Fixes: d41a69f1d390 ("tcp: make tcp_sendmsg() aware of socket backlog")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Mike Christie <michaelc@cs.wisc.edu>
> Cc: Venkatesh Srinivas <venkateshs@google.com>
> ---
> drivers/scsi/iscsi_tcp.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
> index 2e4c82f8329c..ace4f1f41b8e 100644
> --- a/drivers/scsi/iscsi_tcp.c
> +++ b/drivers/scsi/iscsi_tcp.c
> @@ -131,10 +131,10 @@ static void iscsi_sw_tcp_data_ready(struct sock *sk)
> struct iscsi_tcp_conn *tcp_conn;
> read_descriptor_t rd_desc;
>
> - read_lock(&sk->sk_callback_lock);
> + read_lock_bh(&sk->sk_callback_lock);
> conn = sk->sk_user_data;
> if (!conn) {
> - read_unlock(&sk->sk_callback_lock);
> + read_unlock_bh(&sk->sk_callback_lock);
> return;
> }
> tcp_conn = conn->dd_data;
> @@ -154,7 +154,7 @@ static void iscsi_sw_tcp_data_ready(struct sock *sk)
> /* If we had to (atomically) map a highmem page,
> * unmap it now. */
> iscsi_tcp_segment_unmap(&tcp_conn->in.segment);
> - read_unlock(&sk->sk_callback_lock);
> + read_unlock_bh(&sk->sk_callback_lock);
> }
>
> static void iscsi_sw_tcp_state_change(struct sock *sk)
> @@ -165,10 +165,10 @@ static void iscsi_sw_tcp_state_change(struct sock *sk)
> struct iscsi_session *session;
> void (*old_state_change)(struct sock *);
>
> - read_lock(&sk->sk_callback_lock);
> + read_lock_bh(&sk->sk_callback_lock);
> conn = sk->sk_user_data;
> if (!conn) {
> - read_unlock(&sk->sk_callback_lock);
> + read_unlock_bh(&sk->sk_callback_lock);
> return;
> }
> session = conn->session;
> @@ -179,7 +179,7 @@ static void iscsi_sw_tcp_state_change(struct sock *sk)
> tcp_sw_conn = tcp_conn->dd_data;
> old_state_change = tcp_sw_conn->old_state_change;
>
> - read_unlock(&sk->sk_callback_lock);
> + read_unlock_bh(&sk->sk_callback_lock);
>
> old_state_change(sk);
> }
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.
I found this thread
https://lkml.org/lkml/2011/1/25/232
which says it is ok.
next prev parent reply other threads:[~2016-05-18 18:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-18 0:44 [PATCH net-next 0/4] net: block BH in TCP callbacks Eric Dumazet
2016-05-18 0:44 ` [PATCH net-next 1/4] scsi_tcp: " Eric Dumazet
2016-05-18 17:21 ` Mike Christie [this message]
2016-05-18 17:29 ` Eric Dumazet
2016-05-18 20:48 ` Mike Christie
2016-05-18 21:48 ` Eric Dumazet
2016-05-18 0:44 ` [PATCH net-next 2/4] ocfs2/cluster: " Eric Dumazet
2016-05-18 0:44 ` [PATCH net-next 3/4] rds: tcp: " Eric Dumazet
2016-05-18 0:44 ` [PATCH net-next 4/4] tipc: " Eric Dumazet
2016-05-19 18:37 ` [PATCH net-next 0/4] net: " David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=573CA47F.10304@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=venkateshs@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.