KolibriOS/kolibrios
15
24
Fork 61
Code Issues 126 Pull Requests 37 Actions Projects 1 Releases Wiki Activity

fs/ext2: support legacy Rev0 superblocks #421

Merged
Burer merged 3 commits from Matou1306/kolibrios:ext2-good-old-rev0 into main 2026-05-30 05:07:24 +00:00
Conversation 7 Commits 3 Files Changed 1
+9
Matou1306 commented 2026-04-14 07:54:51 +00:00
Contributor
Copy Link
Copy Source

Ext2 Rev0 superblocks lack dynamic fields. Add fallback logic to check for EXT2_GOOD_OLD_REV and manually populate in-memory inodeSize (128) and firstInode (11). 

Introduce standard EXT2_GOOD_OLD_* constants aligning with Linux kernel approach for the same issue.

This aligns with what the Linux Kernel does.

Ext2 Rev0 superblocks lack dynamic fields. Add fallback logic to check for EXT2_GOOD_OLD_REV and manually populate in-memory inodeSize (128) and firstInode (11).  Introduce standard EXT2_GOOD_OLD_* constants aligning with Linux kernel approach for the same issue. This aligns with [what the Linux Kernel does](https://github.com/torvalds/linux/blob/master/fs/ext2/super.c#L1036-L1039).
dunkaist requested review from dunkaist 2026-04-15 12:41:03 +00:00
dunkaist commented 2026-04-15 12:42:31 +00:00
Owner
Copy Link
Copy Source

@Matou1306, were you able to find or create a revision 0 FS to test this change?

@Matou1306, were you able to find or create a revision 0 FS to test this change?
Matou1306 added 2 commits 2026-04-20 23:20:14 +00:00
fs/ext2: support legacy Rev0 superblocks c04d8d96b7 
Ext2 Rev0 superblocks lack dynamic fields. Add fallback logic to check for EXT2_GOOD_OLD_REV and manually populate in-memory inodeSize (128) and firstInode (11). 

Introduce standard EXT2_GOOD_OLD_* constants aligning with Linux kernel approach for the same issue.
codestyle
Build system / Check kernel codestyle (pull_request) Successful in 2m13s
Details
Build system / Build (pull_request) Successful in 18m57s
Details
bddaf56c95
Matou1306 force-pushed ext2-good-old-rev0 from 7972a6baff to bddaf56c95 2026-04-20 23:20:14 +00:00 Compare
dunkaist commented 2026-05-17 03:57:43 +00:00
Owner
Copy Link
Copy Source

@Matou1306, what about the fields s_feature_compat, s_feature_incompat, and s_feature_ro_compat? If I understand correctly, they are present only in revision 1 superblocks, but the current code reads them always. Do I miss anything?

@Matou1306, what about the fields s_feature_compat, s_feature_incompat, and s_feature_ro_compat? If I understand correctly, they are present only in revision 1 superblocks, but the current code reads them always. Do I miss anything?
Matou1306 added 1 commit 2026-05-20 11:19:46 +00:00
merge upstream
Build system / Check kernel codestyle (pull_request) Successful in 33s
Details
Build system / Build (pull_request) Successful in 9m43s
Details
7a0917fbe9
Matou1306 commented 2026-05-21 19:18:57 +00:00
Author
Contributor
Copy Link
Copy Source

@dunkaist For the features they don't cause any errors in the original rev0. The usable superblock fields were indeed only 84 bytes but the superblock size is 1024, so the remaining is explicitly zeroed out.

I also made the test and opened a PR on umka, it only tests ls70, without the fix this outputs file system error, with the fix it reads it normally. I tried read70 but it resulted in access denied (I guess that's because it's the superblock)

I created the image with mkfs but manually matched the rev0 partition style from the hdd loop device you sent me before.

@dunkaist For the features they don't cause any errors in the original rev0. The usable superblock fields were indeed only 84 bytes but the superblock size is 1024, so the remaining is explicitly zeroed out. I also made the test and opened a PR on umka, it only tests ls70, without the fix this outputs file system error, with the fix it reads it normally. I tried read70 but it resulted in access denied (I guess that's because it's the superblock) I created the image with mkfs but manually matched the rev0 partition style from the hdd loop device you sent me before.
dunkaist commented 2026-05-23 03:46:15 +00:00
Owner
Copy Link
Copy Source

the remaining is explicitly zeroed out

Is this guaranteed by the spec for all cases, or is it so just for the particular test image?

> the remaining is explicitly zeroed out Is this guaranteed by the spec for all cases, or is it so just for the particular test image?
Matou1306 commented 2026-05-23 09:30:29 +00:00
Author
Contributor
Copy Link
Copy Source

I saw the linux kernel completely ignores this, so it seems like it is indeed filled out with 0s. Not doing so can also be a vulnerability since the garbage data that would've been filled isn't actually garbage and might contain sensitive data, writing this to the disk wouldn't have been a safe practice

I saw the linux kernel completely ignores this, so it seems like it is indeed filled out with 0s. Not doing so can also be a vulnerability since the garbage data that would've been filled isn't actually garbage and might contain sensitive data, writing this to the disk wouldn't have been a safe practice
👍 1
dunkaist approved these changes 2026-05-26 15:20:33 +00:00
dunkaist requested review from Burer 2026-05-26 15:21:18 +00:00
dunkaist requested review from Doczom 2026-05-26 15:21:18 +00:00
Doczom approved these changes 2026-05-29 18:03:42 +00:00
Burer merged commit 779ea18d4e into main 2026-05-30 05:07:23 +00:00
Burer deleted branch ext2-good-old-rev0 2026-05-30 05:07:24 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
dunkaist
Burer
Doczom
Labels
Clear labels
C
Category/Applications
Category/Drivers
Category/General
Category/Kernel
Category/Libraries
Eolite
FASM
FS
GSoC
This issue in GSoC program
 HardwareTested
HLL
Influence/Settings
Influence/Text/TYPO
IRCC
Kernel
Kind
Breaking
Breaking change that won't be backward compatible
Kind
Bug
Something is not working
Kind
Build
Kind
Documentation
Documentation changes
Kind
Enhancement
Improve existing functionality
Kind
Feature
New functionality
Kind
Security
This is security issue
Kind
Testing
Issue or pull request related to testing
Pay for the code
Paid task
PR
Conflicts
PR conflicts with main
PR
Dependent
This PR is dependent on another PR
Priority
Critical
The priority is critical
Priority
High
The priority is high
Priority
Low
The priority is low
Priority
Medium
The priority is medium
PR
Ready to merge
Pull request is ready for merge
PR
Request changes
Changes requested in pull request
PR
Review required
Reviewed
Confirmed
Issue has been confirmed
Reviewed
Duplicate
This issue or pull request already exists
Reviewed
Invalid
Invalid issue
Reviewed
Won't Fix
This issue won't be fixed
Status
Abandoned
Somebody has started to work on this but abandoned work
Status
Blocked
Something is blocking this issue or pull request
Status
Need More Info
Feedback is required to reproduce issue or to continue work
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
ace-dent (Andrew) Burer Doczom (Mikhail Frolov) dunkaist (Ivan B) hidnplayr IgorA Leency (Kiril Lipatov) mxlgv (Max Logaev) ramenu rgimad sdongles (Serhii Sakhno) Sweetbread (Gleb Zaharov)
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: KolibriOS/kolibrios#421
Delete Branch "Matou1306/kolibrios:ext2-good-old-rev0"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?