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 666A2C433E0 for ; Mon, 18 Jan 2021 17:53:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 011E62222A for ; Mon, 18 Jan 2021 17:53:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 011E62222A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 634A46B025B; Mon, 18 Jan 2021 12:53:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E5BA8D0017; Mon, 18 Jan 2021 12:53:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4FB4C6B02B4; Mon, 18 Jan 2021 12:53:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0078.hostedemail.com [216.40.44.78]) by kanga.kvack.org (Postfix) with ESMTP id 39BE06B025B for ; Mon, 18 Jan 2021 12:53:15 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E8EB61EFD for ; Mon, 18 Jan 2021 17:53:14 +0000 (UTC) X-FDA: 77719642308.26.move98_43070ca2754b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id D76181804B676 for ; Mon, 18 Jan 2021 17:53:14 +0000 (UTC) X-HE-Tag: move98_43070ca2754b X-Filterd-Recvd-Size: 3164 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Mon, 18 Jan 2021 17:53:14 +0000 (UTC) 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 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 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.