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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 00DC2CFB43F for ; Mon, 7 Oct 2024 14:24:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A1016B008A; Mon, 7 Oct 2024 10:24:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 851CC6B008C; Mon, 7 Oct 2024 10:24:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F1BD6B0092; Mon, 7 Oct 2024 10:24:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 477E66B008A for ; Mon, 7 Oct 2024 10:24:52 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C6CBCAC99E for ; Mon, 7 Oct 2024 14:24:51 +0000 (UTC) X-FDA: 82647027582.11.5F5BBAD Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) by imf19.hostedemail.com (Postfix) with ESMTP id 61B6A1A0009 for ; Mon, 7 Oct 2024 14:24:49 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=i3As6tQ6; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf19.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 192.198.163.11) smtp.mailfrom=andriy.shevchenko@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728310991; a=rsa-sha256; cv=none; b=1DJn419I44u1TcZA+AGYrao+hkxJCV8il48TFUR5SoySM0zmyNaO6W3p4yZ3Q2UkEZiYaP kUI/gJTAT/1MdlWfX7vOCc1QBQCy/M9AxMWN6bJSKxXodeN1i0wvlmlS6KWWMGtOp52xGK rUP26N2XwuKxhL1hHFMxbt+A+8K36Cw= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=i3As6tQ6; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf19.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 192.198.163.11) smtp.mailfrom=andriy.shevchenko@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728310991; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IrNyocmXYU9JzOsnWNj8VB3V1Q/vifAZZwaTagA6HrE=; b=o5N3WBmF8ksgcO+ixNY5TBokjIVPLC6xOSf4E0LRoYBA2uo07PctAstdAfIof+mRN/zFgL 2xoESdasROrV4rNo0Z04lKVrqyt9aDnFl5O582daCKqqVPZyGeMxzB7rR9R7QUrjY6dABA 99MmwTpObc0DLuUtU7gAEAtkBvGVsTk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728311089; x=1759847089; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=xtD5r6R1+iAiOT5E2n5P7WbselsT4vAju7aEoR9WU7k=; b=i3As6tQ68sepqwtt+1vnF5rp+rKpQwhXsmhEfNiBX5oHPJPt4Nkpe5L8 DFJoWbbjcpG/k310lpxQuwkiyqzUKdqXgY12Yjx5D5F+xX+LwSthYz6AL 2LwnQV3t+TLhyF7VeRqN83jQGmVvpPfJ3DRIf0Id19hMA2qj3u8NoD03q 5100qFwDTyYVlE+XPbY6Yes+Hl4ag6qFv/tH+vHwBYCF5Wb2+MolHiyRb lr4yDkviu8rEtdwd2r55ylhZdmDXYHzUjOAJM+RonHu4bYROhH+IsrZzH AFOXSoZCPsz2YThAnkTAxjg0wkD8DQJSteVlZVlbdsFKBO9d9vYdbrx3x w==; X-CSE-ConnectionGUID: PQSmtqh3RnS5Afg9uHU7Bw== X-CSE-MsgGUID: pC/ZAzuQQ7W6bW0SCgDezA== X-IronPort-AV: E=McAfee;i="6700,10204,11218"; a="38066726" X-IronPort-AV: E=Sophos;i="6.11,184,1725346800"; d="scan'208";a="38066726" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Oct 2024 07:24:48 -0700 X-CSE-ConnectionGUID: GY0tNvgjRFGpfhvvU6AzHA== X-CSE-MsgGUID: B/OfJPxKRyKdLRPqMuh9HQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,184,1725346800"; d="scan'208";a="106244537" Received: from smile.fi.intel.com ([10.237.72.154]) by fmviesa001.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Oct 2024 07:24:45 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.98) (envelope-from ) id 1sxofB-00000000F60-2JO7; Mon, 07 Oct 2024 17:24:41 +0300 Date: Mon, 7 Oct 2024 17:24:41 +0300 From: Andy Shevchenko To: David Hildenbrand Cc: Dan Williams , "Huang, Ying" , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org, Davidlohr Bueso , Jonathan Cameron , Dave Jiang , Alison Schofield , Vishal Verma , Ira Weiny , Alistair Popple , Bjorn Helgaas , Baoquan He Subject: Re: [PATCH -v2] Resource: fix region_intersects() for CXL memory Message-ID: References: <20240819023413.1109779-1-ying.huang@intel.com> <874j6vc10j.fsf@yhuang6-desk2.ccr.corp.intel.com> <66d8f41cb3e6_3975294f9@dwillia2-xfh.jf.intel.com.notmuch> <65838cc0-9a20-4994-a0ef-9cd50bb00951@redhat.com> <09d44b21-9739-417b-a76c-5383fcbde96b@redhat.com> <922e97d9-e16a-4bb8-90b0-4bb3347174e8@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <922e97d9-e16a-4bb8-90b0-4bb3347174e8@redhat.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Rspamd-Queue-Id: 61B6A1A0009 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: qeusrkdht55au8oey9qtexcwxomx98xe X-HE-Tag: 1728311089-415209 X-HE-Meta: U2FsdGVkX18B0O0YoUHocIBjAfJkvQBrOucrTn9i+zO0HYC9/pNWW/VKyDhPdtWwKS440zqooiM7GqbjUiloYJ+nq+cRHRdcJB5q6XL/cpMU6/jOj7dOzGM6k+pflVbFw3X9G1UrfCWixSAe1rhmIyHomFNPlhkV+q04bqTxSbMOvBhNoLUmLmL7kgfLXqg400GmYixtOLnmdP3fnDYojUzJdimTMyGn8NiuOLnayMTLfBeqvxSEUyCfV0Bu/erZzXKToDkYl/osgriLkDyfmc/4Fr9nignvrQTkFunQrlQdzAljMdMY5vbDlRXfk57Y2umnJcVmCE9oVzi6Cy0pUKY/qBIjF3CfXpOgHNr4AwuYlABCQXTwnqR00gyPsKHDHZJBd9P3LMjivN2g81iPz6pU3rjjup0dzc/WesKDVjkkOWpWw4UUTtB8XmonXav0BS1/NOwmGX8qkpsmevZW1TNR38gw7aQE60VzbgwmK/X8lF/Uv2BvaSz655OKqDzy7eLwuZ++T5Dc9u0dbJv2t6wkOaFp8sM3uXHIkM7nS3W7NbkxHofBS3SwA5FAWnDK6P9xch0pVQT4duvWiFeasn3z8dpxIksnOt3PREyvIdhUlEtXJqCa9EGaVyY0pHkhjwhXFS17FfIwxewY34LvlggSqeTUJBMCt4N2BEnkFdRnOONOc0ghmLCrtjvOdHjc21phHFSV90SDQD9QriA3OKyvDnEQwtAAncgc9LaMivGIqf5U5qDEqbUrQTy3+BNgRpWp8Pjs3w5/Oiw3gZo17HGlJPDB2DbTui+DqmuajtKaQca0wuxCahFybcjK5ph42hK+54nm31CJGA1nbSaspGiG4jrGANTkNGSaDGrjiEIwuS3EXRp9oRuUBkNii0cjONdk5q3m4ovrz45SBlZWYIz65+69wipRQ4b3ktguLyDLEeuy3YpQPBjOjJwGYsIqjPREdDO1WVjfquCxTs7 C3aBVdGf yzYU59v4QFtcvq9b0kNRdjL7JSyA5qdn5O2oouC0ymP6P1MC0HFEzCIErPo2tLCL8KNe8XBzyKvBrAjuFo51x1DpeOJ8PjnwdP2EUcDe+TXUDWSO/lGWy9+7QVlbKIngu8g+ME7Y4lpXGYMExYkKQywAtpoMNHrsLe9sQqIcYVPpJELP0uoSh+wanNP6KsZVzXhx3n8YTyGMWRhsjK4bM0f6GpBRgqhVmPJ+e4EHu2iNiOsG3hX2DWipJqgkSRHjrxI6okhHizi5hc4vjOd2BJFvbxi6Re3EWmxa+jftABg95gGyP3fkH8NgFIM6DtT0HU5w8 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: List-Subscribe: List-Unsubscribe: On Thu, Sep 05, 2024 at 02:57:34PM +0200, David Hildenbrand wrote: > On 05.09.24 14:50, Andy Shevchenko wrote: > > On Thu, Sep 05, 2024 at 02:42:05PM +0200, David Hildenbrand wrote: > > > On 05.09.24 14:36, Andy Shevchenko wrote: > > > > On Thu, Sep 05, 2024 at 01:08:35PM +0200, David Hildenbrand wrote: > > > > > On 05.09.24 12:56, Andy Shevchenko wrote: > > > > > > On Wed, Sep 04, 2024 at 04:58:20PM -0700, Dan Williams wrote: > > > > > > > Huang, Ying wrote: > > > > > > > > Andy Shevchenko writes: [..] > > > > > > > > > You may move Cc list after '---', so it won't unnecessarily pollute the commit > > > > > > > > > message. > > > > > > > > > > > > > > > > Emm... It appears that it's a common practice to include "Cc" in the > > > > > > > > commit log. > > > > > > > > > > > > > > Yes, just ignore this feedback, it goes against common practice. Cc list > > > > > > > as is looks sane to me. > > > > > > > > > > > > It seems nobody can give technical arguments why it's better than just keeping > > > > > > them outside of the commit message. Mantra "common practice" nowadays is > > > > > > questionable. > > > > > > > > > > Just look at how patches look like in the git tree that Andrew picks up. > > > > > (IIRC, he adds a bunch of CCs himself that are not even part of the original > > > > > patch). > > > > > > > > I know that and it's historical, he has a lot of the scripts that work and when > > > > he moved to the Git it was another long story. Now you even can see how he uses > > > > Git in his quilt approach. So, it's an exceptional and not usual workflow, hence > > > > bad example. Try again :-) > > > > > > Point is, it doesn't matter what we do in this patch here if Andrew will > > > unify it at all. > > > > Point is, that this is exceptional. And better to teach people based on better > > practices, no? > > "Better" in your opinion. > I don't care Exactly, that's what I pointed out as well to the previous reply to Dan: it's matter of our care about number of things. > about a couple of Cc lines in a git > commit. They've been useful for me, apparently not for you. I hardly can imagine how _nowadays_ this may be still useful in this form. What I admit is the lore archive and Link tag is really useful. Much more than bare Cc list. > If you succeed in convincing Andrew to change it, then Andrew can fixup his > scripts to remove all of these from the patches he sends out. Maybe at some point in time. As you know he is the most conservative maintainer (from tooling or workflow perspective), so it might take time, but I'm going to do my best to convince people to look at this problem from different angles. > > > > > Having in the git tree who was actually involved/CCed can be quite valuable. > > > > > More helpful than get_maintainers.pl sometimes. > > > > > > > > First of all, there is no guarantee they _were_ involved. From this perspective > > > > having Link: tag instead has much more value and supports my side of arguments. > > > > > > Link is certainly preferable. Usually when I fix a commit, I make sure to CC > > > the people that are listed for the patch, because it at least should have > > > ended up in their mailbox. > > > > > > Often, it also helped to see if a buggy commit was at least CCed to the > > > right persons without digging through mailing list archives. > > > > How is it better than having it in lore.kernel.org in archives where you even > > see who _actually_ participated in discussion, if any? > > You might have to dig through multiple code revisions to find that out. The Link tag will refer to the one that has been applied. It keeps not less information as bare Cc list, but on top one may: 1) either put a few Link tags with versioning; 2) or refer to the previous version of the patches in the respective cover letter. > Again, I used this in the past quite successfully. > > > Again, Cc neither in the Git commit, nor in the email guarantees the people > > were involved. Having Cc in the commit just a big noise that pollutes it. > > Especially I do not understand at all Cc: mailing-list@bla.bla.bla cases. > > They are not people, they have a lot of archives besides lore.kernel.org, > > only waste of resources in all means of that. I tried to summarize that in > > the submitted patches to the documentation, that I referred earlier in this > > thread to. > > I, for my part, never add "Cc:" to patches or cover letters that refer to > mailing lists. I add these manually to my git-send-email "--cc" list. I > though Andrews script also fix that up, but I might be wrong. I see some people / scripts? still put mailing lists to the Cc list which comes as part of the commit messages. This is most odd part to me why. > Anyhow, this is a discussion to be had with Andrew, not with me, so feel > free to engage with Andrew to change is scripts to throw away all CC. I will try, definitely. -- With Best Regards, Andy Shevchenko