From owner-freebsd-mips@freebsd.org Sun Nov 13 20:55:57 2016 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B1E7C407B0 for ; Sun, 13 Nov 2016 20:55:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61E221300 for ; Sun, 13 Nov 2016 20:55:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x243.google.com with SMTP id b123so8804558itb.2 for ; Sun, 13 Nov 2016 12:55:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=QZU1yBd7e4SoNrWVHBDXZ+ETgRmQDdrC1t2HZSGiGWM=; b=go6buCaNh5vnkDUR+ECDW3KRMgPDaf9Gvtgz7l7GvT1qLNKk6EzLMEwlnZ1jH4wj2e am5oLb4JgLvZWF6sjHPIkZYw67UDguFxRm/TDpXTLuhJgnOBzuJHSolGrM5uYVPSFm8+ D4Cd+2jRNRprnm2prm0YU4R9/iXyrEfArolhdxmfQgNAImSQmpEi9rxlH7rGVUPCTp79 pxhDfuAJ+StnCCCdKatNOoDfeldz3EcCgLkZilAk25edl/yBz/XB1vK55D3PkrzSAc2q rFi5dSlnf1dvquBtkGhQR0fg263i9QGgLyVpwA/V0a/rOxwkRqDToruwpsrov5sOXN/a h+lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=QZU1yBd7e4SoNrWVHBDXZ+ETgRmQDdrC1t2HZSGiGWM=; b=NBVrELQnygtioCfx1VDvuvXjrhpumsI2JELq4oZLHAXSoYkRTGw0378u6SFPInD7Up oCE9Ol/Vg5d0y9s7A/1UwZdK/FSmKJwMBCJ8HVgoeAXi/oX5asZ9AD+MetvnOna6BOQ0 peneWz7cRymqQ2zTlKaM44Bng6qdUv+lifSNpUTFW5R4cMN64rCoOAgjN59Ih15TWUw7 UWYfw75OVDmY1RfzBMaY3y/gIIE9hqaIkXwHRz8OzIOIASpOdBNiKhTjQ0jVGpgOB1Vy zeZnGFYx+eN5UbXkGyGO2Br/BV8CzpRVmUk5DiajV+vA6qxqguBAWFAGMUG0Uz3pkeTL YZbA== X-Gm-Message-State: ABUngvcsNLAJWyLeRLMXIE+G6RlTJx7tFQ2zDaLDmpMwMUTB2jaTRriHRwliuhaUSfhgTQ== X-Received: by 10.36.39.85 with SMTP id g82mr4512327ita.52.1479070556640; Sun, 13 Nov 2016 12:55:56 -0800 (PST) Received: from mac-wired.nflx.bsdimp.com (50-253-99-174-static.hfc.comcastbusiness.net. [50.253.99.174]) by smtp.gmail.com with ESMTPSA id o19sm8002551ito.16.2016.11.13.12.55.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 13 Nov 2016 12:55:55 -0800 (PST) Subject: Re: svn commit: r307626 - head/sys/ufs/ffs Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F0650D9E-757D-4745-AAE3-E86EB3622C11"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Warner Losh In-Reply-To: <20161113190344.GM54029@kib.kiev.ua> Date: Sun, 13 Nov 2016 13:55:54 -0700 Cc: Adrian Chadd , Juli Mallett , Warner Losh , "freebsd-mips@freebsd.org" Message-Id: <50FE3B7E-8FA4-47DC-BC45-EE75B9FAFC0F@bsdimp.com> References: <20161113065851.GD54029@kib.kiev.ua> <20161113071911.GF54029@kib.kiev.ua> <20161113075557.GH54029@kib.kiev.ua> <71C512CD-0FB6-40D8-B46C-30467A245693@bsdimp.com> <20161113161548.GK54029@kib.kiev.ua> <20161113190344.GM54029@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 20:55:57 -0000 --Apple-Mail=_F0650D9E-757D-4745-AAE3-E86EB3622C11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 13, 2016, at 12:03 PM, Konstantin Belousov = wrote: >=20 > On Sun, Nov 13, 2016 at 10:50:19AM -0800, Adrian Chadd wrote: >> Ok, so after talking with others, my questions are: >>=20 >> * I thought our VM was supposed to not be doing double mapping like >> this. warner's comment on irc was: >>=20 >> =3D=3D=3D >> 13:39 < bsdimp> adrian the VM isn't supposed to do it at all. >> 13:39 < bsdimp> adrian that is, double map on purpose. >> 13:40 < bsdimp> though there's some exceptions to the rule >> 13:40 < bsdimp> since kernel mappings go away in userland, and >> userland doesn't execute while you're in kernel mode, you can do the >> flushing >> game in busdma to prevent most issues. >> 13:41 < bsdimp> which is what we do. Generally, though, our VM = doesn't >> do it in-kernel. >> =3D=3D=3D >>=20 >> * is this still the case? or are there places in the VM where we are = doing this? >> * can we introduce a machdep/pmap capability check to see if aliasing >> is allowed and if so, turn this feature on? > This never was the case, and never will. VM establishes mappings as > requested by the userspace and kernel, and n-times mapping for the = same > page is always legitimate. It is the pmap duty to handle that. User space N way mapping is rare. Can you show an actual example of when = this is commonly done? Or being done in init(8)? > If you cared to read my previous mail, I already explained that = besides > the userspace asking for n-mapping, there is at least buffer cache = which > also maps the same page into KVA, from the times when unified buffer > cache/page cache was introduced. Same is true for n-mapping of shared > anon pages. KVA mapping is different, since that mapping goes away. And generally, = the KVA mappings aren=E2=80=99t active while user land mappings are = active. Here =E2=80=98active=E2=80=99 means can change the cache. When = the kernel is executing on these single core 32-bit mips boxes, user = space isn=E2=80=99t creating traffic to the pages. Also, KVA mappings = tend to be for pages that we don=E2=80=99t actually touch in the kernel = once the I/O is complete. This is true for data pages in files. It may = not be true for in-kernel meta-data pages, and that might have changed = with your commit (I haven=E2=80=99t looked in enough detail to know). But that still begs the question: why is the fault address 0 in the = original crash report. If we=E2=80=99re doing multiple mappings, and = that=E2=80=99s creating a cache coherency problem because there=E2=80=99s = two copies of dirty cache data, how does that end up with us doing a = NULL dereference? That=E2=80=99s the part that I=E2=80=99m having = trouble understanding and I worry that arguing over the exact parameters = of the VM mapping issues might be distracting us from a credible theory, = with a specific sequence of events that gets us here. It looks like we use the direct map in kernel for addresses < 256MB. = KSEG0 covers a lot of sins. NetBSD has code to cope with congruent mappings that cause problems. = These look to be only on LONGSOON and MIPS3 processors with mips32 and = newer not affected by it. MIPS3 has VCE exceptions for Instructions and = Data and NetBSD has code there to cope. It also maps the pages uncached = until the multiple mappings go away. The other code it has to cope is = effectively disabled when not on these processors. It is a twisty maze = of #ifdefs, though, so maybe I=E2=80=99m missing something. It does = disable the socket page loaning code as well when there=E2=80=99s = issues. So, we=E2=80=99re back to the basic question: why does this change cause = the observed behavior, exactly? >> Adding a pmap capability and turning it on for say, i386/amd64/arm64 >> would allow for this new feature as well as the previous behaviour on >> older platforms. >>=20 >> I don't think I have the time to fix mips pmap to support this new >> feature, so if you want to turn it on for all features, we should >> really fix/test pmap on said platforms first. > This is not a new feature, this is the old bug on that platform. This sort of argument is pointless: the code does something new, and the = current code doesn=E2=80=99t support it. It=E2=80=99s that simple. = Trying to label new bug / old bug, etc is pointless. It=E2=80=99s a bug, = and it=E2=80=99s gotta get fixed. It isn=E2=80=99t clear to me it=E2=80=99= s even understood why things are happening, so even the old / new finger = pointing is premature given we don=E2=80=99t have a definitive cause, = just a theory. Warner >> Final comment: I'd really like to see a sort of "tested on" for = things >> like this, because it's not clear which platforms/architectures it = was >> tested on. --Apple-Mail=_F0650D9E-757D-4745-AAE3-E86EB3622C11 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYKNNaAAoJEGwc0Sh9sBEAwrcP/jZwGTBPLiClMsdw/oQYmTK3 2ch2RafvMzVotVTKaRLKapRTYgShEkfSYudRdbQcSjH/p84xluPk14aaioIjJTfE 5jJaAmwKXcxK93oQpVmbW3wDFKY6zl/IeBwVW76/RP2XZkveu/3Lj3ubAUg1O+Jo FFN6gzcgmLYS1ik+4GcRWi4r12BtbwGqITKei0CyWrDGax3aIbmJ3Px5pB+oVa2K t5ONP9GrFUVvyNIof+lSoYiy2GmRK1Y+LovMgyu6lIU8S1wWJdiljuAMY9Al+7fU U/QMcJx4jMkg2HrJJtqwcpaTDCFP24LDgNW+p/DNvyfmllQBjLspptTeflZB0LmB FTNcWEZdSiydPKEhhClXMxbDhSaNQeqmLH+uXhgfgx2AMOQRJIX+GS5jgsrD+WWn +Z/Gi0QkwAgRE5HsCKQxnxf2nvirvosM9LMMDkNGFVfYZIrB6+4saH+On6SewGcB iE8bRplVIvYxqVuytgFdgWRX5k4wg9NrtG37MQ5h+5mhzgvMuSKdV7UiWxHbpSGN MwsP2+GOqKj3p1hFxrjGPQp/UxrUVUejI2tj3d2kbIdJPGPH/mslBJbI16hum3X1 rXfieADkateIhQQjkQIGBIxsnzT9XMUOLzNLOoPlWhr8tmkw0naMYiUQ2r+5IBc+ 2uCcj0enMhkaWPdS8slF =Fczy -----END PGP SIGNATURE----- --Apple-Mail=_F0650D9E-757D-4745-AAE3-E86EB3622C11--