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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 7 Nov 2013 16:55:44 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Vince Weaver <vince@...ter.net>
Cc:	Peter Zijlstra <peterz@...radead.org>, hpa@...or.com,
	anton@...ba.org, mathieu.desnoyers@...ymtl.ca,
	linux-kernel@...r.kernel.org, michael@...erman.id.au,
	paulmck@...ux.vnet.ibm.com, benh@...nel.crashing.org,
	fweisbec@...il.com, VICTORK@...ibm.com, tglx@...utronix.de,
	oleg@...hat.com, mikey@...ling.org,
	linux-tip-commits@...r.kernel.org,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Jiri Olsa <jolsa@...hat.com>,
	Namhyung Kim <namhyung@...nel.org>,
	David Ahern <dsahern@...il.com>
Subject: Re: [tip:perf/core] tools/perf: Add required memory barriers


* Vince Weaver <vince@...ter.net> wrote:

> On Thu, 7 Nov 2013, Ingo Molnar wrote:
> 
> > I don't want a library that is external and under-tested: for example 
> > quite a few of the PAPI breakages were found very late, after a new 
> > kernel has been released - that's the big disadvantage of 
> > librarization and decentralization. The decentralized library model 
> > might work if all you want to create is a second-class also-ran GUI, 
> > but it just doesn't work very well for actively developed kernel code.
> 
> I would argue that PAPI's problem was because it was trying to use 
> perf_event_open() which is a complex, poorly documented kernel interface 
> with a lot of code churn.  Usually it's the job of the kernel not to 
> break user-space, not the other way around.

As Linus said it on the Kernel Summit: breakages that don't get reported 
or don't get noticed essentially don't exist. We can only fix what gets 
reported in time.

> It's too late on the decentralized library issue.  PAPI has to support 
> kernels going back to 2.6.32 so it's going to have its own copy of the 
> mmap parsing code even if a new syscall gets introduced.
> 
> There are a lot of tools out there now that open-code a perf_event 
> interface.  I don't think it's really possible to say "anyone using the 
> syscall without using our kernel library is unsupported".

I'm not saying that at all - but you appear to expect perfect kernel code 
and fixes done before you report them: that's an impossible expectation.

It's your choice to live outside the space that we readily test and it's 
your choice to not test your bits with a new kernel in time. Others do not 
test your code with -rc kernels, they don't report the bugs, so some bugs 
that affect the PAPI library go unnoticed. Yet you try to blame it on us, 
which is really backwards ...

Thanks,

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