Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1649522 > unrolled thread

Re: [lkp-robot] [NFS] 14d1bbb0ca: BUG:scheduling_while_atomic

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [lkp-robot] [NFS]  14d1bbb0ca: BUG:scheduling_while_atomic Trond Myklebust <trondmy@primarydata.com> - 2017-05-24 13:50 +0200

#1649522 — Re: [lkp-robot] [NFS] 14d1bbb0ca: BUG:scheduling_while_atomic

On Wed, 2017-05-24 at 10:36 +0800, kernel test robot wrote:
> FYI, we noticed the following commit:
> 
> commit: 14d1bbb0ca425c4fdd9a38eaac346c028661b752 ("NFS: Create a
> common nfs4_match_client() function")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
> master
> 
> in testcase: boot
> 
> on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 2 -m
> 4G
> 
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
> 
> 
> +-------------------------------+------------+------------+
> >                               | 5b6d3ff605 | 14d1bbb0ca |
> 
> +-------------------------------+------------+------------+
> > boot_successes                | 469        | 470        |
> > boot_failures                 | 0          | 31         |
> > BUG:scheduling_while_atomic   | 0          | 31         |
> > BUG:spinlock_recursion_on_CPU | 0          | 30         |
> 
> +-------------------------------+------------+------------+
> 
> 
> 
> [  299.158991] BUG: scheduling while atomic:
> mount.nfs/9387/0x00000002
> [  299.169587] 2 locks held by mount.nfs/9387:
> [  299.176165]  #0:  (nfs_clid_init_mutex){......}, at:
> [<ffffffff8130cc92>] nfs4_discover_server_trunking+0x47/0x1fc
> [  299.201802]  #1:  (&(&nn->nfs_client_lock)->rlock){......}, at:
> [<ffffffff813125fa>] nfs40_walk_client_list+0x2e9/0x338
> 

Oops. Anna, it looks as if that patch adds an incorrect call to
"spin_lock(&nn->nfs_client_lock)" for the "default:" case when
processing the result from the SETCLIENTID_CONFIRM call. I can send a
fix.

Thanks Xiaolong!

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@primarydata.com

[toc] | [standalone]

Back to top | Article view | linux.kernel

csiph-web