linux-kernel - Re: [PATCHv2 4.3-rc6] proc: fix convert from oom_score_adj to oom

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]

Date:	Tue, 27 Oct 2015 13:37:04 +0100
From:	Michal Hocko <mhocko@...nel.org>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Hongjie Fang (方洪杰) 
	<Hongjie.Fang@...eadtrum.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv2 4.3-rc6] proc: fix convert from oom_score_adj to oom_adj

On Mon 26-10-15 14:42:57, David Rientjes wrote:
> On Thu, 22 Oct 2015, Hongjie Fang (方洪杰) wrote:
> 
> > 
> > The oom_adj has been replaced by oom_score_adj in kernel,
> > but the /proc/pid/oom_adj is provided for legacy purposes.
> > When write/read a value into/from /proc/pid/oom_adj,
> > there is a transformation between oom_adj and oom_score_adj.
> > 
> > After writing a new value into /proc/pid/oom_adj, then read it.
> > The return value is a different value than you wrote.
> > Fix this by adding a adjustment factor.
> > 
> 
> You're only looking at the output and seeing that it disagrees with what 
> was written and ignoring _why_ it disagrees.
> 
> It's because, as I already stated, oom_score_adj is the effective tunable 
> for oom kill process prioritization and the legacy oom_adj had a different 
> scale where a 1:1 mapping is not possible.
> 
> All throughout the kernel, we report the effective value.  We accept 
> writes and the reads report the effective value.  This is no different.
> 
> Nack again.

I really fail to understand your reasoning. The patch basically fixes up
the presented value of oom_adj after rounding imprecision. It doesn't
change the way how the oom_adj->oom_score_aj mapping is done at all. All
it does is that it presents oom_adj1 -> oom_score_adj -> oom_adj2 and
oom_adj1 = oom_adj2

How can this be any harmful? And more importantly why do you want to
expose the imprecision in the mapping to the user space in the first
place?
-- 
Michal Hocko
SUSE Labs
--
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/