On Sat, Mar 22, 2025 at 12:04:25AM -0700, Gleb Smirnoff wrote: > On Fri, Mar 21, 2025 at 11:13:53AM -0700, David Wolfskill wrote: > D> OK; I started on my secondary laptop (Dell Precision 7520) after having > D> updated the "head" slice to main-n276038-6f6c07813b38 earlier today (and > D> verifying that the initial concern -- that it doesn't appear to complete > D> the transition to graphics mode and appears to emulate a power-consuming > D> brick) still occurred), I copied that slice to a different one (slice 2) > D> and booted from it (using a kernel from a week ago, > D> main-n275966-d2a55e6a9348). > D> > D> I then applied Mark's patch (cleanly; no issues), then > D> rebuilt/installed the kernel, then rebooted... and stuff seems to work; > D> I get the xdm login banner Just Fine (and I can ssh into it normally). > > Thanks, David! > > Mark, can you please push your patch before the stabweek cutoff > that happens early Monday?
Sure, done: https://cgit.freebsd.org/src/commit/?id=74361d693aec892b01c1553bda7176f8d341b2ff BTW, in the longer term I think redzone (and maybe memguard(9)) should eventually go away in favour of KASAN, which can catch the same bugs, and more usefully at that. Right now KASAN's integration into UMA is not as good as it should be in that it doesn't explicitly insert redzones around each allocation; it will however mark redzones if they arise naturally (e.g., when malloc(9)ing 24 bytes you'd get a 32-byte object, and an access beyond the 24 bytes would be a sanitizer violation). However, that should be straightforward to fix. Then, you'd get checking not just for malloc(9) allocations, but for everything from UMA. And, overflows would be caught at the point where they actually occur.
