From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10032 invoked by alias); 23 Sep 2010 12:42:51 -0000 Received: (qmail 10018 invoked by uid 22791); 23 Sep 2010 12:42:50 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate7.de.ibm.com (HELO mtagate7.de.ibm.com) (195.212.17.167) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 23 Sep 2010 12:42:45 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.1/8.13.1) with ESMTP id o8NCggrb014574 for ; Thu, 23 Sep 2010 12:42:42 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o8NCgfau3854496 for ; Thu, 23 Sep 2010 14:42:41 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o8NCgff9019419 for ; Thu, 23 Sep 2010 14:42:41 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id o8NCgex0019394; Thu, 23 Sep 2010 14:42:40 +0200 Message-Id: <201009231242.o8NCgex0019394@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 23 Sep 2010 14:42:40 +0200 Subject: Re: [patch] Fix gcore writer for -Wl,-z,relro (PR corefiles/11804) To: jan.kratochvil@redhat.com (Jan Kratochvil) Date: Thu, 23 Sep 2010 14:48:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20100922213245.GA25769@host1.dyn.jankratochvil.net> from "Jan Kratochvil" at Sep 22, 2010 11:32:45 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-09/txt/msg00403.txt.bz2 Jan Kratochvil wrote: > There was a hint > http://sourceware.org/bugzilla/show_bug.cgi?id=11804#c12 > it may not always work right but that would be just a Linux kernel bug so that > GDB part should be OK. Also it cannot be a regression, only more pages may be > written out with this patch. [ I've been tracking down a Linux on z customer problem that turns out to be exactly the same issue -- thanks for working on this! ] It appears there are at least two problems with this approach currently being discussed: - The "dirty" pages count in /proc/.../smaps is sometimes wrong. This is because the kernel currently only checks the per-PTE dirty bit, and not the per-page dirty bit. This is drastically wrong on System z, because the platform *only* has a per-page hardware dirty bit; per-PTE dirty bit checks will always return "clean". But on other systems there's a chance of mis-indication of the dirty state as well (e.g. if the page was dirtied by a syscall, or if a dirty page was swapped out, swapped back in, and subsequently removed from swap). This can indeed be considered a pure kernel bug that needs to be fixed. - Even with the dirty accounting fixed, there are *still* cases where a page is genuinely clean as far as memory-management is concerned, but it was modified as compared to the file contents anyway. This happens if a page was swapped out and back in, but its contents remain present in swap space until the latter is reused (so-called "swap cache" pages). These are legitimately considered clean pages because they can be simply dropped if needed -- the content is still there on the swap device. To fix the second problem, it seems GDB will need to pursue a different approach, for example by checking whether a mapping contains only file-backed or also any anonymous pages (I'm told by kernel folks that swap cache pages also count as anonymous). However, this information is not readily available in the general case (it's in /proc/kpageflags, but that's root-only, and it is also in /proc/.../numa_maps, but only if NUMA support is enabled ...). One proposal is to add a count of anonymous pages to /proc/.../smaps: http://marc.info/?l=linux-kernel&m=128460743123381&w=2 If that goes in, I guess your patch should consider the new Anonymous: field instead of (or maybe in addition to?) Shared_Dirty and Private_Dirty. (Swap needs to be considered as well in either case.) Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com