The alloca() does give us pointer and we have no practical way to check if the area
is actually available, resulting in corruption in corner cases.
Unfortunately we do not have too many options right now, but to use one page.
Details
Details
- Reviewers
allanjude imp - Commits
- rS313349: loader: disk io should not use alloca()
Done usb/disk boot and no immediate issues were detected, CD boot is in queue.
The CD boot is the most probable victim as the one page is just enough for
2 sectors (2KB).
About the background: The loader (user) memory starts from physical address 0xa000,
we have loader code, data and bss segments there. The stack is set on memory end.
The memory end in this case means the value from BDA address 0x413 (2 bytes, value is
in kilobytes). Therefore the stack address is actually system specific and in general
is at about 610k-640k range. So it is entirely possible that at some point the
loader runtime setup and the loader stack will meet heads up.
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
11.0.1 release did not boot out the box for me, with this patch applied it boots again -- so I can verify it works and fixed my previous problem.