fix: statle smb mount issue when smb file share is deleted and then unmount

[andyzhangx]

What type of PR is this?

/kind bug

What this PR does / why we need it:

fix: statle smb mount issue when smb file share is deleted and then unmount

there is behavior change from linux kernel 5.15.0-1051-azure (or earlier version), when smb file share is deleted, the upstream mount-utils depends on following logic to check whether smb mount is in stale state, while starting from the former kernel version, it returns resource temporarily unavailable error instead of ErrNotExist, thus this PR tries to add a new judgement in the mount-utils in IsCorruptedMnt func, here EWOULDBLOCK is resource temporarily unavailable error.

{11, "EWOULDBLOCK", "resource temporarily unavailable"},

• original logic (won't work now since it now returns it returns resource temporarily unavailable error instead of ErrNotExist in kernel)
  

  kubernetes/staging/src/k8s.io/mount-utils/mount_helper_unix.go

  Lines 188 to 198 in a95a79c

  	} else if errors.Is(err, fs.ErrNotExist) {
  	err = syscall.Access(path, syscall.F_OK)
  	if err == nil {
  	// The access syscall says the file exists, the stat syscall says it
  	// doesn't. This was observed on CIFS when the path was removed at
  	// the server somehow. POSIX calls this a stale file handle, let's fake
  	// that error and treat the path as existing but corrupted.
  	klog.Warningf("Potential stale file handle detected: %s", path)
  	return true, syscall.ESTALE
  	}
  	return false, nil

• currunt error message is like following:

kubernetes.io/csi: Unmounter.TearDownAt failed: rpc error: code = Internal desc = failed to unmount target /var/lib/kubelet/pods/bf4554ca-de3d-43e3-8d93-f35f14406e4f/volumes/kubernetes.io~csi/volume1/mount: Error checking path: stat /var/lib/kubelet/pods/bf4554ca-de3d-43e3-8d93-f35f14406e4f/volumes/kubernetes.io~csi/volume1/mount: resource temporarily unavailable

• how to repro this issue

1. mount smb file share using csi driver or subPath volume
2. delete remote smb file share
3. delete pod, and unmount would be stuck forever (pod in terminating state forever)

• workaround
  force delete the pod

• impact

This issue does not only break CSI drivers, it also breaks on pods with subPath smb volume, error msg is like following, this requires a patch version fix of kubelet since subPath unmount does not go through CSI driver.

Error: error cleaning subPath mounts for volume "volume1" (UniqueName: "kubernetes.io/csi/644d3846-709a-4165-8b13-c1003409d588-volume1") pod "644d3846-709a-4165-8b13-c1003409d588" (UID: "644d3846-709a-4165-8b13-c1003409d588") : error processing /var/lib/kubelet/pods/644d3846-709a-4165-8b13-c1003409d588/volume-subpaths/volume1/helloworld-mount-subpath: error cleaning subpath mount /var/lib/kubelet/pods/644d3846-709a-4165-8b13-c1003409d588/volume-subpaths/volume1/helloworld-mount-subpath/0: Error checking path: stat /var/lib/kubelet/pods/644d3846-709a-4165-8b13-c1003409d588/volume-subpaths/volume1/helloworld-mount-subpath/0: resource temporarily unavailable

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?

fix: statle smb mount issue when smb file share is deleted and then unmount

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

fix: statle smb mount issue when smb file share is deleted and then unmount

[andyzhangx]

/kind bug
/priority important-soon
/sig storage
/triage accepted

[andyzhangx]

/assign @jingxu97 @msau42

[andyzhangx]

@jingxu97 @msau42 could you review this PR asap? I would like to cherrypick this fix to earlier versions, thanks.

[andyzhangx]

@jsafrane can you take a look? thanks.

[jsafrane]

/lgtm
/approve
/milestone v1.29
This is serious enough for some kernels and at the same time it should not break anything else.

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: b211ee78f42277554b58605565bcd967226a3441

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andyzhangx, jsafrane

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• staging/src/k8s.io/mount-utils/OWNERS [jsafrane]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[andyzhangx]

this issue is fixed in v1.26.13, v1.27.10, v1.28.6, v1.29.0