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]
Date:	Tue, 21 Apr 2015 11:11:19 -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 Tue, Apr 21, 2015 at 05:00:07PM +0300, Alexey Dobriyan wrote:
> > 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.
> 
> If there are TWO incorrect parsers, one for TracerPid, another for Ngid,
> you CAN'T workaround it. And if you can't workaround you choose code
> which was written first, namely, TracerPid one.

Not when the code has been out for 1.5 years.  Minimizing the
disturbance is the better course of action.  Look at the file.  If you
move ngid to the end now, it's gonna shift most of the file content,
which is what caused the problem in the first place.

We don't know what's out there which again was the same problem which
triggered this thread in the first place.  Why would you take the same
amount of risk when you can fix the known issue with less amount of
changes?  Just put ngid after tracerpid.  That way, we can fix the
known problems while changing the offsets of only four fields.  At
this point, no change to the file layout is "right".  Such thing isn't
defined regardless of who came first.  The only thing we can do is
working around the known cases while minimizing possible impacts.

Thanks.

-- 
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