From owner-freebsd-arch@freebsd.org Mon Aug 10 14:30:35 2015 Return-Path: Delivered-To: freebsd-arch@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 49C6099EB84 for ; Mon, 10 Aug 2015 14:30:35 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2DED08C7 for ; Mon, 10 Aug 2015 14:30:35 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2CF8199EB83; Mon, 10 Aug 2015 14:30:35 +0000 (UTC) Delivered-To: arch@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 13B2299EB82 for ; Mon, 10 Aug 2015 14:30:35 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A2A978C4; Mon, 10 Aug 2015 14:30:33 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.15.2/8.15.2) with ESMTPS id t7AEUVhW077586 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Aug 2015 17:30:31 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.15.2/8.15.2/Submit) id t7AEUVtU077585; Mon, 10 Aug 2015 17:30:31 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 10 Aug 2015 17:30:31 +0300 From: Gleb Smirnoff To: Konstantin Belousov Cc: arch@FreeBSD.org, alc@freebsd.org Subject: Re: more strict KPI for vm_pager_get_pages() Message-ID: <20150810143031.GF75813@glebius.int.ru> References: <20150430142408.GS546@nginx.com> <20150807133844.GS889@FreeBSD.org> <20150808084121.GX2072@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150808084121.GX2072@kib.kiev.ua> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 14:30:35 -0000 Konstantin, On Sat, Aug 08, 2015 at 11:41:21AM +0300, Konstantin Belousov wrote: K> > 1) There could be a user of KPI who would be fine with partial success. K> > K> > My answer: right now there is none, and if one emerges, the code can K> > be easily adopted to return VM_PAGER_ERROR, but still mark validated K> > pages as valid. The user of KPI then can scan the array and take valid K> > pages. So, the patch doesn't put any obstacles on appearance of such K> > user. K> The vm_fault.c is already fine with the partial success, it only cares K> that the requested page was validated and no error from pager is K> returned. vm_fault.c can be easily adopted to partial success, but I don't see a good reason to do this, since right now no pager does return partial success. K> > 2) Filesystems can do short reads by design, and thus fail to validate K> > the entire array. K> > K> > My answer: yes, that's true. By design NFS, SMBFS and FUSE should be K> > able to return short reads. However, the VOP_GETPAGES methods for all K> > three FSes right now do not have any code that would support that. So, K> > it looks like there is an open issue with these filesystems, not related K> > to my patch. When this issue is addressed in any of aforementioned FSes, K> > the VOP_GETPAGES should be fixed to do several I/Os in case of short K> > reads. K> K> And this is a bug in the networking filesystems (most likely). Rick was K> asked about NFS, but he did not responded. You are proposing to make the K> bug a part of the interface. Yes, this is likely a bug in current filesystems. Note that the bug is already here, and it is not a part of my patch. Also note that the bug has no evidence, we only modeled it in a thought experiment. And I don't propose to make a bug part of interface. I propose that if FS maintainers find time to analyze this issue, then they should fix it, hiding internal peculiarities of their FS into its implementation, instead of escalating it up to the pager interface. K> I object against this change. It is wrong philosophically, and it K> encodes the incomplete or accidental behaviour of several filesystems at K> the interface level. I object to your objection. The current KPI is wrong philosophically. It is wrong that caller passes an array of locked entities (busied pages) and gets partially unlocked array on return. This doesn't allow to write robust code safe from race conditions without introducting workarounds. K> In fact, you are taking some rather secondary feature of the current K> interface, that the non-requested pages are made busy for the duration K> of the paging request, to the level of the fundamental property (would K> the non-mreq pages be not busied, proposed change immediately causes K> applications segfault on parallel file truncation, or makes user data K> corrupted, for example). I really don't get this paragraph. "would the non-mreq pages be not busied" -- but this isn't the case. They are busied and this is intentional. K> All this rototilling is because you do not want to code the proper FSA K> in your reworked sendfile patch. You see, a proper FSA can be built around even more brain damaged interface. Alternatively, I can just say that if the array KPI is so fragile, I will do pages one by one in a busy loop. So, yes, the "problem" is solvable without touching KPI, but the solution isn't right one. -- Totus tuus, Glebius. From owner-freebsd-arch@freebsd.org Wed Aug 12 18:20:10 2015 Return-Path: Delivered-To: freebsd-arch@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 9726A9A083A for ; Wed, 12 Aug 2015 18:20:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7482FD4D for ; Wed, 12 Aug 2015 18:20:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 81DA5B97F for ; Wed, 12 Aug 2015 14:20:09 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Supporting cross-debugging vmcores in libkvm (Testing needed) Date: Wed, 12 Aug 2015 10:50:20 -0700 Message-ID: <5166205.rtMjEmhvmo@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <3121152.ujdxFEovO3@ralph.baldwin.cx> References: <3121152.ujdxFEovO3@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 12 Aug 2015 14:20:09 -0400 (EDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 18:20:10 -0000 On Tuesday, August 04, 2015 10:56:09 AM John Baldwin wrote: > Many debuggers (recent gdb and lldb) support cross-architecture debugging > just fine. My current WIP port of kgdb to gdb7 supports cross-debugging for > remote targets already, but I wanted it to also support cross-debugging for > vmcores. > > The existing libkvm/kgdb code in the tree has some limited support for > cross-debugging. It requires building a custom libkvm (e.g. libkvm-i386.a) > and custom kgdb for each target platform. However, gdb (and lldb) both > support multiple targets in a single binary, so I'd like to have a single > kgdb binary that can cross-debug anything. > > I started hacking on libkvm last weekend and have a prototype that I've used > (along with some patches to my kgdb port) to debug an amd64 vmcore on an > i386 machine and vice versa. > > ... > > What I'm mostly after is comments on the API, etc. Once that is settled I > will move forward on converting and/or stubbing the other backends (the > stub route would be to only support other backends on native systems for > now). I guess this is closer to a nuclear power plant than a bikeshed judging by the feedback. I have ported the rest of the MD backends and verified that the updated libkvm passes a universe build (including various static assertions for the duplicated constants in other backends). What I have not done is any runtime testing and I would like to ask for help with that now. In particular I need someone to test that kgdb and/or ps works against a native core dump on all platforms other than amd64 and i386. Note that some of the trickiness is that the backends now have to make runtime decisions for things that were previously compile-time decisions. The biggest one affected by this is the MIPS backend as that backend handles three ABIs (mipso32, mipsn32, and mipsn64). I believe I have the handling for that correct (mips[on]32 use 32-bit KSEGs where as mipsn64 uses the extended segments and compat32 KSEGS, and mipso32 uses 32-bit PTEs and mipsn32/n64 both use 64-bit PTEs) (plus both endians for both in theory). The ARM backend also handles both endians (in theory). Another wrinkle is that sparc64 uses its own dump format instead of writing out an ELF file. I had to convert the header structures to use fixed-width types to be cross-friendly. It would be good to ensure that a new libkvm can read a vmcore from an old kernel and vice versa to make sure my conversion is correct (I added an explicit padding field that I believe was implicit before). The code is currently available for review in phabric at https://reviews.freebsd.org/D3341 To test, you can run 'arc patch D3341' in a clean tree to apply the patch. -- John Baldwin From owner-freebsd-arch@freebsd.org Thu Aug 13 04:43:27 2015 Return-Path: Delivered-To: freebsd-arch@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 0894499F45E for ; Thu, 13 Aug 2015 04:43:27 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CDE75CAD; Thu, 13 Aug 2015 04:43:26 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-227-250.lns20.per1.internode.on.net [121.45.227.250]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id t7D4hLZP000989 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 12 Aug 2015 21:43:24 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Supporting cross-debugging vmcores in libkvm (Testing needed) To: John Baldwin , freebsd-arch@freebsd.org References: <3121152.ujdxFEovO3@ralph.baldwin.cx> <5166205.rtMjEmhvmo@ralph.baldwin.cx> From: Julian Elischer Message-ID: <55CC2063.9070804@freebsd.org> Date: Thu, 13 Aug 2015 12:43:15 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <5166205.rtMjEmhvmo@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2015 04:43:27 -0000 On 8/13/15 1:50 AM, John Baldwin wrote: > On Tuesday, August 04, 2015 10:56:09 AM John Baldwin wrote: >> Many debuggers (recent gdb and lldb) support cross-architecture debugging >> just fine. My current WIP port of kgdb to gdb7 supports cross-debugging for >> remote targets already, but I wanted it to also support cross-debugging for >> vmcores. >> >> The existing libkvm/kgdb code in the tree has some limited support for >> cross-debugging. It requires building a custom libkvm (e.g. libkvm-i386.a) >> and custom kgdb for each target platform. However, gdb (and lldb) both >> support multiple targets in a single binary, so I'd like to have a single >> kgdb binary that can cross-debug anything. >> >> I started hacking on libkvm last weekend and have a prototype that I've used >> (along with some patches to my kgdb port) to debug an amd64 vmcore on an >> i386 machine and vice versa. >> >> ... >> >> What I'm mostly after is comments on the API, etc. Once that is settled I >> will move forward on converting and/or stubbing the other backends (the >> stub route would be to only support other backends on native systems for >> now). > I guess this is closer to a nuclear power plant than a bikeshed judging by the > feedback. It has "keep well clear" and "beware of the leopard" written all over it. and when you get past those you see "dragons be here".