cgroup: ebpf: make unexpected errors in haveBpfProgReplace louder

If we get an unexpected error here, it is probably because of a library
or kernel change that could cause our detection logic to be invalid. As
a result, these warnings should be louder so users have a chance to tell
us about them sooner (or so we might notice them before doing a release,
as happened with the 1.2.0 regression).

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>

libcontainer/cgroups/devices/ebpf_linux.go

@@ -107,14 +107,14 @@ func haveBpfProgReplace() bool {
 			},
 		})
 		if err != nil {
-			logrus.Debugf("checking for BPF_F_REPLACE support: ebpf.NewProgram failed: %v", err)
+			logrus.Warnf("checking for BPF_F_REPLACE support: ebpf.NewProgram failed: %v", err)
 			return
 		}
 		defer prog.Close()
 
 		devnull, err := os.Open("/dev/null")
 		if err != nil {
-			logrus.Debugf("checking for BPF_F_REPLACE support: open dummy target fd: %v", err)
+			logrus.Warnf("checking for BPF_F_REPLACE support: open dummy target fd: %v", err)
 			return
 		}
 		defer devnull.Close()
@@ -138,7 +138,11 @@ func haveBpfProgReplace() bool {
 			return
 		}
 		if !errors.Is(err, unix.EBADF) {
-			logrus.Debugf("checking for BPF_F_REPLACE: got unexpected (not EBADF or EINVAL) error: %v", err)
+			// If we see any new errors here, it's possible that there is a
+			// regression due to a cilium/ebpf update and the above EINVAL
+			// checks are not working. So, be loud about it so someone notices
+			// and we can get the issue fixed quicker.
+			logrus.Warnf("checking for BPF_F_REPLACE: got unexpected (not EBADF or EINVAL) error: %v", err)
 		}
 		haveBpfProgReplaceBool = true
 	})