xprt_alloc_bc_request() cannot call xprt_free_bc_request() without
deadlocking, since it already holds the xprt->bc_pa_lock.
Reported-by: Chuck Lever <[email protected]>
Fixes: 0d2a970d0ae55 ("SUNRPC: Fix a backchannel race")
Signed-off-by: Trond Myklebust <[email protected]>
---
net/sunrpc/backchannel_rqst.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/backchannel_rqst.c b/net/sunrpc/backchannel_rqst.c
index 9825ff0f91d6..5a3b50aec397 100644
--- a/net/sunrpc/backchannel_rqst.c
+++ b/net/sunrpc/backchannel_rqst.c
@@ -240,8 +240,8 @@ static struct rpc_rqst *xprt_alloc_bc_request(struct rpc_xprt *xprt, __be32 xid)
req = xprt_alloc_bc_req(xprt, GFP_ATOMIC);
if (!req)
goto not_found;
- /* Note: this 'free' request adds it to xprt->bc_pa_list */
- xprt_free_bc_request(req);
+ list_add_tail(&req->rq_bc_pa_list, &xprt->bc_pa_list);
+ xprt->bc_alloc_count++;
}
req = list_first_entry(&xprt->bc_pa_list, struct rpc_rqst,
rq_bc_pa_list);
--
2.4.3
Hi Trond-
On Jul 22, 2015, at 4:36 PM, Trond Myklebust <[email protected]> wrote:
> xprt_alloc_bc_request() cannot call xprt_free_bc_request() without
> deadlocking, since it already holds the xprt->bc_pa_lock.
>
> Reported-by: Chuck Lever <[email protected]>
> Fixes: 0d2a970d0ae55 ("SUNRPC: Fix a backchannel race")
> Signed-off-by: Trond Myklebust <[email protected]>
That?s exactly what I did as a basic fix, and I can report that
it successfully avoids the deadlock.
If xprt_alloc_bc_request() no longer calls xprt_free_bc_request(),
are the accounting changes introduced by 0d2a970d0ae55 still
necessary?
> ---
> net/sunrpc/backchannel_rqst.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/sunrpc/backchannel_rqst.c b/net/sunrpc/backchannel_rqst.c
> index 9825ff0f91d6..5a3b50aec397 100644
> --- a/net/sunrpc/backchannel_rqst.c
> +++ b/net/sunrpc/backchannel_rqst.c
> @@ -240,8 +240,8 @@ static struct rpc_rqst *xprt_alloc_bc_request(struct rpc_xprt *xprt, __be32 xid)
> req = xprt_alloc_bc_req(xprt, GFP_ATOMIC);
> if (!req)
> goto not_found;
> - /* Note: this 'free' request adds it to xprt->bc_pa_list */
> - xprt_free_bc_request(req);
> + list_add_tail(&req->rq_bc_pa_list, &xprt->bc_pa_list);
> + xprt->bc_alloc_count++;
> }
> req = list_first_entry(&xprt->bc_pa_list, struct rpc_rqst,
> rq_bc_pa_list);
> --
> 2.4.3
>
--
Chuck Lever
On Wed, Jul 22, 2015 at 4:40 PM, Chuck Lever <[email protected]> wrote:
> Hi Trond-
>
>
> On Jul 22, 2015, at 4:36 PM, Trond Myklebust <[email protected]> wrote:
>
>> xprt_alloc_bc_request() cannot call xprt_free_bc_request() without
>> deadlocking, since it already holds the xprt->bc_pa_lock.
>>
>> Reported-by: Chuck Lever <[email protected]>
>> Fixes: 0d2a970d0ae55 ("SUNRPC: Fix a backchannel race")
>> Signed-off-by: Trond Myklebust <[email protected]>
>
> That’s exactly what I did as a basic fix, and I can report that
> it successfully avoids the deadlock.
>
> If xprt_alloc_bc_request() no longer calls xprt_free_bc_request(),
> are the accounting changes introduced by 0d2a970d0ae55 still
> necessary?
The accounting changes are there to fix the race that Christoph
reported in which a valid backchannel request can be rejected by the
RPC layer if it happens to come in after the reply to the previous
request was sent, but before xprt_free_bc_request has completed. I
would therefore expect them still to be needed.
That said, I just noticed that the bc_free_count was being incorrectly
maintained. Should be fixed with v2 of the patch series.
Cheers
Trond
On Jul 22, 2015, at 5:14 PM, Trond Myklebust <[email protected]> wrote:
> On Wed, Jul 22, 2015 at 4:40 PM, Chuck Lever <[email protected]> wrote:
>> Hi Trond-
>>
>>
>> On Jul 22, 2015, at 4:36 PM, Trond Myklebust <[email protected]> wrote:
>>
>>> xprt_alloc_bc_request() cannot call xprt_free_bc_request() without
>>> deadlocking, since it already holds the xprt->bc_pa_lock.
>>>
>>> Reported-by: Chuck Lever <[email protected]>
>>> Fixes: 0d2a970d0ae55 ("SUNRPC: Fix a backchannel race")
>>> Signed-off-by: Trond Myklebust <[email protected]>
>>
>> That?s exactly what I did as a basic fix, and I can report that
>> it successfully avoids the deadlock.
>>
>> If xprt_alloc_bc_request() no longer calls xprt_free_bc_request(),
>> are the accounting changes introduced by 0d2a970d0ae55 still
>> necessary?
>
> The accounting changes are there to fix the race that Christoph
> reported in which a valid backchannel request can be rejected by the
> RPC layer if it happens to come in after the reply to the previous
> request was sent, but before xprt_free_bc_request has completed. I
> would therefore expect them still to be needed.
>
> That said, I just noticed that the bc_free_count was being incorrectly
> maintained. Should be fixed with v2 of the patch series.
I will get v2 in front of the tester who found this issue.
--
Chuck Lever
On Jul 22, 2015, at 5:15 PM, Chuck Lever <[email protected]> wrote:
>
> On Jul 22, 2015, at 5:14 PM, Trond Myklebust <[email protected]> wrote:
>
>> On Wed, Jul 22, 2015 at 4:40 PM, Chuck Lever <[email protected]> wrote:
>>> Hi Trond-
>>>
>>>
>>> On Jul 22, 2015, at 4:36 PM, Trond Myklebust <[email protected]> wrote:
>>>
>>>> xprt_alloc_bc_request() cannot call xprt_free_bc_request() without
>>>> deadlocking, since it already holds the xprt->bc_pa_lock.
>>>>
>>>> Reported-by: Chuck Lever <[email protected]>
>>>> Fixes: 0d2a970d0ae55 ("SUNRPC: Fix a backchannel race")
>>>> Signed-off-by: Trond Myklebust <[email protected]>
>>>
>>> That?s exactly what I did as a basic fix, and I can report that
>>> it successfully avoids the deadlock.
>>>
>>> If xprt_alloc_bc_request() no longer calls xprt_free_bc_request(),
>>> are the accounting changes introduced by 0d2a970d0ae55 still
>>> necessary?
>>
>> The accounting changes are there to fix the race that Christoph
>> reported in which a valid backchannel request can be rejected by the
>> RPC layer if it happens to come in after the reply to the previous
>> request was sent, but before xprt_free_bc_request has completed. I
>> would therefore expect them still to be needed.
>>
>> That said, I just noticed that the bc_free_count was being incorrectly
>> maintained. Should be fixed with v2 of the patch series.
>
> I will get v2 in front of the tester who found this issue.
The v2 fix appears solid. Thanks!
--
Chuck Lever