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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150417151259.GA16743@htj.duckdns.org>
Date:	Fri, 17 Apr 2015 11:12:59 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	xiaoming.wang@...el.com,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Mel Gorman <mgorman@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] proc: move the adding option Ngid to the end of
 proc/PID/status

On Fri, Apr 17, 2015 at 06:05:55PM +0300, Alexey Dobriyan wrote:
> Moving Ngid to the end of file minimizes risk of breakage.

Hmmm... how so?  The only reason for changing the position is because
there's this specific breakage.  The goal should be working around
that specific case while keeping the impact minimum on everyone else.
It doesn't matter whether the initial change was good or bad, the
kernel w/ the new layout is already out in the wild and it has been
out there for a while.  How is risking changing offsets on most of the
fields on those kernels a good idea?  Mimize the changes to work
around the specific case.

> Correctly written code doesn't care.
> Code which hardcodes layout won't notice.

Huh?  Code which hardcodes layout since 1.5 years ago will definitely
notice.

> It would be OK argument if gentlemen from Intel send "let's futureproof and
> move Ngid because someone might depend on exact position" patch.
> 
> Primum non nocere.

ajlkjaeligjlakd lakjeilgjal flekjfa.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ