linux-kernel - Re: [PATCH 1/5] mm: compaction: Remove redundant VM_BUG_ON() in compact

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20230111135144.5be220426ef4c0cae0a3429d@linux-foundation.org>
Date:   Wed, 11 Jan 2023 13:51:44 -0800
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Baolin Wang <baolin.wang@...ux.alibaba.com>
Cc:     Matthew Wilcox <willy@...radead.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/5] mm: compaction: Remove redundant VM_BUG_ON() in
 compact_zone()

On Wed, 11 Jan 2023 14:40:20 +0800 Baolin Wang <baolin.wang@...ux.alibaba.com> wrote:

> 
> 
> On 1/11/2023 7:37 AM, Matthew Wilcox wrote:
> > On Tue, Jan 10, 2023 at 03:25:32PM -0800, Andrew Morton wrote:
> >> On Tue, 10 Jan 2023 13:37:57 +0000 Matthew Wilcox <willy@...radead.org> wrote:
> >>
> >>> On Tue, Jan 10, 2023 at 09:36:18PM +0800, Baolin Wang wrote:
> >>>> The compaction_suitable() will never return values other than COMPACT_SUCCESS,
> >>>> COMPACT_SKIPPED and COMPACT_CONTINUE, so after validation of COMPACT_SUCCESS
> >>>> and COMPACT_SKIPPED, we will never hit other unexpected case. Thus remove
> >>>> the redundant VM_BUG_ON() validation for the return values of compaction_suitable().
> >>>
> >>> I don't understand why we'd remove this check.
> >>
> >> Well, just from code inspection it serves no purpose.
> >>
> >> Such an assertion might be useful during early code development, but I
> >> think we can consider compaction_suitable() to adequately debugged by
> >> now?
> > 
> > What if compaction_suitable() is modified to return another value?
> 
> Then this will be an expected value which should be handled by caller, 
> and IMO we can not make such assumption for future to keep this 
> unhelpful check.

One way of looking at this: if the assertion wasn't there and someone
sent a patch which added it, would we merge the patch?

"[patch] add check for compaction_suitable() return value"

"why"

"it might be wrong"

"it isn't"

"but we might make it wrong later"

"the same can be said of every function in the kernel"


And if we wouldn't merge a hypothetical patch which adds some code, we
shouldn't retain that code, no?