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=-7.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 85E1CC433E6 for ; Mon, 18 Jan 2021 17:54:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5403F22227 for ; Mon, 18 Jan 2021 17:54:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407275AbhARRyX (ORCPT ); Mon, 18 Jan 2021 12:54:23 -0500 Received: from mail.kernel.org ([198.145.29.99]:48218 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2436729AbhARRxz (ORCPT ); Mon, 18 Jan 2021 12:53:55 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id E27D422227; Mon, 18 Jan 2021 17:53:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610992393; bh=2BUVn/G7ZLhzQ7BKdANSYLDJE9+tWZ93amHRzaBmVy4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mS0liz8ZtG5Own/099bZ5X2A2wNMH5QZuZxd+Fmu7bCe+6hkLbY1Ayn1YmyPhqA05 N2C2CJ4Pqck6/pkECVwQ9XOj49W06S3PF0Bg9B9n81vq84DEwgK6YKDn2saDAkGDFn x9tA9f/NS+c+yICAaSokw0nB4iNJW4IroYHqT4CyaFyV/T4Mq/0AI8j9aCszK4+/6g x/Osw1OAhwbHLBsJfDCrt+oj3OCnqi7u0+SYVw69PQ+2bUSRLT3PDe+Bl4MJ0s6/7h /2YQvHO558YN6bkPMUW0i9mSZvBtVDGEJhs1OWfmTAru+QIxBn1Um+zMgak1pJJmPn E8r4pTTfHyF+Q== Subject: Re: [PATCH 1/2] [v2] lib/hexdump: introduce DUMP_PREFIX_UNHASHED for unhashed addresses To: Andy Shevchenko Cc: Andrew Morton , Linux Kernel Mailing List , Linus Torvalds , Sergey Senozhatsky , Petr Mladek , roman.fietze@magna.com, Kees Cook , Steven Rostedt , John Ogness , linux-mm , Akinobu Mita , Alexander Viro , Vaibhav Jain , Dan Williams , Linux FS Devel References: <20210116220950.47078-1-timur@kernel.org> <20210116220950.47078-2-timur@kernel.org> <20210118171411.GG4077@smile.fi.intel.com> From: Timur Tabi Message-ID: Date: Mon, 18 Jan 2021 11:53:10 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210118171411.GG4077@smile.fi.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/18/21 11:14 AM, Andy Shevchenko wrote: > But isn't it good to expose those issues (and fix them)? I suppose. >>> Perhaps even add _ADDRESS to DUMP_PREFIX_UNHASHED, but this maybe too >> long. >> >> I think DUMP_PREFIX_ADDRESS_UNHASHED is too long. > What about introducing new two like these: > > DUMP_PREFIX_OFFSET, > DUMP_PREFIX_ADDRESS, > DUMP_PREFIX_ADDR_UNHASHED, > DUMP_PREFIX_ADDR_HASHED, I think we're approaching bike-shedding. DUMP_PREFIX_ADDR_HASHED and DUMP_PREFIX_ADDRESS are the same thing. I don't want people to have to move from DUMP_PREFIX_ADDRESS to some other enum for no change in functionality. I'm willing to rearrange the code so that it's enumerated more consistently, but I don't think there's anything wrong with DUMP_PREFIX_UNHASHED. It's succinct and clear.