Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755211AbdIGJjg (ORCPT ); Thu, 7 Sep 2017 05:39:36 -0400 Received: from mail-pg0-f68.google.com ([74.125.83.68]:34140 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755087AbdIGJjX (ORCPT ); Thu, 7 Sep 2017 05:39:23 -0400 X-Google-Smtp-Source: ADKCNb7Omnq25aEre1bl2s3ygw0VQHt+0XcQ51ACT7rVsG661Tqav7b281xc+BnVxuQf6tViqa0bYA== Date: Thu, 7 Sep 2017 18:36:31 +0900 From: Sergey Senozhatsky To: Helge Deller Cc: Sergey Senozhatsky , linux-kernel@vger.kernel.org, Sergey Senozhatsky , Petr Mladek , Andrew Morton , Tony Luck , Fenghua Yu , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman Subject: Re: [PATCH 00/14] Fix wrong %pF and %pS printk format specifier usages Message-ID: <20170907093631.GD533@jagdpanzerIV.localdomain> References: <1504729681-3504-1-git-send-email-deller@gmx.de> <20170907004522.GA3885@jagdpanzerIV.localdomain> <8b93f9ca-95f6-4e40-1cc8-d1a65833abff@gmx.de> <20170907075653.GA533@jagdpanzerIV.localdomain> <20170907083207.GC533@jagdpanzerIV.localdomain> <667b8849-fb60-a312-2483-505252ff737e@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <667b8849-fb60-a312-2483-505252ff737e@gmx.de> 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: 2242 Lines: 55 (Cc Tony, Fenghua, Benjamin, Paul, Michael) a brief description: original patch set: lkml.kernel.org/r/1504729681-3504-1-git-send-email-deller@gmx.de start of this discussion: lkml.kernel.org/r/20170907075653.GA533@jagdpanzerIV.localdomain basically we are looking at possibilities to make %pF/%pS differences less disturbing. Helge has discovered a number of wrong usages in the kernel and has fixed the currently existing call sites; the question is what we can do to avoid this type of the patch sets in the future? /* assuming that no one reads printk documentation */ Hopefully you guys can help. On (09/07/17 11:12), Helge Deller wrote: [..] > > - ptr = dereference_function_descriptor(ptr); > > + ptr = __dereference_function_descriptor(ptr); > > This is not needed. > All affected arches (ia64, ppc64, parisc64) already call > probe_kernel_address() inside their dereference_function_descriptor() function. > So this patch just adds unnecessary overhead for all arches. good, thanks. honestly, I obviously didn't check what each platform does. guilty! sort of. > > ... here is a question, does function descriptor belong to a special > > section? can we check that supplied ptr belongs to a descriptor section > > and avoid dereference_function_descriptor() if it doesn't? (just fall > > through directly to symbol_string() in this case). is this possible? > > I think theoretically yes. > On parisc ptr does *not* point to any code segment, and most likely it > points to the .data segment. I don't know if that's the case for ia64 and > ppc64 too. > I can look into adding such check-code, but even then the warning will > only show up if you run on ia64, ppc64 and parisc64. ok. personally I think that we need to start doing "does ptr belong to descriptor segment/section/etc" thing and skip dereference_function_descriptor() when it doesn't. [well, where possible. hopefully on every affected platform... if this problem actually bothers any one]. that seems like the way to fix the root cause of the problem. because it's you, Petr and may be 7 more guys who knows the difference between %pF/%pS. no one else has any idea at all. and no one actually reads the printk() documentation, let's be real :) -ss