From nobody Fri Mar 21 09:50:58 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 4ZJyPd5H9hz5qy2j for ; Fri, 21 Mar 2025 09:51:01 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZJyPd3xMdz3dgY; Fri, 21 Mar 2025 09:51:01 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742550661; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+t08LD5CmqD/AA503jLRugbCzWmMXh82K16jm+DwN1U=; b=aVG/iXHo/eVWOgdvPxTwEalgy7TFuToaB3xlv2iD0V4gjZ4pDj1m2anokvJViasOseN0kJ A0K7l0BC8tGa3WEXTtqc154Zxxz3+UQYfvxthMJHlhPBULGKlY+gAFNvRANRz1wPpuWwK5 /VwYo2a6F7UcEUPTKGR+0+gzwGxQHjHgpBYHJcutuJnJRrnRC5ZDQ9UlaaISTQ6HfWa5ta GhSDg4tM4xEo6py7fRacvq6/ayGx0EpDKPfXib9rgPLgSQQ3nR9POfYnXZ7gdUlXRclDzC mlT+HK1UNUlVR09vU1koiTnSdGiNM19p/JVG07jxvqkEqS92CGV5Avg3g4Yv1g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1742550661; a=rsa-sha256; cv=none; b=WoxXp1FXrtf7RC2EARsz8XbzAfwiXrVmXy23JsmZJlXftSHQE11P/Xem1F5rZJjuXWkeJW W5zWMxtt+pBpRuaaU3d/+etEjqZiMJn7X2PEfJuV6IES2Rsi9wqeDI8yrhsTvzd4ElA3jD 2V7VcnsvV2pe31uQCG9BxtYvtng7CNkUI53EYKe01R0FZMqAjCHiwuVYjdkcDVyOKX/iWo 1LoWQPQsdG/4PD+2pWOTX3lG9u4v6z1xKTsjFvGdLGKuopZDLgfzTx+1u9Gu+Xgn68t6Xk VujLolLuof/br5QF6BDTf+iY3PS9rs8xYtoWuWDVvQys67y7+rzhZLDc4ZKYXA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742550661; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+t08LD5CmqD/AA503jLRugbCzWmMXh82K16jm+DwN1U=; b=ahwUQCQHhDFaEM84sLEk6Cm65AzLcWmD0RmCWLGoGRHyh1WR7xP7WeNtatJREQD8ZSNdkP A8tdGl9vtNg5q4Y7wnCLFbTCffkprnkt6RiWc5seFOd3NDo51TeQq7GUAWK/TRAlHeWSwW ZONXg5P0VINHtcyfo4RrHFyNM2jK4UKmoV7Pp8z4dnbaLZNt6qC6Z5hUN7N7OP3CVjEv/x n4k0Sk0MBOJwhQTEbf3wQLeKWGrs+Duq+gE/7Tt73L3kqa7mMltJ+aqqHUB7tbsF8XW1Ne ncy3P1RZg1gRG921tfkeNv4JYudY+Vp/VZcJz8bhNUjUGaHFVzfRDo5mxoFK8Q== Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZJyPc1bJVzZQN; Fri, 21 Mar 2025 09:51:00 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Fri, 21 Mar 2025 02:50:58 -0700 From: Gleb Smirnoff To: Mark Johnston 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: 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 Smirnoff