linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Michal Hocko <mhocko@kernel.org>, riel@redhat.com
Cc: linux-kernel@vger.kernel.org, mike.kravetz@oracle.com,
	linux-mm@kvack.org, colm@allcosts.net, akpm@linux-foundation.org,
	keescook@chromium.org, luto@amacapital.net, wad@chromium.org,
	mingo@kernel.org, kirill@shutemov.name, dave.hansen@intel.com,
	linux-api@vger.kernel.org
Subject: Re: [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK
Date: Mon, 7 Aug 2017 16:19:18 +0200	[thread overview]
Message-ID: <134bbcf4-5717-7f53-0bf1-57158e948bbe@redhat.com> (raw)
In-Reply-To: <20170807134648.GI32434@dhcp22.suse.cz>

On 08/07/2017 03:46 PM, Michal Hocko wrote:
> How do they know that they need to regenerate if they do not get SEGV?
> Are they going to assume that a read of zeros is a "must init again"? Isn't
> that too fragile?

Why would it be fragile?  Some level of synchronization is needed to set
things up, of course, but I think it's possible to write a lock-free
algorithm to maintain the state even without strong guarantees of memory
ordering from fork.

In the DRBG uniqueness case, you don't care if you reinitialize because
it's the first use, or because a fork just happened.

In the API-mandated fork check, a detection false positive before a fork
is not acceptable (because it would prevent legitimate API use), but I
think you can deal with this case if you publish a pointer to a
pre-initialized, non-zero mapping.

Thanks,
Florian

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-08-07 14:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170806140425.20937-1-riel@redhat.com>
2017-08-07 13:22 ` [PATCH v2 0/2] mm,fork,security: introduce MADV_WIPEONFORK Michal Hocko
     [not found]   ` <20170807132257.GH32434-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-08-07 13:46     ` Michal Hocko
2017-08-07 14:19       ` Florian Weimer [this message]
2017-08-10 13:06         ` Michal Hocko
2017-08-07 14:59       ` Rik van Riel
     [not found]         ` <1502117991.6577.13.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-08-09  9:59           ` Kirill A. Shutemov
2017-08-09 12:31             ` Rik van Riel
2017-08-09 12:42             ` Florian Weimer
2017-08-10 13:05         ` Michal Hocko
     [not found]           ` <20170810130531.GS23863-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-08-10 13:23             ` Colm MacCárthaigh
     [not found]               ` <CAAF6GDc2hsj-XJj=Rx2ZF6Sh3Ke6nKewABXfqQxQjfDd5QN7Ug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-08-10 15:36                 ` Michal Hocko
2017-08-10 16:17                   ` Colm MacCárthaigh
     [not found]                     ` <CAAF6GDeno6RpHf1KORVSxUL7M-CQfbWFFdyKK8LAWd_6PcJ55Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-08-10 17:01                       ` Michal Hocko
     [not found]                         ` <20170810170144.GA987-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-08-10 22:09                           ` Colm MacCárthaigh
     [not found]                             ` <CAAF6GDdFjS612mx1TXzaVk1J-Afz9wsAywTEijO2TG4idxabiw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-08-11 14:06                               ` Michal Hocko
     [not found]                                 ` <20170811140653.GO30811-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-08-11 14:11                                   ` Florian Weimer
     [not found]                                     ` <c8cda773-b28d-f35f-7f18-6735584cb173-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-08-11 14:24                                       ` Michal Hocko
     [not found]                                         ` <20170811142457.GP30811-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-08-11 15:24                                           ` Florian Weimer
2017-08-11 15:31                                             ` Michal Hocko
2017-08-07 15:55       ` Colm MacCárthaigh
2017-08-07 16:02         ` Colm MacCárthaigh
2017-08-10 13:21         ` Michal Hocko
2017-08-10 14:11           ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=134bbcf4-5717-7f53-0bf1-57158e948bbe@redhat.com \
    --to=fweimer@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=colm@allcosts.net \
    --cc=dave.hansen@intel.com \
    --cc=keescook@chromium.org \
    --cc=kirill@shutemov.name \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@amacapital.net \
    --cc=mhocko@kernel.org \
    --cc=mike.kravetz@oracle.com \
    --cc=mingo@kernel.org \
    --cc=riel@redhat.com \
    --cc=wad@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).