From owner-svn-src-all@freebsd.org Thu Jun 14 22:23:40 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F7B71010082; Thu, 14 Jun 2018 22:23:40 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3FE9686B62; Thu, 14 Jun 2018 22:23:38 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 6510e4af; Fri, 15 Jun 2018 00:23:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=l2TMH0sxs/ZY8MsaPUYIZTpv3yo=; b=B9INkoxub836FsAqkVopgTsEtxY0 VIcyEmCX3x5CkZhi7NeM9tV9QVsd8ZyzyvPexpdLuk/WIX5jtiebEGctcNRnHjdi lgrkX6NU7GLDBwdtoR35KxFR6ZVQRfo4MLXglxzcZlHILeZAfOETQLHkqix5SodA WiwoNjwkTWGU2tA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=XeYRVSHPRbiYPp95OA/+ZTcYi9yn8p9DS6vg2DgZEQhe0m2UvEcloTkx icoiWi/IzQrVgtM2AIAp7jnGwrAj2I9KQKDo4GdRISRSa84g4DDZdYggr7+QFxuE HWRXMTrQaM2swVJTN0Y2k3hmLBzum3mcXrwTv6mu5a+295poe30= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 7e894d55 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 15 Jun 2018 00:23:36 +0200 (CEST) Date: Fri, 15 Jun 2018 00:23:36 +0200 From: Emmanuel Vadot To: "Jonathan T. Looney" Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r335068 - in head: share/man/man9 sys/amd64/amd64 sys/i386/i386 sys/kern sys/net sys/sys sys/vm Message-Id: <20180615002336.fcb966efe812cd60af59f68f@bidouilliste.com> In-Reply-To: <201806131704.w5DH4gLv048134@repo.freebsd.org> References: <201806131704.w5DH4gLv048134@repo.freebsd.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 22:23:40 -0000 Hi Jonathan, On Wed, 13 Jun 2018 17:04:42 +0000 (UTC) "Jonathan T. Looney" wrote: > Author: jtl > Date: Wed Jun 13 17:04:41 2018 > New Revision: 335068 > URL: https://svnweb.freebsd.org/changeset/base/335068 > > Log: > Make UMA and malloc(9) return non-executable memory in most cases. > > Most kernel memory that is allocated after boot does not need to be > executable. There are a few exceptions. For example, kernel modules > do need executable memory, but they don't use UMA or malloc(9). The > BPF JIT compiler also needs executable memory and did use malloc(9) > until r317072. > > (Note that a side effect of r316767 was that the "small allocation" > path in UMA on amd64 already returned non-executable memory. This > meant that some calls to malloc(9) or the UMA zone(9) allocator could > return executable memory, while others could return non-executable > memory. This change makes the behavior consistent.) > > This change makes malloc(9) return non-executable memory unless the new > M_EXEC flag is specified. After this change, the UMA zone(9) allocator > will always return non-executable memory, and a KASSERT will catch > attempts to use the M_EXEC flag to allocate executable memory using > uma_zalloc() or its variants. > > Allocations that do need executable memory have various choices. They > may use the M_EXEC flag to malloc(9), or they may use a different VM > interfact to obtain executable pages. > > Now that malloc(9) again allows executable allocations, this change also > reverts most of r317072. > > PR: 228927 > Reviewed by: alc, kib, markj, jhb (previous version) > Sponsored by: Netflix > Differential Revision: https://reviews.freebsd.org/D15691 This brake module loading on armv7 and arm64 kevans log on armv7 : https://gist.github.com/kevans91/d0ffcd6c94a0e4cdfdc5433612fce2e8 mine on arm64 : http://dpaste.com/3VVBZDV Do you have any idea what could cause that ? Is any MD stuff is missing for those arches ? Thanks, -- Emmanuel Vadot