linux-kernel - Re: [PATCH] Revert "mm: rename _count, field of the struct page, to

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: <d7049c89-7b78-ee1c-7216-90d8dd69d1b5@suse.cz>
Date:	Thu, 16 Jun 2016 11:36:47 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Vitaly Kuznetsov <vkuznets@...hat.com>, linux-mm@...ck.org
Cc:	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org, Joonsoo Kim <iamjoonsoo.kim@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Hugh Dickins <hughd@...gle.com>, Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH] Revert "mm: rename _count, field of the struct page, to
 _refcount"

On 06/16/2016 11:22 AM, Vitaly Kuznetsov wrote:
> _count -> _refcount rename in commit 0139aa7b7fa12 ("mm: rename _count,
> field of the struct page, to _refcount") broke kdump. makedumpfile(8) does
> stuff like READ_MEMBER_OFFSET("page._count", page._count) and fails. While
> it is definitely possible to fix this particular tool I'm not sure about
> other tools which might be doing the same.
>
> I suggest we remember the "we don't break userspace" rule and revert for
> 4.7 while it's not too late.

I don't think the rule applies to tools such as kdump and crash, or e.g. 
systemtap, that interact with kernel internals even though they are 
technically "userspace". They have to adapt to new kernel versions all 
the time, the internal APIs are not frozen. Otherwise we would be quite 
limited in evolving the kernel...

So even though the change in question is not essential (field rename) 
and reverting wouldn't really hurt technical progress, this is not a 
sufficient reason, IMO. Thus, NAK.

Vlastimil