Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752965AbZFREix (ORCPT ); Thu, 18 Jun 2009 00:38:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750930AbZFREiq (ORCPT ); Thu, 18 Jun 2009 00:38:46 -0400 Received: from mail-px0-f189.google.com ([209.85.216.189]:49020 "EHLO mail-px0-f189.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750818AbZFREip (ORCPT ); Thu, 18 Jun 2009 00:38:45 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=NHRixuNMvluP8ClljO9gY+hUXPCYaTVsM/93k96k0J7IztHxVYGRyPE7KUY2nnV/ja erIR68e85iVDxDOZXN5LUR4ANh1AFCmvWzZvevFymbNYu25waSGsXnt9x89R7ASCPduo Y2gC+0cLhqlt3ndjN78UaUb3qkz9Wcvd2CrU8= Date: Thu, 18 Jun 2009 12:40:55 +0800 From: Amerigo Wang To: "Eric W. Biederman" Cc: Amerigo Wang , Tao Ma , Andrew Morton , linux-kernel@vger.kernel.org, Alexey Dobriyan Subject: Re: [Patch BUGFIX] kcore: fix its wrong size on x86_64 Message-ID: <20090618044055.GB6133@cr0.nay.redhat.com> References: <2375c9f90906081743p77934f47n8ba1a018d333b95b@mail.gmail.com> <20090611050929.GA2706@cr0.nay.redhat.com> <20090613040958.GA2959@cr0> <2375c9f90906160829g3d605836yb4c5b9beeac50c5f@mail.gmail.com> <20090618030051.GA6133@cr0.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1248 Lines: 38 On Wed, Jun 17, 2009 at 08:37:40PM -0700, Eric W. Biederman wrote: >Amerigo Wang writes: > >> On Tue, Jun 16, 2009 at 12:27:36PM -0700, Eric W. Biederman wrote: >>>Américo Wang writes: >>>>> I think a case can be made either way.  In practice neither answer >>>>> gives us a dense offset space on x86_64 so I think I prefer the >>>>> current definition which sets or clears the high bits as opposed >>>>> to something that mangles the address more. >>>>> >>>> >>>> I am trying to dig more... There must be something wrong there. >>> >>>How so? >> >> See what you will get for kc_vaddr_to_offset(__va(0))? >> It is supposed to be 0. > >I see: 0x0000880000001000 That extra 0x1000 looks suspicous. huh? 0x0000880000000000 not? > >It MUST NOT be 0. That is where the ELF header lives in the file. Of course I knew this. Just read the code: phdr->p_offset = kc_vaddr_to_offset(m->addr) + dataoff; So it should be 0, 'dataoff' is there... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/