From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751330AbdINGxr (ORCPT <rfc822;w@1wt.eu>);
        Thu, 14 Sep 2017 02:53:47 -0400
Received: from mail-pg0-f68.google.com ([74.125.83.68]:35689 "EHLO
        mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751085AbdINGxq (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 14 Sep 2017 02:53:46 -0400
X-Google-Smtp-Source: ADKCNb6NU5PL+SkUAhTwWA3yd9VA4Occ/b2UV9Hh/i0W87tmPXXyTi1eSKIZQFfIFvNNMESL94L9yw==
Date: Thu, 14 Sep 2017 15:53:41 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Helge Deller <deller@gmx.de>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Petr Mladek <pmladek@suse.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Yu, Fenghua" <fenghua.yu@intel.com>,
        Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        Paul Mackerras <paulus@samba.org>,
        Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH 00/14] Fix wrong %pF and %pS printk format specifier
 usages
Message-ID: <20170914065341.GD599@jagdpanzerIV.localdomain>
References: <8b93f9ca-95f6-4e40-1cc8-d1a65833abff@gmx.de>
 <20170907075653.GA533@jagdpanzerIV.localdomain>
 <20170907083207.GC533@jagdpanzerIV.localdomain>
 <667b8849-fb60-a312-2483-505252ff737e@gmx.de>
 <20170907093631.GD533@jagdpanzerIV.localdomain>
 <20170907095119.GE533@jagdpanzerIV.localdomain>
 <0604f27e-24ab-625b-9013-c6c0f4f6acc1@gmx.de>
 <3908561D78D1C84285E8C5FCA982C28F6136C2ED@ORSMSX114.amr.corp.intel.com>
 <20170908061830.GA496@jagdpanzerIV.localdomain>
 <20170908172528.qc2vdtxzqh777k6o@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170908172528.qc2vdtxzqh777k6o@intel.com>
User-Agent: Mutt/1.9.0 (2017-09-02)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On (09/08/17 10:25), Luck, Tony wrote:
> On Fri, Sep 08, 2017 at 03:18:30PM +0900, Sergey Senozhatsky wrote:
> > if the addr is not in kernel .text, then try dereferencing it and check
> > if the dereferenced addr is in kernel .text.
> 
> If it really is a function pointer, then we know that it is safe
> to dereference. But if it isn't, then maybe not?

yes. I thought about it - we can do %pS on a pointer to a global
structure. so that simple heuristic would not work reliably. we
parse ELF sections, and we know the address range of .opd section,
so we can check if the supplied pointer is within the .opd section
or not.

.opd does exist on ia64. not sure what's the name of ELF descriptor
section on ppc64/parisc64.

if we will be able to simply do

	.opd->address  <=  ptr  <=  .opd->address + .opd->size

then it mostly should work for us. I guess.

> If it is a function pointer then dereferening will indeed give
> us a .text address. But if it isn't, it might still give us a
> .text address (we could reduce the probability of a false hit
> by checking that the .text address was exactly on a symbol with
> no offset ... but data values that happen to be the addresses of
> function entry points are possible).

hm. yes, need to think more.

	-ss