[dhowells-fs:rxrpc-next 2/3] net/rxrpc/conn_client.c:494:1-7: preceding lock on line 471 (fwd)

[dhowells-fs:rxrpc-next 2/3] net/rxrpc/conn_client.c:494:1-7: preceding lock on line 471 (fwd)

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 4330 bytes --]

Does the spin lock taken on line 471 need to be released in the !usable
case?

The return on line 494 also looks odd for a void function.

julia

---------- Forwarded message ----------
Date: Tue, 15 Sep 2020 09:39:41 +0800
From: kernel test robot <lkp@intel.com>
To: kbuild(a)lists.01.org
Cc: lkp(a)intel.com, Julia Lawall <julia.lawall@lip6.fr>
Subject: [dhowells-fs:rxrpc-next 2/3] net/rxrpc/conn_client.c:494:1-7: preceding
     lock on line 471

CC: kbuild-all(a)lists.01.org
TO: David Howells <dhowells@redhat.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git rxrpc-next
head:   288827d53e8edcca94caf6a507105fcbd20f419d
commit: 245500d853e9f20036cec7df4f6984ece4c6bf26 [2/3] rxrpc: Rewrite the client connection manager
:::::: branch date: 6 days ago
:::::: commit date: 6 days ago
config: i386-randconfig-c001-20200914 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@lip6.fr>


coccinelle warnings: (new ones prefixed by >>)

>> net/rxrpc/conn_client.c:494:1-7: preceding lock on line 471

# https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?id=245500d853e9f20036cec7df4f6984ece4c6bf26
git remote add dhowells-fs https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
git fetch --no-tags dhowells-fs rxrpc-next
git checkout 245500d853e9f20036cec7df4f6984ece4c6bf26
vim +494 net/rxrpc/conn_client.c

45025bceef17ed David Howells 2016-08-24  459
45025bceef17ed David Howells 2016-08-24  460  /*
245500d853e9f2 David Howells 2020-07-01  461   * Add a connection to a bundle if there are no usable connections or we have
245500d853e9f2 David Howells 2020-07-01  462   * connections waiting for extra capacity.
45025bceef17ed David Howells 2016-08-24  463   */
245500d853e9f2 David Howells 2020-07-01  464  static void rxrpc_maybe_add_conn(struct rxrpc_bundle *bundle, gfp_t gfp)
45025bceef17ed David Howells 2016-08-24  465  {
245500d853e9f2 David Howells 2020-07-01  466  	struct rxrpc_call *call;
245500d853e9f2 David Howells 2020-07-01  467  	int i, usable;
45025bceef17ed David Howells 2016-08-24  468
245500d853e9f2 David Howells 2020-07-01  469  	_enter("");
245500d853e9f2 David Howells 2020-07-01  470
245500d853e9f2 David Howells 2020-07-01 @471  	spin_lock(&bundle->channel_lock);
245500d853e9f2 David Howells 2020-07-01  472
245500d853e9f2 David Howells 2020-07-01  473  	/* See if there are any usable connections. */
245500d853e9f2 David Howells 2020-07-01  474  	usable = 0;
245500d853e9f2 David Howells 2020-07-01  475  	for (i = 0; i < ARRAY_SIZE(bundle->conns); i++)
245500d853e9f2 David Howells 2020-07-01  476  		if (rxrpc_may_reuse_conn(bundle->conns[i]))
245500d853e9f2 David Howells 2020-07-01  477  			usable++;
245500d853e9f2 David Howells 2020-07-01  478
245500d853e9f2 David Howells 2020-07-01  479  	if (!usable && !list_empty(&bundle->waiting_calls)) {
245500d853e9f2 David Howells 2020-07-01  480  		call = list_first_entry(&bundle->waiting_calls,
245500d853e9f2 David Howells 2020-07-01  481  					struct rxrpc_call, chan_wait_link);
245500d853e9f2 David Howells 2020-07-01  482  		if (test_bit(RXRPC_CALL_UPGRADE, &call->flags))
245500d853e9f2 David Howells 2020-07-01  483  			bundle->try_upgrade = true;
245500d853e9f2 David Howells 2020-07-01  484  	}
245500d853e9f2 David Howells 2020-07-01  485
245500d853e9f2 David Howells 2020-07-01  486  	if (!usable)
245500d853e9f2 David Howells 2020-07-01  487  		goto alloc_conn;
245500d853e9f2 David Howells 2020-07-01  488
245500d853e9f2 David Howells 2020-07-01  489  	spin_unlock(&bundle->channel_lock);
245500d853e9f2 David Howells 2020-07-01  490  	_leave("");
245500d853e9f2 David Howells 2020-07-01  491  	return;
245500d853e9f2 David Howells 2020-07-01  492
245500d853e9f2 David Howells 2020-07-01  493  alloc_conn:
245500d853e9f2 David Howells 2020-07-01 @494  	return rxrpc_add_conn_to_bundle(bundle, gfp);
45025bceef17ed David Howells 2016-08-24  495  }
45025bceef17ed David Howells 2016-08-24  496

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 30398 bytes --]

Re: [dhowells-fs:rxrpc-next 2/3] net/rxrpc/conn_client.c:494:1-7: preceding lock on line 471 (fwd)

[David Howells]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

Julia Lawall <julia.lawall@inria.fr> wrote:

> Does the spin lock taken on line 471 need to be released in the !usable
> case?

rxrpc_add_conn_to_bundle() releases the lock.  It's marked with __releases so
the checker shouldn't complain.  I wanted to put the manipulation of
bundle->alloc_conn together - which meant moving out that lock release.

> The return on line 494 also looks odd for a void function.

At one point they were both int, but it doesn't really matter - gcc is fine
with it.  It does have the advantage that if one of them changes return type,
this will cause a complaint if the other isn't also changed.

David