Date: Fri, 21 Mar 2025 02:50:58 -0700 From: Gleb Smirnoff <glebius@freebsd.org> To: Mark Johnston <markj@freebsd.org> Cc: "Bjoern A. Zeeb" <bz@freebsd.org>, David Wolfskill <david@catwhisker.org>, current@freebsd.org, kib@freebsd.org, jhb@freebsd.org Subject: Re: Possible video driver issue after main-n275966-d2a55e6a9348 -> main-n275975-5963423232e8 Message-ID: <Z902glkq79hlB0N4@cell.glebi.us> In-Reply-To: <Z90ymKjH18bkj-nc@framework> References: <Z9WJsC4FcyHQkME-@albert.catwhisker.org> <Z9jRXIe5cNnlRfhU@albert.catwhisker.org> <01qqq28n-p1s3-n82q-9n1s-7o900ro5n62q@SerrOFQ.bet> <Z9l7vF_gt57AyzDC@albert.catwhisker.org> <Z9mN10KGg_pQXbly@albert.catwhisker.org> <Z9oBNVH7l8QKHSC3@cell.glebi.us> <rp062q43-939r-3o94-7s04-06s8669nsq1s@serrofq.bet> <Z90poZ960b6jCXqn@cell.glebi.us> <Z90ymKjH18bkj-nc@framework>
index | next in thread | previous in thread | raw e-mail
On Fri, Mar 21, 2025 at 05:34:16AM -0400, Mark Johnston wrote: M> On Fri, Mar 21, 2025 at 01:56:01AM -0700, Gleb Smirnoff wrote: M> > On Thu, Mar 20, 2025 at 07:52:19PM +0000, Bjoern A. Zeeb wrote: M> > B> He's hitting a ... somewhere in i915kms.ko (here's the two instances I M> > B> have): M> > B> REDZONE: Buffer underflow detected. 16 bytes corrupted before 0xfffffe089bc65000 (262148 bytes allocated). M> > B> REDZONE: Buffer underflow detected. 16 bytes corrupted before 0xfffffe08a7e70000 (262148 bytes allocated). M> > M> > I looked a bit into the problem and it actually seems very trivial to me. M> > Please re-check my observations. M> > M> > A contigmalloc(9) allocation doesn't get redzone protection, see kern_malloc.c. M> > But free(9) always does contigmalloc check. This makes deprecation of M> > contigfree(9) incompatible with redzone(9). And looks like M> > 19df0c5abcb9d4e951e610b6de98d4d8a00bd5f9 is our first bump into this sad fact. M> M> Can we not just add redzone padding to contigmalloc() allocations? I was about to suggest that, but was afraid it is too naive :) But if that works, why not? We probably should document that for contigmalloc() the redzone would provide protection of the virtual space, but not the physical. M> Compile-tested patch below: Why do you increase the size with redzone_size_ntor() before passing it to redzone_setup()? Other calls to redzone_setup() don't do that. My reading is that argument to redzone_setup() shall be exactly the amount of bytes requested by the malloc KPI user. If you pass increased value, the canaries will be written after a gap. -- Gleb Smirnoffhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Z902glkq79hlB0N4>