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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ