linux-kernel - Re: [PATCH] scripts/checksyscalls.sh: only whine perf_counter

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:	Sun, 14 Jun 2009 19:11:11 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Mike Frysinger <vapier.adi@...il.com>
Cc:	akpm <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scripts/checksyscalls.sh: only whine perf_counter_open when supported

On Sun, Jun 14, 2009 at 05:55:44AM -0400, Mike Frysinger wrote:
> On Sun, Jun 14, 2009 at 05:37, Paul Mundt wrote:
> > On Sat, Jun 13, 2009 at 06:48:52AM -0400, Mike Frysinger wrote:
> >> On Fri, Jun 12, 2009 at 07:29, Mike Frysinger wrote:
> >> > If the port does not support HAVE_PERF_COUNTERS, then they can't support
> >> > the perf_counter_open syscall either. ??Rather than forcing everyone to add
> >> > an ignore (or suffer the warning until they get around to implementing
> >> > support), only whine about the syscall when applicable.
> >> >
> >> > Signed-off-by: Mike Frysinger <vapier@...too.org>
> >>
> >> Andrew: could you pick this up since Ingo acked it now ?
> 
> btw, Sam said he would pick it up via the kbuild tree
> 
> > I fail to see why this is necessary? cond_syscall() takes care of this in
> > the not implemented case, the same as every other syscall backing some
> > feature that has yet to be implemented.
> 
> i dont think we should go hassling every arch maintainer when a new
> syscall is added that requires arch-specific support for optional
> features (especially when said features are debug in nature).  if
> wiring up the syscall is the only work because the code is all common
> (like the pread/pwrite functions), then np of course.

Perhaps not, but I do prefer to have the script whine at me when a new
syscall pops up, just so I know when I have to start caring about a new
feature. New syscalls that are handled by cond_syscall() are trivially
dropped in to the syscall table to get rid of these warnings, regardless
of whether you have any intention of really supporting the feature or
not. If a generic implementation becomes available, then it can be
supported without having to backtrack and update place-holders.

These are not things I want to see silenced just because you don't
presently feel compelled to wire up the entry on your platform.

The fact the perf counter stuff has no real generic support, or even the
present infrastructure to support it on pretty much every 32-bit platform
that isn't x86 is more an issue with -tip development methodology than
anything to do with the syscall bits.

Of course if it had been handled properly then the generic software
counters would have been actually implemented generically and
subsequently made available from the stub and the HAVE_xxx would be
reserved for architecture-specific counters. Unfortunately these days
"generic" generally seems to imply "can be made generic if someone else
bothers to actually do the work, assuming they can find any documentation
in the first place".
--
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/