From nobody Fri Mar 21 17:35:50 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 4ZK8k20Vgrz5rT2C for ; Fri, 21 Mar 2025 17:35:54 +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 4ZK8k16xdCz3NyS; Fri, 21 Mar 2025 17:35:53 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1742578554; 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=Z/uo218lzS4z9U3XSVv+8kIif1aw+D31OYWS48JkPLM=; b=ZLi7Sqr8Uqjc9sjMQa1L+9W1++jdc6LZsC9CYIaXara5vbeu6FMFS3c51EVfRvdRXAfPTe 8PQexRvKZf3X+XFcuI60rQUaoVVE0AI3oZT6x2KiQJUT8/bokEoTOiqE9uH3sAwQbULzvr DuSqqJKwacAmpFM1wCKNo+2/wLk23ojFmx5UP0IAkefeeV3D4MLBBU5y3mKbjCrBvKbqao 83bwdlFnxKz9d92bwaKL+XljACFyl7gtHlC0E/JcjVgShMX5yKVJJGVJ20p+cSz5/bRDk4 rjhA2FSUKk2FpSichlPVnI1GbLM0tCT3BhbwwD601DCSvUkK1GbTGiE6NNIgTg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1742578554; a=rsa-sha256; cv=none; b=BMOzXXbOmqt8MTyS4Syu/jB/P0JfiEVQdU5rEQmDxxwCjUe69M5usA5aNIqjztJdJUKrup 3bNJNGhkN3wu3vb7BGEfcH9jTh4z7zM3zZAHInK6DnfEYLOypQkkqNommQSHBioNFEBpn0 1OEGjk1ZCbyoDV5y6CZDG59KB2GJfLdCThi7vmkcZlLFvKAYD2tx14DrwA+53wzlZh6x/h 6QAsgAUBZhpvLCWr4tTGuSmjTcaY3ocQ7Dyl8zCB2IEx1J/lhbHAYsg4iNrW9+W2lIeWdd I6cFrr99XAwM9C72mKsIqLuKoJ5I0l7wWh4qUpZxHkn4H+peDSbNRgxFqyKyyw== 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=1742578554; 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=Z/uo218lzS4z9U3XSVv+8kIif1aw+D31OYWS48JkPLM=; b=b0Sn7a7hDPBaqFd15RwczRk+JMmFgKuYsaFOV32bh09TQ/wjnH2IXDc9lq49hGlkLsKgO3 mzKoL7P6VnN5teB/dj4MxN5NtotD7RXB9huPeBEodlHdsaURbUI9fZsOd6XcLNghR+/T+1 p1L9EG5PdtuO+THLlu4yH+taJqZAgtxm4/CHhFXWuESUtRx14obnhMnQ7zCl7YQfGJHHg5 SzLyCu6Ondb1XXjT9kgmirVK0TDOPJi9QAKaM0mdGRbVLVseMjnyc2Dx15TE1PUR7B8nZ+ GSdVPfejV2aMQiu935WNdpgIhXqRfYsjMz+sFXb1y9ggxHoarVxmAHWYVHIjFg== 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 4ZK8k11KNnztq9; Fri, 21 Mar 2025 17:35:53 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Fri, 21 Mar 2025 10:35:50 -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 09:55:10AM -0400, Mark Johnston wrote: M> > I was about to suggest that, but was afraid it is too naive :) But M> > if that works, why not? We probably should document that for M> > contigmalloc() the redzone would provide protection of the virtual M> > space, but not the physical. M> M> I'm not sure what you mean by this? As implemented, the patch M> effectively rounds up the allocation size, so the redzone will also be M> physically contiguous. Though, I see now that this will result in an M> non-page-aligned allocation, which callers of contigmalloc() might M> not tolerate... M> M> Actually, for malloc_large() and contigmalloc() allocations it's M> probably a bit easier to just provide guard pages around the M> allocation, like we do for kernel stacks. That is, if the caller asks M> for N pages, then allocate N+2 pages of virtual address space and back M> pages [1, N] with physical memory. Then any overflow will trap at the M> site of the overflow, which is probably more useful than what M> redzone(9). Actually, KASAN provides the same checking, but currently M> we don't pad allocations when KASAN is enabled. M> M> > M> Compile-tested patch below: M> > M> > Why do you increase the size with redzone_size_ntor() before passing M> > it to redzone_setup()? Other calls to redzone_setup() don't do that. M> > My reading is that argument to redzone_setup() shall be exactly the M> > amount of bytes requested by the malloc KPI user. If you pass M> > increased value, the canaries will be written after a gap. M> M> I pass "osize", the original allocation size, to redzone_setup(). I see the point, with growing the original size you also guarantee red zone both in physical and virtual memory. Got it, thanks! -- Gleb Smirnoff