Change:
The implementation of generic ephemeral volumes depended on relaxing the "pod uses PVC" check such that PVC deletion is allowed to proceed even when the pod itself still exist, as long as it is certain that kubelet is done with the pod: As noted in that comment, there were diverging opinions about what deletionGracePeriodSeconds being zero means. This issue is about double-checking that and if necessary, come up with a better check.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig storage
Jordan in kubelet which causes to be set to zero: This is called "after terminating the containers and cleaning up the pod". So and are indeed equivalent. does this address the concern that you had regarding generic ephemeral volumes and pod shutdown? Whether "after terminating the containers and cleaning up the pod" is good enough for the PVC protection controller is a different question, but that then is also affecting normal PVCs and not just generic ephemeral volumes.
It looks like calls which calls : So it does look like this waits until pod volumes are successfully unmounted (minus the node unstage issue). This addresses my concern thanks!
Only thing left is to clean up the todo in the code.
See

Discussion:
// podIsShutDown returns true if kubelet is done with the pod or // it was force-deleted. func podIsShutDown(pod *v1.Pod) bool { <del> // The following text is based on how pod shutdown was // initially described to me. During PR review, it was pointed out // that this is not correct: "deleteGracePeriodSeconds tells // kubelet when it can start force terminating the // containers. Volume teardown only starts after containers // are termianted. So there is an additional time period after // the grace period where volume teardown is happening." // // TODO (https://github.com/kubernetes/enhancements/issues/1698#issuecomment-655344680): // investigate what kubelet really does and if necessary, // add some other signal for "kubelet is done". For now the check // is used only for ephemeral volumes, because it // is needed to avoid the deadlock. // </del> // A pod that has a deletionTimestamp and a zero // deletionGracePeriodSeconds <del> // a) has been processed by kubelet and is ready for deletion or </del> <ins> // a) has been processed by kubelet and was set up for deletion //    by the apiserver: //    - canBeDeleted has verified that volumes were unpublished //      https://github.com/kubernetes/kubernetes/blob/5404b5a28a2114299608bab00e4292960dd864a0/pkg/kubelet/kubelet_pods.go#L980 //    - deletionGracePeriodSeconds was set via a delete //      with zero GracePeriodSeconds //      https://github.com/kubernetes/kubernetes/blob/5404b5a28a2114299608bab00e4292960dd864a0/pkg/kubelet/status/status_manager.go#L580-L592 // or </ins> // b) was force-deleted. // // It's now just waiting for garbage collection. We could wait