From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034902AbcIWOmI (ORCPT ); Fri, 23 Sep 2016 10:42:08 -0400 Received: from mail-yw0-f193.google.com ([209.85.161.193]:32864 "EHLO mail-yw0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1034684AbcIWOmH (ORCPT ); Fri, 23 Sep 2016 10:42:07 -0400 Date: Fri, 23 Sep 2016 10:42:02 -0400 From: Tejun Heo To: zijun_hu Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, zijun_hu@htc.com, mingo@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, mgorman@techsingularity.net Subject: Re: [PATCH 1/1] lib/ioremap.c: avoid endless loop under ioremapping page unaligned ranges Message-ID: <20160923144202.GA31387@htj.duckdns.org> References: <57E20A69.5010206@zoho.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57E20A69.5010206@zoho.com> User-Agent: Mutt/1.7.0 (2016-08-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Wed, Sep 21, 2016 at 12:19:53PM +0800, zijun_hu wrote: > From: zijun_hu > > endless loop maybe happen if either of parameter addr and end is not > page aligned for kernel API function ioremap_page_range() > > in order to fix this issue and alert improper range parameters to user > WARN_ON() checkup and rounding down range lower boundary are performed > firstly, loop end condition within ioremap_pte_range() is optimized due > to lack of relevant macro pte_addr_end() > > Signed-off-by: zijun_hu Unfortunately, I can't see what the points are in this series of patches. Most seem to be gratuitous changes which don't address real issues or improve anything. "I looked at the code and realized that, if the input were wrong, the function would misbehave" isn't good enough a reason. What's next? Are we gonna harden all pointer taking functions too? For internal functions, we don't by default do input sanitization / sanity check. There sure are cases where doing so is beneficial but reading a random function and thinking "oh this combo of parameters can make it go bonkers" isn't the right approach for it. We end up with cruft and code changes which nobody needed in the first place and can easily introduce actual real bugs in the process. It'd be an a lot more productive use of time and effort for everyone involved if the work is around actual issues. Thanks. -- tejun