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

Processes overwriting each other in a shared File during Fork syscall #261

Open
yashaswi2000 opened this issue Jun 11, 2024 · 0 comments
Open
Labels
bug Something isn't working

Comments

@yashaswi2000
Copy link
Contributor

yashaswi2000 commented Jun 11, 2024

Description

Parent and child processes overwrite each others output, when using shared files. This is happening due to lack of a shared file offset across processes. In traditional UNIX systems and probably also in Linux systems, the file structure is as follows:
file descriptors in process fd table -> kernel level open file table -> vnode/inode. and file offsets are stored in kernel level open file table.

Cases:

  • when independent processes open the same file.

    In this case each process will have a fd in its own process table, which will be pointing to an entry in kernel open file table. so even kernel open file table will have two entries each from corresponding processes pointing to the same inode/vnode. so in this case file offsets are completely independent as they are two different entries in open file table. and overwriting is normal behaviour.
  • when forking happens and child and parent process write to the same file.

    Assuming Atomic writes each process will have its own entry of fd in its process table, which points to the same entry in kernel open file table. so both fds point to the same entry in the open file table. Thus sharing the file offset and each of them update this as and when writes happen.

Why this behaviour?

In RustPosix, the file offsets are stored inside process fd tables and not in the open file table. which doesnt cause any issues when independent processes are using same files, but since there is no way to share a file offset, this causes unexpected behaviour in fork syscall case.

How is this Tested?

With Buffered and unbuffered calls like fprintf and dprintf along with direct write syscalls.
verified this behaviour as the behaviour falls in expected case when using lseek manually and writing across processes.

References

https://www.cs.rpi.edu/academics/courses/fall04/os/c18/#:~:text=When%20a%20file%20is%20first,to%20the%20next%20unread%20byte.

@yashaswi2000 yashaswi2000 added the bug Something isn't working label Jun 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant