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: <20091013063816.GB9470@elte.hu>
Date:	Tue, 13 Oct 2009 08:38:16 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Brice Goglin <Brice.Goglin@...ia.fr>
Cc:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	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


* Brice Goglin <Brice.Goglin@...ia.fr> wrote:

> Ingo Molnar wrote:
> > * Jason Gunthorpe <jgunthorpe@...idianresearch.com> wrote:
> >
> >   
> >> On Mon, Oct 12, 2009 at 08:19:44PM +0200, Ingo Molnar wrote:
> >>
> >>     
> >>>> 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." ;-)
> >>>       
> >> It can't OOM once the ummunotify registration is done - when an event 
> >> occurs it doesn't allocate any memory and it doesn't loose events.
> >>     
> >
> > Well, it has built-in event loss via the UMMUNOTIFY_FLAG_HINT mechanism: 
> > any double events on the same range will cause an imprecise event to be 
> > recorded and cause the loss of information.
> >   
> 
> The target (MPI) application doesn't care about how many events are 
> coming here. It just needs to know whether something has been 
> invalidated in the range. If so, it destroy the whole RDMA window 
> anyway. So it's actually _good_ that multiple events are merged into a 
> single one: the application only has to process a single event per 
> partially-invalidated range.

it's not unconditionally good as the fuzzy-merge-events rule:

                        events[n].flags      = UMMUNOTIFY_EVENT_FLAG_HINT;
                        events[n].hint_start = max(reg->start, reg->hint_start);
                        events[n].hint_end   = min(reg->end, reg->hint_end);

in essence merges flushes into a single interval - which inevitably 
might include areas of memory that were not flushed at all.

For example these two flushes:

  [...]          [...]

Would be merged into:

  [..................]

Btw., isnt the above max/min logic buggy, causing lost events? Shouldnt 
it be:

                        events[n].hint_start = min(reg->start, reg->hint_start);
                        events[n].hint_end   = max(reg->end, reg->hint_end);

?

	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/