From nobody Fri Mar 21 09:34:16 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZJy2S3zPfz5qwpf for ; Fri, 21 Mar 2025 09:34:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZJy2R54nqz3XVV; Fri, 21 Mar 2025 09:34:23 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-224019ad9edso41773495ad.1; Fri, 21 Mar 2025 02:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742549662; x=1743154462; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=pohX0M+Dl1V9pnlGNg5Og1gkiK1wLGVaoFgSqq58v3Y=; b=M3EzMgUorTRRI78khtbIz9R91LdCBF4MNWQZ2pYhUnAF7n6myTgNAkpp/8nGuVhUdB ljXEY0srqvKYCqs+HsmF0djrQcpJ4taD9jJAzj7Xe1/WtIc92j9vsT8FgZq0/Mt1ydWI pga4mi+Fk0AmAhyNImrDhgLBoh8bDE+SB6jCWd9iywvAvxMpAXJ3IoceVdhAcWebBk1t KOBfKFq72/8O99VeV5Hb+JshTBxP2YjBoFkqRc/dtfpVslQL6JR93YSqguqjBVnzbs3i 79mx0rInly3TQ4k3bcxVJDuHAUq+NNC+ZfzmxkT/CE5kerGX+hQLOvmPkjCHAKs3NECJ zCFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742549662; x=1743154462; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pohX0M+Dl1V9pnlGNg5Og1gkiK1wLGVaoFgSqq58v3Y=; b=vRN4BtH6Qe65qL1l5chBIhBFggzBjPK1OqUvlccx8CCGscPypzlzkCCe5Um2VIq2EQ nLrg09ab7wPwZTpWdhen3u7+8CgN9ObrhjcVMbAAxHY9+/k7T2VZiH6L2kxdJouBSBy8 juAMq2JRIHIFO1Zp3zaqvl4Ihy4UFhhDci1D1+s2+7bxxCQT2Ff3EU4F3Tv6pApZqOTP 4+rDWUXR+R5MXXEH5PG5aZYoWbAC+KBxfrcNa4RYcD0MNB6ctp1hGJn1FeXEGqcEvCAW KdS2e1ehfMfOcy2SaPdL+VmoBB629EKL+S2KMmGGOTzYu7MnKPmgU2TxG91yXK0y4NkJ WCOA== X-Forwarded-Encrypted: i=1; AJvYcCV4BddW+ihz0tVnGN3lUDE5JFf0ropS74qndhkJXbMUxUMLp6/ljaVEEv+vdvABQbcCVBGq@freebsd.org, AJvYcCV7WbY0veOuqfYAT5v2NF7CtdOo4KFJ5wEnihtHBSCCPpOALnz2pj6ngsMAk4XgNfSQ9CzKeNl8@freebsd.org, AJvYcCWSSl/C7XHCWGD7EUtN/RZwcHdK8CNY5/7iHlgGiFAlM+PkywuGFPsNk882sEmfwFJ7Vcii@freebsd.org X-Gm-Message-State: AOJu0Yx0fICvuI45enrwgC55J/tq9+E7UuduRTqnfOYF1j52WKyoi/K5 7NBD9AhDAYSZE/TOiDFKgwueSYUhnoIMNn9rlYy+XwKP5+2/Y88OfuLze6PEnyc= X-Gm-Gg: ASbGncuwgWOtot5Rue633QxFsVaDFNr22PEjABPTD2eQCBJUZoS4e2XmXZOMnMUfbqP fyafrJMz5SrmDeTqcubSn5QIEgdEopmz6qaRamFthNcZcAoBbW01/YoOOFB30Gl9g4J8PtLtEq7 LxqO75TqvNTwEXv1ar//7yvgSofskQWfWu2CCYc+i+bxfEX00PWEVmVjPFB/iPLzQNujpzVfivM wxjyrYFdEe0j6FYAWhh5nEe4Y13MXmxPHg9QVh6FrjlnFpUCxxpH8tBIDZ/HiWUpnGY80zvtP5k rJ6ygiEmTDT8weObdpa8+DVVHNBq05KH+sBUoFP4HuZ8whO8kRFbS06ggh7YOYQOaNs= X-Google-Smtp-Source: AGHT+IHcmfLfs87Bhl2BCKMtIaZX74WacHiT59eJ3KfXad5Iwc4V4OooQnFKadGIAz+8YCiROa7vcQ== X-Received: by 2002:a17:902:d54a:b0:224:24d3:6103 with SMTP id d9443c01a7336-22780e0327amr57755635ad.35.1742549661753; Fri, 21 Mar 2025 02:34:21 -0700 (PDT) Received: from framework (M106185150005.v4.enabler.ne.jp. [106.185.150.5]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-227811f6f88sm11910995ad.237.2025.03.21.02.34.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Mar 2025 02:34:21 -0700 (PDT) Date: Fri, 21 Mar 2025 05:34:16 -0400 From: Mark Johnston To: Gleb Smirnoff Cc: "Bjoern A. Zeeb" , David Wolfskill , current@freebsd.org, kib@freebsd.org, jhb@freebsd.org Subject: Re: Possible video driver issue after main-n275966-d2a55e6a9348 -> main-n275975-5963423232e8 Message-ID: References: <01qqq28n-p1s3-n82q-9n1s-7o900ro5n62q@SerrOFQ.bet> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4ZJy2R54nqz3XVV X-Spamd-Bar: ---- On Fri, Mar 21, 2025 at 01:56:01AM -0700, Gleb Smirnoff wrote: > On Thu, Mar 20, 2025 at 07:52:19PM +0000, Bjoern A. Zeeb wrote: > B> He's hitting a ... somewhere in i915kms.ko (here's the two instances I > B> have): > B> REDZONE: Buffer underflow detected. 16 bytes corrupted before 0xfffffe089bc65000 (262148 bytes allocated). > B> REDZONE: Buffer underflow detected. 16 bytes corrupted before 0xfffffe08a7e70000 (262148 bytes allocated). > > I looked a bit into the problem and it actually seems very trivial to me. > Please re-check my observations. > > A contigmalloc(9) allocation doesn't get redzone protection, see kern_malloc.c. > But free(9) always does contigmalloc check. This makes deprecation of > contigfree(9) incompatible with redzone(9). And looks like > 19df0c5abcb9d4e951e610b6de98d4d8a00bd5f9 is our first bump into this sad fact. Can we not just add redzone padding to contigmalloc() allocations? Compile-tested patch below: diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c index b1347b15e651..0b76e633b04a 100644 --- a/sys/kern/kern_malloc.c +++ b/sys/kern/kern_malloc.c @@ -477,11 +477,18 @@ contigmalloc_size(uma_slab_t slab) } void * -contigmalloc(unsigned long size, struct malloc_type *type, int flags, +contigmalloc(unsigned long osize, struct malloc_type *type, int flags, vm_paddr_t low, vm_paddr_t high, unsigned long alignment, vm_paddr_t boundary) { void *ret; + unsigned long size; + +#ifdef DEBUG_REDZONE + size = redzone_size_ntor(osize); +#else + size = osize; +#endif ret = (void *)kmem_alloc_contig(size, flags, low, high, alignment, boundary, VM_MEMATTR_DEFAULT); @@ -489,16 +496,26 @@ contigmalloc(unsigned long size, struct malloc_type *type, int flags, /* Use low bits unused for slab pointers. */ vsetzoneslab((uintptr_t)ret, NULL, CONTIG_MALLOC_SLAB(size)); malloc_type_allocated(type, round_page(size)); +#ifdef DEBUG_REDZONE + ret = redzone_setup(ret, osize); +#endif } return (ret); } void * -contigmalloc_domainset(unsigned long size, struct malloc_type *type, +contigmalloc_domainset(unsigned long osize, struct malloc_type *type, struct domainset *ds, int flags, vm_paddr_t low, vm_paddr_t high, unsigned long alignment, vm_paddr_t boundary) { void *ret; + unsigned long size; + +#ifdef DEBUG_REDZONE + size = redzone_size_ntor(osize); +#else + size = osize; +#endif ret = (void *)kmem_alloc_contig_domainset(ds, size, flags, low, high, alignment, boundary, VM_MEMATTR_DEFAULT); @@ -506,6 +523,9 @@ contigmalloc_domainset(unsigned long size, struct malloc_type *type, /* Use low bits unused for slab pointers. */ vsetzoneslab((uintptr_t)ret, NULL, CONTIG_MALLOC_SLAB(size)); malloc_type_allocated(type, round_page(size)); +#ifdef DEBUG_REDZONE + ret = redzone_setup(ret, osize); +#endif } return (ret); }