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]

Date:	Fri, 11 Sep 2009 09:58:10 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:	Brice Goglin <Brice.Goglin@...ia.fr>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org,
	general@...ts.openfabrics.org, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org
Subject: Re: [ofa-general] Re: [GIT PULL] please pull ummunotify


 > So.. What is the problem with fork? The semantics of what should
 > happen seem natural enough to me, the PD doesn't get copied to the
 > child, so the MR stays with the parent. COW events on the pinned
 > region must be resolved so that the physical page stays with the
 > process that has pinned it - the pin is logically released in the
 > child because the MR doesn't exist because the PD doesn't exist.

This is getting away from the problem that ummunotify is solving, but
handling a COW fault generated by the parent by doing the copy in the
child seems like a pretty major, tricky change to make.  The child may
have forked 100 more times in the meantime, meaning we now have to
change 101 memory maps ... the cost of page faults goes through the roof
probably...

 - R.
--
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/