about NFS sub system between Public Kernel and Red Hat Kernel.
Subsystems (2)
I have 1 question, and also 2 conclusions which need confirm.
1) Question:
Jeff Layton said in Red Hat Bugzilla (bug 848706):
"Have configuration where the same host is acting as both NFS client and server. That's a configuration known to cause deadlocks."
Does it mean that the public Linux kernel (not Red Hat) also can cause deadlocks if NFS client and server are under the same machine ?
2) Confirm 1: (better by Jeff Layton)
For function nfs_commit_set_lock in ./fs/nfs/write.c
for latest public kernel version:
the parameters of out_of_line_wait_on_bit_lock() are (&nfsi->flags, NFS_INO_COMMIT, nfs_wait_killable, TASK_KILLABLE) for Red Hat kernel version: kernel-2.6.18-308.4.1.el5 the parameters of out_of_line_wait_on_bit_lock() are (&nfsi->flags, NFS_INO_COMMIT, nfs_wait_bit_uninterruptible, TASK_UNINTERRUPTIBLE)
It means for red hat version:
when deadlock occurs, we can not boot machine in normal way (it is true for my test machine, the deadlock task can not be killed) It means for public kernel version:
"Assume deadlock occurs", we can still boot machine in normal way, because the task can be killed.
Is what I said above correct ?
3) Confirm 2:
Is LTP (Linux Test Project) still a suitable test tools for public kernel ? (for ltp-full-20100331.gz stress test, it mounts NFS on local machine, and the latest LTP ltp-full-20120401.bz2 also seems the same).
thanks.
gchen
Asianux Corporation
Quoted 5 lines · On Fri, 31 Aug 2012 13:40:16 +0800 gchen <[email protected]> wrote:
I have 1 question, and also 2 conclusions which need confirm.
Quoted 9 lines
1) Question:
Jeff Layton said in Red Hat Bugzilla (bug 848706):
"Have configuration where the same host is acting as both NFS client and server. That's a configuration known to cause deadlocks."Does it mean that the public Linux kernel (not Red Hat) also can cause deadlocks if NFS client and server are under the same machine ?
Yes.
Quoted 13 lines
2) Confirm 1: (better by Jeff Layton)
For function
nfs_commit_set_lockin./fs/nfs/write.cfor latest public kernel version:
the parameters ofout_of_line_wait_on_bit_lock()are (&nfsi->flags,NFS_INO_COMMIT,nfs_wait_killable,TASK_KILLABLE) for Red Hat kernel version: kernel-2.6.18-308.4.1.el5 the parameters ofout_of_line_wait_on_bit_lock()are (&nfsi->flags,NFS_INO_COMMIT,nfs_wait_bit_uninterruptible,TASK_UNINTERRUPTIBLE)
Quoted 9 lines
It means for red hat version:
when deadlock occurs, we can not boot machine in normal way (it is true for my test machine, the deadlock task can not be killed) It means for public kernel version:
"Assume deadlock occurs", we can still boot machine in normal way, because the task can be killed.Is what I said above correct ?
Not sure I understand your question. RHEL5 doesn't have support for TASK_KILLABLE, and I didn't backport it, hence the difference in that function.
Quoted 7 lines
3) Confirm 2:
Is LTP (Linux Test Project) still a suitable test tools for public kernel ? (for ltp-full-20100331.gz stress test, it mounts NFS on local machine, and the latest LTP ltp-full-20120401.bz2 also seems the same).
That I'm not sure of. All I can tell you is that mounts over loopback (or similar configurations) are easily deadlockable under load.
Signature · 1 line
Jeff Layton <[email protected]>
Quoted 10 lines · Jeff Layton
Quoted 7 lines · On Fri, 31 Aug 2012 13:40:16 +0800 gchen <[email protected]> wrote:
I have 1 question, and also 2 conclusions which need confirm.
1) Question:
Quoted 8 lines
Quoted 7 lines
Jeff Layton said in Red Hat Bugzilla (bug 848706):
"Have configuration where the same host is acting as both NFS client and server. That's a configuration known to cause deadlocks."Does it mean that the public Linux kernel (not Red Hat) also can cause deadlocks if NFS client and server are under the same machine ?
Yes.
I will communicate with LTP (Linux Test Project) to confirm it, too.
And, it will be better if other members in [email protected] also confirm it.
Quoted 19 lines
Quoted 19 lines
2) Confirm 1: (better by Jeff Layton)
For function
nfs_commit_set_lockin./fs/nfs/write.cfor latest public kernel version:
the parameters ofout_of_line_wait_on_bit_lock()are (&nfsi->flags,NFS_INO_COMMIT,nfs_wait_killable,TASK_KILLABLE) for Red Hat kernel version: kernel-2.6.18-308.4.1.el5 the parameters ofout_of_line_wait_on_bit_lock()are (&nfsi->flags,NFS_INO_COMMIT,nfs_wait_bit_uninterruptible,TASK_UNINTERRUPTIBLE)It means for red hat version:
when deadlock occurs, we can not boot machine in normal way (it is true for my test machine, the deadlock task can not be killed) It means for public kernel version:
"Assume deadlock occurs", we can still boot machine in normal way, because the task can be killed.
Quoted 5 lines
Quoted 2 lines
Is what I said above correct ?
Not sure I understand your question. RHEL5 doesn't have support for
TASK_KILLABLE, and I didn't backport it, hence the difference in that function.
I agree with what you said above.
Thanks for your confirmation.
Quoted 9 lines
Quoted 6 lines
3) Confirm 2:
Is LTP (Linux Test Project) still a suitable test tools for public kernel ? (for ltp-full-20100331.gz stress test, it mounts NFS on local machine, and the latest LTP ltp-full-20120401.bz2 also seems the same).
That I'm not sure of. All I can tell you is that mounts over loopback (or similar configurations) are easily deadlockable under load.
I will communicate with LTP (Linux Test Project) about these informations.
Thanks.
gchen.
Asianux Corporation.