Searched hist:222719 (Results 1 - 4 of 4) sorted by relevance
/freebsd-11-stable/sys/fs/nfsclient/ | ||
H A D | nfs_clrpcops.c | diff 222719 Sun Jun 05 16:27:44 MDT 2011 rmacklem The new NFSv4 client was erroneously using "p" instead of "p_leader" for the "id" for POSIX byte range locking. I think this would only have affected processes created by rfork(2) with the RFTHREAD flag specified. This patch fixes that by passing the "id" down through the various functions from nfs_advlock(). MFC after: 2 weeks |
H A D | nfs_clstate.c | diff 222719 Sun Jun 05 16:27:44 MDT 2011 rmacklem The new NFSv4 client was erroneously using "p" instead of "p_leader" for the "id" for POSIX byte range locking. I think this would only have affected processes created by rfork(2) with the RFTHREAD flag specified. This patch fixes that by passing the "id" down through the various functions from nfs_advlock(). MFC after: 2 weeks |
H A D | nfs_clport.c | diff 222719 Sun Jun 05 16:27:44 MDT 2011 rmacklem The new NFSv4 client was erroneously using "p" instead of "p_leader" for the "id" for POSIX byte range locking. I think this would only have affected processes created by rfork(2) with the RFTHREAD flag specified. This patch fixes that by passing the "id" down through the various functions from nfs_advlock(). MFC after: 2 weeks |
/freebsd-11-stable/sys/fs/nfs/ | ||
H A D | nfs_var.h | diff 222719 Sun Jun 05 16:27:44 MDT 2011 rmacklem The new NFSv4 client was erroneously using "p" instead of "p_leader" for the "id" for POSIX byte range locking. I think this would only have affected processes created by rfork(2) with the RFTHREAD flag specified. This patch fixes that by passing the "id" down through the various functions from nfs_advlock(). MFC after: 2 weeks |
Completed in 190 milliseconds