linux-kernel - Re: [PATCH v2 2/2] fs: super.c: Add tracepoint to get name of superblock shrinker

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: <20160818063239.GO2356@ZenIV.linux.org.uk>
Date:	Thu, 18 Aug 2016 07:32:39 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Janani Ravichandran <janani.rvchndrn@...il.com>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org, riel@...riel.com,
	akpm@...ux-foundation.org, vdavydov@...tuozzo.com, mhocko@...e.com,
	vbabka@...e.cz, mgorman@...hsingularity.net,
	kirill.shutemov@...ux.intel.com, bywxiaobai@....com
Subject: Re: [PATCH v2 2/2] fs: super.c: Add tracepoint to get name of
 superblock shrinker

On Thu, Aug 18, 2016 at 02:09:31AM -0400, Janani Ravichandran wrote:

>  static LIST_HEAD(super_blocks);
> @@ -64,6 +65,7 @@ static unsigned long super_cache_scan(struct shrinker *shrink,
>  	long	inodes;
>  
>  	sb = container_of(shrink, struct super_block, s_shrink);
> +	trace_mm_shrinker_callback(shrink, sb->s_type->name);

IOW, we are (should that patch be accepted) obliged to keep the function in
question and the guts of struct shrinker indefinitely.

NAK.  Keep your debugging patches in your tree and maintain them yourself.
And if a change in the kernel data structures breaks them (and your userland
code relying on those), it's your problem.

Tracepoints are very nice for local debugging/data collection/etc. patches.
Accepting them into mainline shifts the responsibility for updating them
to the rest of us, and unlike you we can't update the userland side.

Adding a userland ABI means pledging to keep it alive pretty much indefinitely.
It's not automatically unacceptable (hell, new syscalls get added from time
to time), but it should come with a serious analysis of what's getting exposed
and it shouldn't be accepted without such.