Received: by 10.223.185.116 with SMTP id b49csp4156672wrg; Tue, 6 Mar 2018 10:43:40 -0800 (PST) X-Google-Smtp-Source: AG47ELtjUA9svKSLnyXkEcifgf0WzjcBLm+eHhyBkuLEEim1R9tV0rVGgbUQVY0w/pzTt2v6V6h9 X-Received: by 10.99.115.21 with SMTP id o21mr1797233pgc.226.1520361820230; Tue, 06 Mar 2018 10:43:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520361820; cv=none; d=google.com; s=arc-20160816; b=Ra4g7mm8jetKMUU1cEYQx7tMTpntfMNv12v8qGRrCshDUHqgeuEhr2cts7cU4j3ydM YhMqNMU5W5EfOmgqPxCaGuns4ru9dKnN5d+BdSZPvWOxYe2d/nUXoaJfqg9PxQ+rD4lW V2nFSo6i+oWppI7vnp1o4Ce0SPurpCoCGyXxg+y57ZNYskv5mW1S+b3mK3rgbvRYYJac zsxCK6nsJrGhQGorY6yHKMjf9Vrxt+INMqLyEq8kdn3jLLl7JeS10LT2k9cYoR2PzcSr vRL9N5MRXjDPyLKNAaSc2sxiJXvP3JCSelWhD0OGeojPJOeNLkBaHYRLxMFJ5zC2lbG9 /gXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=minee7uRVKfp8Fvm6pSQw9VWK3TUm9ibsxGbVB6/ij8=; b=Wzj24O2dDWWwPcv0aCQelu6Vk4yjH8LAAgZmNLfQ5oXWX1/ssM5f3LPT+PaSIYVIgc ncDhfptwcR6SLG59Oc0JP6UVNbfiQe19WCLTmmQUElXZo8V2lxmFC3qBNzUv8pKdt5VG xvYGwMW87I12EAoLQga3RjGvqIcj+nBOHAFqGTZKox81h2CmdEyKGhW8f+Rjul+FyAz3 CYa3ItbR+y204fkMn4E/FQwZ8ZbJVPjSEBvMKf3uQIknk4BKEloxy0yi+n2N1wEdXTCO 9Itl61zNA/vLRFO2PitCMelQHf6nrqPiz4KeWbBnMUS9EsE9jV3o6WV/BizepRIAb1xX 24ZQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d30-v6si11462534pld.452.2018.03.06.10.43.24; Tue, 06 Mar 2018 10:43:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753747AbeCFSma (ORCPT + 99 others); Tue, 6 Mar 2018 13:42:30 -0500 Received: from tartarus.angband.pl ([89.206.35.136]:56200 "EHLO tartarus.angband.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750797AbeCFSm3 (ORCPT ); Tue, 6 Mar 2018 13:42:29 -0500 Received: from kilobyte by tartarus.angband.pl with local (Exim 4.89) (envelope-from ) id 1etHXe-0003kK-Gi; Tue, 06 Mar 2018 19:42:26 +0100 Date: Tue, 6 Mar 2018 19:42:26 +0100 From: Adam Borowski To: Alexey Dobriyan Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] vsprintf: distinguish between (null), (err) and (invalid) pointer derefs Message-ID: <20180306184226.ww5uopskejwojeta@angband.pl> References: <20180306182217.GA3798@avx2> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180306182217.GA3798@avx2> X-Junkbait: aaron@angband.pl, zzyx@angband.pl User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: kilobyte@angband.pl X-SA-Exim-Scanned: No (on tartarus.angband.pl); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 06, 2018 at 09:22:17PM +0300, Alexey Dobriyan wrote: > > +#define BAD_PTR_STRING(x) (!(x) ? "(null)" : IS_ERR(x) ? "(err)" : "(invalid)") > > This is getting ridiculous. > > Instead of simply printing a pointer as %08lx or %016llx, not only glibc > (null) stupidity is propagated but expanded and "improved". This is not about printing a pointer, this is about attempting to print an object referenced by such a bad pointer. Which leads to a crash: in userspace, you get a segfault; in the kernel, at least in the case I tested, the system is dead without even a squeal on either console or serial. > I assure you reading 0000000000000000 is just as obvious as (null) and > reading fffffffffffffffa is just as good as -ENOMEM. > > In fact printing with hex is more information. Maybe it is important > that buggy pointer is small value but it's value is lost. > > Sure don't dereference a pointer for very small or very erry values > but print it without all the bell and whistles. That's a reasonable suggestion, but it still needs to be special cased. Note the difference between printk("%px", 42) and printk("%s", 42). See this part: - if (!ptr && *fmt != 'K' && *fmt != 'x') { + if (IS_BAD_PTR(ptr) && *fmt != 'K' && *fmt != 'x') { Printing the pointer is already excluded; what I'm fixing is: 1. lying that the bad pointer was (null) when it was -ENOMEM (commit 1) 2. crash when some bad code tries to printk("%s", -ENOMEM) (commit 2) So, if what you propose is applying commit 2, and changing 1 to print the raw value instead of (null)/(err)/(invalid), that sounds good. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. ⠈⠳⣄⠀⠀⠀⠀ A master species delegates.