Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751330AbdINGxr (ORCPT ); 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 ); 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 To: "Luck, Tony" Cc: Sergey Senozhatsky , Helge Deller , "linux-kernel@vger.kernel.org" , Sergey Senozhatsky , Petr Mladek , Andrew Morton , "Yu, Fenghua" , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman 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: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1260 Lines: 33 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