From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37E8AC04E53 for ; Wed, 15 May 2019 07:23:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0DF4121473 for ; Wed, 15 May 2019 07:23:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726218AbfEOHXT (ORCPT ); Wed, 15 May 2019 03:23:19 -0400 Received: from mail-ua1-f68.google.com ([209.85.222.68]:36417 "EHLO mail-ua1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725871AbfEOHXS (ORCPT ); Wed, 15 May 2019 03:23:18 -0400 Received: by mail-ua1-f68.google.com with SMTP id 94so87935uam.3; Wed, 15 May 2019 00:23:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D6y3Txro2Y80xJMXPF/WXXyGFbfglpcuRYylKAaykOs=; b=G4d5TbL2zXDn5f9I+chOsiGhFl10gM57db35uOamciP3gknJPcKVAPQ91SGx5xumQ9 tvb51SUNSptNd5quVQ29U/dlzr49oSMN2kg61B+NDMqNh118Anjl577d7R4f9IV2G5Rm WWalbCsPJzu6IixyqHD8SxelZOfrxdanwBT9E1K8rJrZfzMPQXiw+QlDQLFFV5HzWztC FinsSG8D1crlV7wGLP63W3JJgBtGI+uAIwWbrYHxSxGKqbBfMRfkIW5OpXpXeEDoekkb YUbKyC3AYzdUDWVwXRtGr2bimNvLIrpD0Y9/bb6Asejx5QcuZ0cDYynoosigb4ODS4nT DJHA== X-Gm-Message-State: APjAAAWZsGZ6LjNx1HBrEMY9eAuDJxvGx3efvWJrJaCXgkWAskar6KMB fK+OLxwNDPKg36z491yliv+KRlWAlzinHoI0xyhl+w== X-Google-Smtp-Source: APXvYqwXjd7ZJQ8Ru9EPguJi1io4zPagRBwnSJVZX+f303p0r2QyE6ajAOtJrnYR8sRf8L5ySdKBcnfwbQtAINpBUKc= X-Received: by 2002:ab0:6419:: with SMTP id x25mr19591138uao.86.1557904997683; Wed, 15 May 2019 00:23:17 -0700 (PDT) MIME-Version: 1.0 References: <20190510081635.GA4533@jagdpanzerIV> <20190510084213.22149-1-pmladek@suse.com> <20190510122401.21a598f6@gandalf.local.home> <096d6c9c17b3484484d9d9d3f3aa3a7c@AcuMS.aculab.com> <20190513091320.GK9224@smile.fi.intel.com> <20190513124220.wty2qbnz4wo52h3x@pathway.suse.cz> <20190514020730.GA651@jagdpanzerIV> <45348cf615fe40d383c1a25688d4a88f@AcuMS.aculab.com> <20190514143751.48e81e05@oasis.local.home> <20190514153503.6b7faaa7@oasis.local.home> In-Reply-To: <20190514153503.6b7faaa7@oasis.local.home> From: Geert Uytterhoeven Date: Wed, 15 May 2019 09:23:05 +0200 Message-ID: Subject: Re: [PATCH] vsprintf: Do not break early boot with probing addresses To: Steven Rostedt Cc: David Laight , Sergey Senozhatsky , Petr Mladek , Andy Shevchenko , christophe leroy , Linus Torvalds , Rasmus Villemoes , "Tobin C . Harding" , Michal Hocko , Sergey Senozhatsky , "linux-kernel@vger.kernel.org" , Michael Ellerman , "linuxppc-dev@lists.ozlabs.org" , Russell Currey , Stephen Rothwell , Heiko Carstens , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , Martin Schwidefsky Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Steve, On Tue, May 14, 2019 at 9:35 PM Steven Rostedt wrote: > On Tue, 14 May 2019 21:13:06 +0200 > Geert Uytterhoeven wrote: > > > > Do we care about the value? "(-E%u)"? > > > > > > That too could be confusing. What would (-E22) be considered by a user > > > doing an sprintf() on some string. I know that would confuse me, or I > > > would think that it was what the %pX displayed, and wonder why it > > > displayed it that way. Whereas "(fault)" is quite obvious for any %p > > > use case. > > > > I would immediately understand there's a missing IS_ERR() check in a > > function that can return -EINVAL, without having to add a new printk() > > to find out what kind of bogus value has been received, and without > > having to reboot, and trying to reproduce... > > I have to ask. Has there actually been a case that you used a %pX and > it faulted, and you had to go back to find what the value of the > failure was? If it faulted, the bad pointer value is obvious from the backtrace. If the code avoids the fault by verifying the pointer and returning "(efault)" instead, the bad pointer value is lost. Or am I missing something? Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: [PATCH] vsprintf: Do not break early boot with probing addresses Date: Wed, 15 May 2019 09:23:05 +0200 Message-ID: References: <20190510081635.GA4533@jagdpanzerIV> <20190510084213.22149-1-pmladek@suse.com> <20190510122401.21a598f6@gandalf.local.home> <096d6c9c17b3484484d9d9d3f3aa3a7c@AcuMS.aculab.com> <20190513091320.GK9224@smile.fi.intel.com> <20190513124220.wty2qbnz4wo52h3x@pathway.suse.cz> <20190514020730.GA651@jagdpanzerIV> <45348cf615fe40d383c1a25688d4a88f@AcuMS.aculab.com> <20190514143751.48e81e05@oasis.local.home> <20190514153503.6b7faaa7@oasis.local.home> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20190514153503.6b7faaa7@oasis.local.home> Sender: linux-kernel-owner@vger.kernel.org To: Steven Rostedt Cc: David Laight , Sergey Senozhatsky , Petr Mladek , Andy Shevchenko , christophe leroy , Linus Torvalds , Rasmus Villemoes , "Tobin C . Harding" , Michal Hocko , Sergey Senozhatsky , "linux-kernel@vger.kernel.org" , Michael Ellerman , "linuxppc-dev@lists.ozlabs.org" , Russell Currey , Stephen Rothwell , Heiko Carstens , "linux-arch@vger.kernel.org" List-Id: linux-arch.vger.kernel.org Hi Steve, On Tue, May 14, 2019 at 9:35 PM Steven Rostedt wrote: > On Tue, 14 May 2019 21:13:06 +0200 > Geert Uytterhoeven wrote: > > > > Do we care about the value? "(-E%u)"? > > > > > > That too could be confusing. What would (-E22) be considered by a user > > > doing an sprintf() on some string. I know that would confuse me, or I > > > would think that it was what the %pX displayed, and wonder why it > > > displayed it that way. Whereas "(fault)" is quite obvious for any %p > > > use case. > > > > I would immediately understand there's a missing IS_ERR() check in a > > function that can return -EINVAL, without having to add a new printk() > > to find out what kind of bogus value has been received, and without > > having to reboot, and trying to reproduce... > > I have to ask. Has there actually been a case that you used a %pX and > it faulted, and you had to go back to find what the value of the > failure was? If it faulted, the bad pointer value is obvious from the backtrace. If the code avoids the fault by verifying the pointer and returning "(efault)" instead, the bad pointer value is lost. Or am I missing something? Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DCA27C04E53 for ; Wed, 15 May 2019 07:24:41 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 30DE120862 for ; Wed, 15 May 2019 07:24:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 30DE120862 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 453mK26vQjzDqSc for ; Wed, 15 May 2019 17:24:38 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gmail.com (client-ip=209.85.222.68; helo=mail-ua1-f68.google.com; envelope-from=geert.uytterhoeven@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Received: from mail-ua1-f68.google.com (mail-ua1-f68.google.com [209.85.222.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 453mHX46lpzDqP9 for ; Wed, 15 May 2019 17:23:20 +1000 (AEST) Received: by mail-ua1-f68.google.com with SMTP id 79so339989uav.6 for ; Wed, 15 May 2019 00:23:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D6y3Txro2Y80xJMXPF/WXXyGFbfglpcuRYylKAaykOs=; b=nkLANUWE4Kdbrgc6T0t3YR8u+jIbze0XAhDlBboO14adEp0HtEsZ+aujakhnqfKbkG /gX63u+m965rhHW2WI0XmoarCbm+wLxI8W6RvP8zwlchdC10BV9iwVsCp43SKWbhpuB3 6YwnZsvPLsX0rJ0PynJS/cB8v0lAgVQT3hvyy7KtP8Ef726wRMB5ik3Kqto1291+/oI7 ZehOgZzB033jzNxJOBwG0H0GBr9rU119B8B9u0MHMP3z2PhlcJBKoKJ630cEP8LQApxI OsMOOQo5lWoSpQFgSD00k3f5Hwd0D1PtNcx6MU/4WzAMZ94CLTEPO6cCjkOwITaSBpCZ Njaw== X-Gm-Message-State: APjAAAXeDUcJD8ZIJly7R9Zrj64CaJbBqlJ2x42vmDdY8yR9hRbz+pRU URCFdX59yEerRBRM6KlqfmPNrLHLpnXJ4QDN1sY= X-Google-Smtp-Source: APXvYqwXjd7ZJQ8Ru9EPguJi1io4zPagRBwnSJVZX+f303p0r2QyE6ajAOtJrnYR8sRf8L5ySdKBcnfwbQtAINpBUKc= X-Received: by 2002:ab0:6419:: with SMTP id x25mr19591138uao.86.1557904997683; Wed, 15 May 2019 00:23:17 -0700 (PDT) MIME-Version: 1.0 References: <20190510081635.GA4533@jagdpanzerIV> <20190510084213.22149-1-pmladek@suse.com> <20190510122401.21a598f6@gandalf.local.home> <096d6c9c17b3484484d9d9d3f3aa3a7c@AcuMS.aculab.com> <20190513091320.GK9224@smile.fi.intel.com> <20190513124220.wty2qbnz4wo52h3x@pathway.suse.cz> <20190514020730.GA651@jagdpanzerIV> <45348cf615fe40d383c1a25688d4a88f@AcuMS.aculab.com> <20190514143751.48e81e05@oasis.local.home> <20190514153503.6b7faaa7@oasis.local.home> In-Reply-To: <20190514153503.6b7faaa7@oasis.local.home> From: Geert Uytterhoeven Date: Wed, 15 May 2019 09:23:05 +0200 Message-ID: Subject: Re: [PATCH] vsprintf: Do not break early boot with probing addresses To: Steven Rostedt Content-Type: text/plain; charset="UTF-8" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Petr Mladek , "linux-arch@vger.kernel.org" , Sergey Senozhatsky , Heiko Carstens , "linux-s390@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , Rasmus Villemoes , "linux-kernel@vger.kernel.org" , Michal Hocko , Sergey Senozhatsky , David Laight , Stephen Rothwell , Andy Shevchenko , Linus Torvalds , Martin Schwidefsky , "Tobin C . Harding" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi Steve, On Tue, May 14, 2019 at 9:35 PM Steven Rostedt wrote: > On Tue, 14 May 2019 21:13:06 +0200 > Geert Uytterhoeven wrote: > > > > Do we care about the value? "(-E%u)"? > > > > > > That too could be confusing. What would (-E22) be considered by a user > > > doing an sprintf() on some string. I know that would confuse me, or I > > > would think that it was what the %pX displayed, and wonder why it > > > displayed it that way. Whereas "(fault)" is quite obvious for any %p > > > use case. > > > > I would immediately understand there's a missing IS_ERR() check in a > > function that can return -EINVAL, without having to add a new printk() > > to find out what kind of bogus value has been received, and without > > having to reboot, and trying to reproduce... > > I have to ask. Has there actually been a case that you used a %pX and > it faulted, and you had to go back to find what the value of the > failure was? If it faulted, the bad pointer value is obvious from the backtrace. If the code avoids the fault by verifying the pointer and returning "(efault)" instead, the bad pointer value is lost. Or am I missing something? Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds