Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[LibOS] Ignore O_TRUNC flag for FIFO files #1401

Conversation

sahason
Copy link
Contributor

@sahason sahason commented Jun 19, 2023

Description of the changes

During enablement of mxnet-model-server in gramine one issue is observed that for FIFO files opening it with O_TRUNC returns EINVAL. In the native O_TRUNC flag for FIFO files is ignored. See man 2 open. This PR also emulates the same behaviour for gramine.

How to test this PR?

Modify this line

fd = open(FIFO_PATH, O_NONBLOCK | O_RDONLY);
by adding O_TRUNC flag and replacing O_RDONLY by O_RDWR and test this PR by running regression test.


This change is Reviewable

Copy link

@dimakuv dimakuv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (3 more required), not enough approvals from different teams (2 more required, approved so far: ) (waiting on @sahason)

a discussion (no related file):
Thanks @sahason for the PR. The idea is correct, but I'll take over this PR and will fix it to be more "Gramine" standard.


Signed-off-by: Sonali Saha <sonali.saha@intel.com>
@dimakuv dimakuv force-pushed the sahason/handle_fifo_truncate_error branch from 65f1788 to 42bd145 Compare June 19, 2023 07:33
Copy link

@dimakuv dimakuv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 3 of 3 files at r2, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions, not enough approvals from maintainers (3 more required), not enough approvals from different teams (2 more required, approved so far: ) (waiting on @sahason)

a discussion (no related file):

Previously, dimakuv (Dmitrii Kuvaiskii) wrote…

Thanks @sahason for the PR. The idea is correct, but I'll take over this PR and will fix it to be more "Gramine" standard.

Done


a discussion (no related file):
I tested this PR.

  • Before this change:
[P1:T1:mkfifo] trace: ---- openat(AT_FDCWD, "tmp/fifo", O_WRONLY|O_TRUNC|0x800, 0000) = -22
  • After this change:
[P1:T1:mkfifo] trace: ---- openat(AT_FDCWD, "tmp/fifo", O_WRONLY|O_TRUNC|0x800, 0000) = 0x4


libos/src/fs/pipe/fs.c line 215 at r2 (raw file):

         * covers most apps seen in the wild (in particular, LTP apps). */
        log_warning("FIFO (named pipe) '%s' cannot be opened in read-write mode in Gramine. "
                    "Treating it as read-only.", dent->name);

This is an unrelated change which I detected when playing with libos/test/regression/mkfifo.c and open(O_RDWR).

Before this change Gramine would output:

warning: FIFO (named pipe) '/' cannot be opened in read-write mode in Gramine. Treating it
 as read-only.

After this change:

warning: FIFO (named pipe) 'fifo' cannot be opened in read-write mode in Gramine. Treating
 it as read-only.

libos/test/regression/mkfifo.c line 65 at r2 (raw file):

            /* wait until client is ready for read (O_TRUNC flag here is only for testing) */
            errno = 0;
            fd = open(FIFO_PATH, O_NONBLOCK | O_WRONLY | O_TRUNC);

I added O_TRUNC to this server part (opening the write end of the FIFO pipe) purely for testing this corner case.

Same could be added to the client part (as @sahason did in the PR description), but I found it too convoluted for a test -- I don't think applications really do RW on FIFO pipes. Or even if they do, that's technically incorrect.

@dimakuv
Copy link

dimakuv commented Jun 19, 2023

Jenkins, test this please

Copy link
Contributor

@kailun-qin kailun-qin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 3 of 3 files at r2, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @sahason)

Copy link

@dimakuv dimakuv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: all files reviewed, all discussions resolved, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel)

Copy link

@dimakuv dimakuv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: all files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel) (waiting on @sahason)

a discussion (no related file):
Incidentally, we implemented a similar fix in 1563. So when that one is merged, we can close this PR.


@dimakuv
Copy link

dimakuv commented Sep 28, 2023

This was fixed as part of #1563 (which will be merged today). Closing.

@dimakuv dimakuv closed this Sep 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants