ap_tools/ap-check: handle get-attributes between pre and post event

Since mdevctl commit acf78c1ff6c9 it is now possible for the
get-attributes event to occur between a pre-define and post-define.
This is done in order to obtain the active attributes for the device
before writing them to the config file, and implies that the
get-attributes cannot re-obtain the file lock.  For other cases
where mdevctl calls get-attributes, the file lock is not already
held and must be obtained by ap-check before reading attributes from
active devices.
To solve this, let's use the knowledge that mdevctl is a single-threaded
tool and add a test to detect this scenario.  If the file lock is
already held by the parent during a get-attributes, don't attempt to
re-acquire it.

Reported-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>

libap/ap.c

@@ -722,6 +722,34 @@ int ap_get_lock_callout(void)
 	return util_lockfile_parent_lock(AP_LOCKFILE, AP_LOCK_RETRIES);
 }
 
+/**
+ * Attempt to acquire the ap config lock using the Parent Process ID without
+ * waiting/retries.  Detect if the attempt was rejected because the lock is
+ * already held by the Parent Process ID.
+ *
+ * @retval         0          Lock acquired on behalf of parent process
+ * @retval         1          Lock not obtained, already held by parent
+ * @retval         != 0       Lock was not obtained, other error
+ */
+int ap_try_lock_callout(void)
+{
+	int pid, ppid, rc;
+
+	if (util_lockfile_parent_lock(AP_LOCKFILE, 0)) {
+		/* Lock is already held, let's peek at the owner */
+		ppid = getppid();
+		rc = util_lockfile_peek_owner(AP_LOCKFILE, &pid);
+		if (rc || pid != ppid) {
+			/* We didn't get the lock, unknown or other owner */
+			return 2;
+		}
+		/* Signify that the lock is already held by the caller */
+		return 1;
+	}
+
+	return 0;
+}
+
 /**
  * Release the ap config lock
  *