diff mbox series

util: swupdate_remove_directory: remove error if target is missing

Message ID 20240731003708.3979149-1-dominique.martinet@atmark-techno.com
State Changes Requested
Delegated to: Stefano Babic
Headers show
Series util: swupdate_remove_directory: remove error if target is missing | expand

Commit Message

Dominique Martinet July 31, 2024, 12:37 a.m. UTC
commit a6ad222f58a5 ("util: Ensure swupdate_remove_directory unmounts
path") added a check for swupdate_remove_directory() to umount the
target if it is a mount point, but if it had already been cleaned up
then an error will now be printed.

If the file is already missing there is just nothing to do, do not print
an error message.

Cc: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
---
our update script was already removing the path, so this error started
showing up after upgrading; I guess we could keep the error if parent is
missing and perhaps a trace if the dir itself is missing?
Happy to adjust the patch if these messages are deemed useful.

(I guess I could also remove the cleanup on our side, I'm taking care to
not descend into submounts but since this runs afterwards anyway it's not
like that's any help; do we want to set FTW_MOUNT to the nftw call?)

 core/util.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

Comments

Stefano Babic July 31, 2024, 7:46 a.m. UTC | #1
Hi Dominique,

On 31.07.24 02:37, Dominique Martinet wrote:
> commit a6ad222f58a5 ("util: Ensure swupdate_remove_directory unmounts
> path") added a check for swupdate_remove_directory() to umount the
> target if it is a mount point, but if it had already been cleaned up
> then an error will now be printed.
>
> If the file is already missing there is just nothing to do, do not print
> an error message.
>
> Cc: James Hilliard <james.hilliard1@gmail.com>
> Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
> ---
> our update script was already removing the path, so this error started
> showing up after upgrading;

But in this case you are doing something that it is not expected.
SWUpdate must create and remove the resources, including paths, and it
is not expected that someone else is removing files that belong to SWUpdate.

Anyway, cleanup is not an error, and return error from
swupdate_remove_directory is not checked. Any entry in the log by
calling this function should be marked with a level lower than ERROR.

> I guess we could keep the error if parent is
> missing and perhaps a trace if the dir itself is missing?
> Happy to adjust the patch if these messages are deemed useful.

But is this happening if nobody is removing path or resources ? SWUpdate
tracks what has created and destroy at the end. The ERROR you see are
signalling that something happened that was unexpected (i.e. someone
removing paths). I will lower down ERROR to WARN.

>
> (I guess I could also remove the cleanup on our side,

IMHO it is better

> I'm taking care to
> not descend into submounts but since this runs afterwards anyway it's not
> like that's any help; do we want to set FTW_MOUNT to the nftw call?)

We can add to enforce and avoid side effect - SWUpdate is checking if it
is a mount point and unmount itself.

>
>   core/util.c | 7 ++++---
>   1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/core/util.c b/core/util.c
> index 33a9af7114a3..09bdf93b1e51 100644
> --- a/core/util.c
> +++ b/core/util.c
> @@ -173,12 +173,10 @@ static int _is_mount_point(const char *path, const char *parent_path) {
>   	struct stat path_stat, parent_stat;
>
>   	if (stat(path, &path_stat)) {
> -		ERROR("stat for path %s failed: %s", path, strerror(errno));
>   		return -errno;
>   	}
>
>   	if (stat(parent_path, &parent_stat)) {
> -		ERROR("stat for parent path %s failed: %s", parent_path, strerror(errno));
>   		return -errno;
>   	}
>
> @@ -209,8 +207,11 @@ int swupdate_remove_directory(const char* path)
>   	}
>
>   	ret = _is_mount_point(dpath, get_tmpdir());
> -	if (ret < 0)
> +	if (ret < 0) {
> +		// directory already removed
> +		ret = 0;
>   		goto out;
> +	}
>
>   	if (ret) {
>   		WARN("Unexpected mountpoint, unmounting: %s", dpath);


Best regards,
Stefano
Dominique Martinet July 31, 2024, 8:09 a.m. UTC | #2
Stefano Babic wrote on Wed, Jul 31, 2024 at 09:46:52AM +0200:
> > I guess we could keep the error if parent is
> > missing and perhaps a trace if the dir itself is missing?
> > Happy to adjust the patch if these messages are deemed useful.
> 
> But is this happening if nobody is removing path or resources ? SWUpdate
> tracks what has created and destroy at the end. The ERROR you see are
> signalling that something happened that was unexpected (i.e. someone
> removing paths). I will lower down ERROR to WARN.

Thanks, I'll let you lower the warning (and perhaps fix the return value
or make it void since nobody checks it? I guess that doesn't really
matter)

> > (I guess I could also remove the cleanup on our side,
> 
> IMHO it is better

Ok, I think that was leftover from before swupdate was cleaning it up,
but looking back we don't have any release with that so it must have
been early experiments; I'll just remove this cleanup on my side.

> > I'm taking care to
> > not descend into submounts but since this runs afterwards anyway it's not
> > like that's any help; do we want to set FTW_MOUNT to the nftw call?)
> 
> We can add to enforce and avoid side effect - SWUpdate is checking if it
> is a mount point and unmount itself.

(upon verification I actually wasn't taking any care at all there...)
I'll note this is welcome; actually checking if something is a
mountpoint is more work than I can put in right now but that might be an
improvement for later.

BTW note the current check for is a mountpoint is not correct in case of
bind mount within the same filesystem, e.g. if /foo and /bar are in the
same filesystem then `mount --bind /foo /bar/subdir` will not have
/bar/subdir detected as a mountpoint by this version of _is_mount_point.

The correct thing to do is to check if any mount targets in
/proc/self/mounts is a subpath of the path we're considering (assuming
it is canonical e.g. no ../ or double slashes), but that's also more
work than I'm willing to put into short term as we never mount anything
there so it's probably fine as is -- remove will fail, terminating nftw
with -1 in turn and we're not checking that at all for a warning, but
hopefully such mount points shouldn't happen...
(but I guess that since James added the check it did somewhere?!)


Cheers,
diff mbox series

Patch

diff --git a/core/util.c b/core/util.c
index 33a9af7114a3..09bdf93b1e51 100644
--- a/core/util.c
+++ b/core/util.c
@@ -173,12 +173,10 @@  static int _is_mount_point(const char *path, const char *parent_path) {
 	struct stat path_stat, parent_stat;
 
 	if (stat(path, &path_stat)) {
-		ERROR("stat for path %s failed: %s", path, strerror(errno));
 		return -errno;
 	}
 
 	if (stat(parent_path, &parent_stat)) {
-		ERROR("stat for parent path %s failed: %s", parent_path, strerror(errno));
 		return -errno;
 	}
 
@@ -209,8 +207,11 @@  int swupdate_remove_directory(const char* path)
 	}
 
 	ret = _is_mount_point(dpath, get_tmpdir());
-	if (ret < 0)
+	if (ret < 0) {
+		// directory already removed
+		ret = 0;
 		goto out;
+	}
 
 	if (ret) {
 		WARN("Unexpected mountpoint, unmounting: %s", dpath);