Bug 216086
| Summary: | An NFSv4.1 client openowner structure is erroneously free'd when recovery fails | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Rick Macklem <rmacklem> | ||||
| Component: | kern | Assignee: | Rick Macklem <rmacklem> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Some People | Keywords: | patch | ||||
| Priority: | --- | Flags: | rmacklem:
mfc-stable11+
rmacklem: mfc-stable10+ |
||||
| Version: | CURRENT | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
A commit references this bug: Author: rmacklem Date: Tue Apr 11 22:47:02 UTC 2017 New revision: 316719 URL: https://svnweb.freebsd.org/changeset/base/316719 Log: Don't throw away Open state when a NFSv4.1 client recovery fails. If the ExchangeID/CreateSession operations done by an NFSv4.1 client after the server crashes/reboots fails, it is possible that some process/thread is waiting for an open_owner lock. If the client state is free'd, this can cause a crash. This would not normally happen, but has been observed on a mount of the AmazonEFS service. Reported by: cperciva Tested by: cperciva PR: 216086 MFC after: 2 weeks Changes: head/sys/fs/nfsclient/nfs_clstate.c Patch has been committed and MFC'd. |
Created attachment 178894 [details] Don't free openowner+opens when a recovery attempt fails When the NFSv4.1 client attempts recovery from a server crash/reboot and the new ExchangeID/CreateSession fails 5 times, the code free'd the openowner structure and cleared the NFSCLFLAGS_HASCLIENTID. However, it is possible that a process holds the lock on the openowner at this time and, as such, the openowner should not be free'd. It also makes sense to keep the opens in case a subsequent recovery is successful. This scenario would not normally happen, but apparently does for the AmazonEFS server. This patch changes the code to not free the openowner + opens and leave the flag set for the crash/lease_expiry recovery cases.