svn commit: r316311 - in head: lib/libstand sys/boot/geli sys/boot/i386/gptboot sys/boot/i386/loader sys/boot/i386/zfsboot

[Konstantin Belousov]

On Tue, Jun 06, 2017 at 03:51:26PM +0200, Hans Petter Selasky wrote:
> On 03/31/17 02:04, Allan Jude wrote:
> > Author: allanjude
> > Date: Fri Mar 31 00:04:32 2017
> > New Revision: 316311
> > URL: https://svnweb.freebsd.org/changeset/base/316311
> > 
> 
> 
> > 
> > Modified: head/sys/boot/i386/zfsboot/zfsboot.c
> > ==============================================================================
> > --- head/sys/boot/i386/zfsboot/zfsboot.c	Thu Mar 30 23:49:57 2017	(r316310)
> > +++ head/sys/boot/i386/zfsboot/zfsboot.c	Fri Mar 31 00:04:32 2017	(r316311)
> > @@ -926,7 +926,7 @@ load(void)
> >       zfsargs.primary_pool = primary_spa->spa_guid;
> >   #ifdef LOADER_GELI_SUPPORT
> >       bcopy(gelipw, zfsargs.gelipw, sizeof(zfsargs.gelipw));
> > -    bzero(gelipw, sizeof(gelipw));
> > +    explicit_bzero(gelipw, sizeof(gelipw));
> >   #else
> >       zfsargs.gelipw[0] = '\0';
> >   #endif
> > 
> 
> Hi Allan,
> 
> For ARM platforms you'll need to do a write memory barrier before the 
> explicit_bzero() returns, else the memory can be recovered by 
> invalidating the memory area by the next thread which is allocating this 
> memory ???
Note that loader execution is single threaded / single core.  As is,
it is not possible for the cache invalidation targeting the generic memory 
in loader to occur.

That said, if we consider usage of the explicit_bzero() in more complete
environment, then a memory barrier is definitely useless for the stated
purpose. After the writing thread issued a barrier, cache is not flushed
to RAM. In other words, cache flush is probably worth doing there, as
you noted.

But this raises a question, shouldn't the explicit_bzero() implementation
handle the cache flush ?