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=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,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 7FE76C433DB for ; Wed, 20 Jan 2021 09:19:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BD7002332A for ; Wed, 20 Jan 2021 09:19:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BD7002332A Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D41686B0005; Wed, 20 Jan 2021 04:19:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CCA7E6B0006; Wed, 20 Jan 2021 04:19:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B933B6B0007; Wed, 20 Jan 2021 04:19:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0127.hostedemail.com [216.40.44.127]) by kanga.kvack.org (Postfix) with ESMTP id 9C0086B0005 for ; Wed, 20 Jan 2021 04:19:20 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 65A29B7A0 for ; Wed, 20 Jan 2021 09:19:20 +0000 (UTC) X-FDA: 77725604880.08.yard20_6210bea27559 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 4A1981819E624 for ; Wed, 20 Jan 2021 09:19:20 +0000 (UTC) X-HE-Tag: yard20_6210bea27559 X-Filterd-Recvd-Size: 4689 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Wed, 20 Jan 2021 09:19:19 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1611134358; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=52em1yn/Qr5akNgNbjF28oF+osSjM05q1X0waiVX+8Y=; b=uAubqB3b+wP1NRPQjAFc1KnUyU92GvRYO4WPyNa1wjhvNCkhOmKBG8nLkR8duTbhMpcW3Z d9gsXFWpuv7yaKythsHoIn3i7J/k36UlKernz0z9tjTlSI2INh4OzRMOf1BiKZCMHsMkfb Nv9TKsPH1rMx5a7dp52QhLUseUnNFyc= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 37CE7AF3E; Wed, 20 Jan 2021 09:19:18 +0000 (UTC) Date: Wed, 20 Jan 2021 10:19:17 +0100 From: Petr Mladek To: Timur Tabi Cc: Kees Cook , Matthew Wilcox , Sergey Senozhatsky , Andrew Morton , linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, roman.fietze@magna.com, Steven Rostedt , John Ogness , linux-mm@kvack.org, Akinobu Mita Subject: Re: [PATCH 0/2] introduce DUMP_PREFIX_UNHASHED for hex dumps Message-ID: References: <20210116220950.47078-1-timur@kernel.org> <20210118182635.GD2260413@casper.infradead.org> <20210119014725.GH2260413@casper.infradead.org> <202101191135.A78A570@keescook> <29122c86-bfea-2f25-d111-00641cc660ba@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29122c86-bfea-2f25-d111-00641cc660ba@kernel.org> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue 2021-01-19 13:55:29, Timur Tabi wrote: > On 1/19/21 1:45 PM, Kees Cook wrote: > > How about this so the base address is hashed once, with the offset added > > to it for each line instead of each line having a "new" hash that makes > > no sense: > > > > diff --git a/lib/hexdump.c b/lib/hexdump.c > > index 9301578f98e8..20264828752d 100644 > > --- a/lib/hexdump.c > > +++ b/lib/hexdump.c > > @@ -242,12 +242,17 @@ void print_hex_dump(const char *level, const char *prefix_str, int prefix_type, > > const void *buf, size_t len, bool ascii) > > { > > const u8 *ptr = buf; > > + const u8 *addr; > > int i, linelen, remaining = len; > > unsigned char linebuf[32 * 3 + 2 + 32 + 1]; > > if (rowsize != 16 && rowsize != 32) > > rowsize = 16; > > + if (prefix_type == DUMP_PREFIX_ADDRESS && > > + ptr_to_hashval(ptr, &addr)) > > + addr = 0; > > + > > for (i = 0; i < len; i += rowsize) { > > linelen = min(remaining, rowsize); > > remaining -= rowsize; > > @@ -258,7 +263,7 @@ void print_hex_dump(const char *level, const char *prefix_str, int prefix_type, > > switch (prefix_type) { > > case DUMP_PREFIX_ADDRESS: > > printk("%s%s%p: %s\n", > > - level, prefix_str, ptr + i, linebuf); > > + level, prefix_str, addr + i, linebuf); > > Well, this is better than nothing, but not by much. Again, as long as %px > exists for printk(), I just cannot understand any resistance to allowing it > in print_hex_dump(). > > Frankly, I think this patch and my patch should both be added. During > debugging, it's very difficult if not impossible to work with hashed > addresses. I use print_hex_dump() with an unhashed address all the time, > either by applying my patch to my own kernel or just replacing the %p with > %px. This was my view as well. People should not need to add features into hexdump code when they want to use is for debugging. And the address is pretty useful. A solution might be to prevent using this in the mainline: + it might be reported by checkpatch.pl + it might print some bold warning on the first use, similar to trace_printk(). Or we need this in the mainline. Then the use of %pK looks like the best compromise to me. We could also add some warning as a comment and use some provocative name for the flag as suggested by Matthew. And we should definitely add Linus into CC when sending v2. His expected opinion has been mentioned several times in this thread. It would be better to avoid these speculations and get his real opinion. IMHO, it is too late to add him in this long thread. Best Regards, Petr