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

Implements sys_fs_fcntl 0xC0000008 and 0xC000001A #11957

Merged
merged 2 commits into from Jun 11, 2022

Conversation

RipleyTom
Copy link
Contributor

Closes #2928

@RipleyTom RipleyTom force-pushed the cell_fs_stuff branch 4 times, most recently from fba5767 to 852163d Compare May 7, 2022 08:33
@RipleyTom RipleyTom marked this pull request as draft May 7, 2022 17:00
@RipleyTom RipleyTom force-pushed the cell_fs_stuff branch 4 times, most recently from 87b2716 to e4ce382 Compare May 7, 2022 21:16
@RipleyTom RipleyTom marked this pull request as ready for review May 7, 2022 21:17
@Megamouse
Copy link
Contributor

@elad335 please review

@RipleyTom RipleyTom force-pushed the cell_fs_stuff branch 4 times, most recently from 2ed420e to c9f3551 Compare May 11, 2022 08:06
@RipleyTom
Copy link
Contributor Author

I added a free method to lv2_memory_container that serves as a sanity check.

@RipleyTom RipleyTom force-pushed the cell_fs_stuff branch 2 times, most recently from d0e381a to 79f5721 Compare May 12, 2022 14:03

if (file->io_alloc_addr)
{
sys_memory_free(ppu, file->io_alloc_addr);
Copy link
Contributor

Choose a reason for hiding this comment

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

It's not what I meant and altering user-memory area is a bad hack especially if coming from lv2.

Copy link
Contributor

@elad335 elad335 May 12, 2022

Choose a reason for hiding this comment

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

The changes done by taking and freeing memory should be observable as one by other threads, that's why I said adding the memory stats mutex lock.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How is it a bad hack when it's what happens on ps3?
It's meant to allocate memory from a user container...

Copy link
Contributor

@elad335 elad335 May 12, 2022

Choose a reason for hiding this comment

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

LV2 memory has nothing to do with user memory. It's in totally diffetent address space. Where user memory is kept under 4GB barrier, LV2's is all about addressing space above it.

Copy link
Contributor

Choose a reason for hiding this comment

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

And allotting more user memory than the game has allocated in user memory area may create a false memory shortage. Yes, it is possible to exhaust vm::user64k area with much less than 256mb of memory in special sequence of code.

Copy link
Contributor

Choose a reason for hiding this comment

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

What happens if take fails? usually LV2 reverts all changes upon failure.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It always frees the previously allocated memory even if the new allocation fails.

Copy link
Contributor

Choose a reason for hiding this comment

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

Can you test it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did, that's how I know.

Copy link
Contributor

Choose a reason for hiding this comment

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

Okay, than it's probably not atomic if it does it this way.

@RipleyTom RipleyTom marked this pull request as draft May 12, 2022 15:04
@RipleyTom RipleyTom force-pushed the cell_fs_stuff branch 2 times, most recently from b44cbd5 to d62088b Compare May 12, 2022 20:26
@RipleyTom RipleyTom marked this pull request as ready for review May 12, 2022 20:27
@RipleyTom RipleyTom force-pushed the cell_fs_stuff branch 3 times, most recently from 98798a8 to 602efe3 Compare May 13, 2022 15:12
@RipleyTom RipleyTom marked this pull request as draft May 13, 2022 15:23
@RipleyTom RipleyTom marked this pull request as ready for review May 13, 2022 15:32
@AniLeo AniLeo merged commit da6434a into RPCS3:master Jun 11, 2022
@RipleyTom RipleyTom deleted the cell_fs_stuff branch October 20, 2022 08:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

sys_fs_fcntl(): Unknown operations
4 participants