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:
7117464
here, you are changing do_proc_read -> do_cg_read
1b8d493
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 #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 (7117464 and 1b8d493) 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]

cgroup_is_enabled && LXCFS_TYPE_CGROUP(type)

[DevonSchwartz]

Added change

[mihalicyn]

small nit

[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 <[email protected]>

Fixed reads so that they have proper parameters

Signed-off-by: Devon Schwartz <[email protected]>

Fixed semicolon and variable instantiation

Signed-off-by: Devon Schwartz <[email protected]>

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 <[email protected]>

Fixed reads so that they have proper parameters

Signed-off-by: Devon Schwartz <[email protected]>

Fixed semicolon and variable instantiation

Signed-off-by: Devon Schwartz <[email protected]>

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?

[DevonSchwartz]

@mihalicyn Did I correctly address your desired changes? I think the merge is still blocked because of the review request on May 3.

[mihalicyn]

Hey @DevonSchwartz

sorry for a long delay with the reply.

Yeah, now it looks good.

For some reason GitHub runners get stuck to test this one. I guess you need to do something like git commit --amend && git push -f to retrigger tests.

[DevonSchwartz]

Thanks @mihalicyn . Just made the push

[stgraber]

Thanks!