linux-kernel - Re: [ofa-general] Re: [GIT PULL] please pull ummunotify

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: <20091012181944.GF17138@elte.hu>
Date:	Mon, 12 Oct 2009 20:19:44 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:	Pavel Machek <pavel@....cz>, Roland Dreier <rdreier@...co.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org,
	Paul Mackerras <paulus@...ba.org>,
	Anton Blanchard <anton@...ba.org>,
	general@...ts.openfabrics.org, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org, Jeff Squyres <jsquyres@...co.com>
Subject: Re: [ofa-general] Re: [GIT PULL] please pull ummunotify


* Jason Gunthorpe <jgunthorpe@...idianresearch.com> wrote:

> On Wed, Sep 30, 2009 at 11:44:56AM +0200, Ingo Molnar wrote:
> > > > OK.  It would be nice to tie into something more general, but I 
> > > > think I agree -- perf counters are missing the filtering and the "no 
> > > > lost events" that ummunotify does have. [...]
> > 
> > Performance events filtering is being worked on and now with the 
> > proper non-DoS limit you've added you can lose events too, dont you? 
> > So it's all a question of how much buffering to add - and with perf 
> > events too you can buffer arbitrary large amount of events.
> 
> No, the ummunotify does not loose events, that is the fundamental 
> difference between it and all tracing schemes.
> 
> Every call to ibv_reg_mr is paired with a call to ummunotify to create 
> a matching watcher. Both calls allocate some kernel memory, if one 
> fails the entire operation fails and userspace can do whatever it does 
> on memory allocation failure.

We already support signal notification for perf events, and we also 
support two modi of perf ring-buffer overflow notification. Adding a 
third one that sends a signal when events are lost would be in line with 
that.

This would allow you to have the OOM semantics of requesting a SIGBUS - 
or user-space could do other things: like print a warning in the app or 
ignore the event overflow.

Which are all interesting things to do. (If you do that you might want 
to add that to 'perf top' or 'perf record' as well.)

> After that point the scheme is perfectly lossless.

Well if it can OOM it's not lossless, obviously. You just define "event 
loss" to be equivalent to "Destruction of the universe." ;-)

	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/