Fix lxcfs read null

[DevonSchwartz]

We used the macros that were implemented for lxcfs_release() to fix the NULL path issue. This will replace the existing strcmp solution.

These macros have already been merged into the main branch to resolve the lxcfs_release() issue.

fix #635

[stgraber]

@mihalicyn can you review this one please?

[mihalicyn]

Hi @DevonSchwartz

Thanks for your PR! Please, can you explain how this is connected with #599 ? Why have you mentioned this issue?

[DevonSchwartz]

I made a mistake linking that issue. I meant to link this issue instead. I will go ahead and fix that. Sorry for the confusion.

[mihalicyn]

Next question is why are you change only lxcfs_read, but no touching other functions.

Also, please, can you explain the reason of this changes: https://github.com/lxc/lxcfs/pull/640/commits/7117464add690a8f7e3bb255158382aa4d47c996 here, you are changing do_proc_read -> do_cg_read https://github.com/lxc/lxcfs/pull/640/commits/1b8d493c82a083c55d66e788aabe6dd8376ffe91 then, do_cg_read -> do_proc_read

[DevonSchwartz]

I change lxcfs_read because that was the only function specified. I did not want to change other functions that were not in the scope of the issue We changed those because we were accidentally calling do_cg_read() for every case of LXCFS_TYPE, instead of the correct function. For example, when LXCFS_TYPE_PROC(type) was true, we should not have called do_cg_read. This issue came up when we compiled locally.

[mihalicyn]

Ah, so, this PR is an attempt to fix https://github.com/lxc/lxcfs/issues/635?

[mihalicyn]

We changed those because we were accidentally calling do_cg_read() for every case of LXCFS_TYPE, instead of the correct function. For example, when LXCFS_TYPE_PROC(type) was true, we should not have called do_cg_read. This issue came up when we compiled locally.

You need to squash all (3) commits into one then (https://docs.github.com/en/get-started/using-git/about-git-rebase). It is a good practice to have one commit per logical change. But in your case you have two commits (https://github.com/lxc/lxcfs/commit/7117464add690a8f7e3bb255158382aa4d47c996 and https://github.com/lxc/lxcfs/commit/1b8d493c82a083c55d66e788aabe6dd8376ffe91) which do the opposite thing (first - introduces a wrong change and second reverts it). This is not something we want. ;-)

[mihalicyn]

In general, I can't see how this change can fix issue in #635, because in there we have a pretty-pretty weird stack. It looks like something is terribly wrong with the dynamic symbol resolution. It is not the same bug as we had with lxcfs_release.

[DevonSchwartz]

Just squashed the commits.

[mihalicyn]

Please, edit commit message:

 Combine last 3 commits into one commit that changes the macros

Changed the strcmp in lxcfs_read() to macros

Signed-off-by: Devon Schwartz <devon.s.schwartz@utexas.edu>

Fixed reads so that they have proper parameters

Signed-off-by: Devon Schwartz <devon.s.schwartz@utexas.edu>

Fixed semicolon and variable instantiation

Signed-off-by: Devon Schwartz <devon.s.schwartz@utexas.edu>

using git commit --amend. You need to have only one Signed-off-by tag and one commit desciption. You can take some inspiration about how we format git commit messages from git log.

[DevonSchwartz]

Please, edit commit message:

 Combine last 3 commits into one commit that changes the macros

Changed the strcmp in lxcfs_read() to macros

Signed-off-by: Devon Schwartz <devon.s.schwartz@utexas.edu>

Fixed reads so that they have proper parameters

Signed-off-by: Devon Schwartz <devon.s.schwartz@utexas.edu>

Fixed semicolon and variable instantiation

Signed-off-by: Devon Schwartz <devon.s.schwartz@utexas.edu>

using git commit --amend. You need to have only one Signed-off-by tag and one commit desciption. You can take some inspiration about how we format git commit messages from git log.

small nit

Thank you! Just changed the previous commit message to one sign-off and fixed the cgroup_is_enabled issue.

[DevonSchwartz]

I went ahead and added the checks to FUSE file system calls except open/opendir. Should we find a way to create a safe macro for the non-FUSE calls too?

Update: I just realized that those would may not have an equivalent macro because the macro relies on file type info.

[DevonSchwartz]

Should I squash the latest commits to close this issue?

[stgraber]

Yeah, a single clean commit would be good I think.

[DevonSchwartz]

Should I resolve the change requested from above?