linux-kernel - Re: [PATCH v1 1/1] libnvdimm/labels: Get rid of redundant 'else'

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: <aRGncoEEcbq_D6mV@smile.fi.intel.com>
Date: Mon, 10 Nov 2025 10:50:58 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Alison Schofield <alison.schofield@...el.com>
Cc: Ira Weiny <ira.weiny@...el.com>, nvdimm@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	Dan Williams <dan.j.williams@...el.com>,
	Vishal Verma <vishal.l.verma@...el.com>,
	Dave Jiang <dave.jiang@...el.com>
Subject: Re: [PATCH v1 1/1] libnvdimm/labels: Get rid of redundant 'else'

On Sun, Nov 09, 2025 at 02:11:54PM -0800, Alison Schofield wrote:
> On Fri, Nov 07, 2025 at 10:23:32AM -0600, Ira Weiny wrote:
> > 
> > Yea putting this in the commit message but more importantly knowing you
> > looked through the logic of how claim class is used is what I'm looking
> > for.
> 
> Coming back around to this patch after a few days, after initially
> commenting on the unexplained behavior change, I realize a better
> response would have been a simple NAK.
> 
> This patch demonstrates why style-only cleanups are generally discouraged
> outside of drivers/staging. It creates code churn without fixing bugs
> or adding functionality, the changes aren't justified in the commit
> message, it adds risk, and consumes limited reviewer and maintainer
> bandwidth.
> 
> To recoup value from the time already spent on this, I suggest using
> this opportunity to set a clear position and precedent, like:
> 
> 	"Style cleanups are not welcomed in the NVDIMM subsystem unless
> 	they're part of a fix or a patch series that includes substantive
> 	changes to the same code area."

Let's rotten it with the old APIs and style then :-)

I have heard you and I won't try even bring any new patch in this subsystem, thanks.

> FWIW, if folks are looking to dive into this code, there is a patchset
> in review here[1] that adds new functionality to this area. Reviews,
> including style reviews, are welcomed.
> 
> Regardless of a commit message update or a change to the code, this
> one is a NAK from me.
> 
> [1] https://lore.kernel.org/nvdimm/20250917132940.1566437-1-s.neeraj@samsung.com/

-- 
With Best Regards,
Andy Shevchenko