From owner-freebsd-testing@freebsd.org Wed Sep 4 21:36:15 2019 Return-Path: Delivered-To: freebsd-testing@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DA845CE86C for ; Wed, 4 Sep 2019 21:36:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 46Nxvz5TdGz3Qhq for ; Wed, 4 Sep 2019 21:36:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id BC192CE86A; Wed, 4 Sep 2019 21:36:15 +0000 (UTC) Delivered-To: testing@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BBDD2CE869 for ; Wed, 4 Sep 2019 21:36:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46Nxvz4YdRz3Qhp for ; Wed, 4 Sep 2019 21:36:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 8131C21CF3 for ; Wed, 4 Sep 2019 21:36:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x84LaFY8077652 for ; Wed, 4 Sep 2019 21:36:15 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x84LaFPM077651 for testing@freebsd.org; Wed, 4 Sep 2019 21:36:15 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: testing@freebsd.org Subject: [Bug 211924] lib/libc/sys/mmap_test:mmap_truncate_signal fails with SIGSEGV instead of SIGBUS Date: Wed, 04 Sep 2019 21:36:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: tests X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jilles@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: testing@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2019 21:36:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211924 Jilles Tjoelker changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jilles@FreeBSD.org --- Comment #5 from Jilles Tjoelker --- I think FreeBSD is wrong here. Reading the mmap page of SUSv4tc2 XSH 3 Syst= em Interfaces: ] The system shall always zero-fill any partial page at the end of an ] object. Further, the system shall never write out any modified portions ] of the last page of an object which are beyond its end. References ] within the address range starting at pa and continuing for len bytes to ] whole pages following the end of an object shall result in delivery of a ] SIGBUS signal. As far as I understand, SEGV_MAPERR is for the case where no mapping exists= for the address, and SEGV_ACCERR is for the case where the access conflicts with the prot parameter passed to mmap() (PROT_READ/PROT_WRITE/PROT_EXEC). The s= ize of the mapping is equal to the len parameter passed to mmap(), whether the underlying object is that long or not. So this does not mean that the change mentioned in 118304 is completely wro= ng. There is only a problem for pages of the mapped region beyond the end of the object. By the way, the testcase is not POSIX-compliant either, since the aforementioned mmap page also says: ] If the size of the mapped file changes after the call to mmap() as a ] result of some other operation on the mapped file, the effect of ] references to portions of the mapped region that correspond to added or ] removed portions of the file is unspecified. --=20 You are receiving this mail because: You are the assignee for the bug.=