Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 21 Apr 2020 11:16:29 -0400
From:   Peter Xu <peterx@redhat.com>
To:     Michal Hocko <mhocko@kernel.org>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm, mempolicy: fix up gup usage in lookup_node
Message-ID: <20200421151629.GG420399@xz-x1>
References: <20200421071026.18394-1-mhocko@kernel.org>
 <20200421132916.GE420399@xz-x1>
 <20200421144603.GI27314@dhcp22.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20200421144603.GI27314@dhcp22.suse.cz>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Apr 21, 2020 at 04:46:03PM +0200, Michal Hocko wrote:
> I thought I have explained that when we have discussed last time and the
> changelog is explaining that as well. Checking for impossible error code
> is simply confusing and provokes for copy&pasting this pattern. I
> wouldn't really bother if I haven't seen this cargo cult pattern in the
> so many times.

It's just my poor habit to avoid churns like this.  Say, if the check is not
there, I definitely shouldn't add that check without explicit reason.  However
if it's there already (and it's not an extremely hot path so no number to show
that it will bring any performance impact), then I won't touch it either
without a good reasoning.  "Somebody could copy & paste the same code" isn't a
reason to me - that's something we can observe when reviewing a patch.

I've broken some code due to some tiny trivial small changes that I thought
won't hurt, and I've also been debugging for hours due to some "should be
trivial" patches from others.  This is how the habit comes...

But it's not a strong opinion either.  I'd be fine if the patch is liked by
others and Andrew would like to queue it.

Thanks,

-- 
Peter Xu