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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 19 Mar 2014 11:12:02 +0100
From:	Jan Kara <>
To:	Minchan Kim <>
Cc:	John Stultz <>,
	LKML <>,
	Andrew Morton <>,
	Android Kernel Team <>,
	Johannes Weiner <>,
	Robert Love <>, Mel Gorman <>,
	Hugh Dickins <>, Dave Hansen <>,
	Rik van Riel <>,
	Dmitry Adamushko <>,
	Neil Brown <>,
	Andrea Arcangeli <>,
	Mike Hommey <>, Taras Glek <>,
	Jan Kara <>,
	KOSAKI Motohiro <>,
	Michel Lespinasse <>,
	"" <>
Subject: Re: [PATCH 0/3] Volatile Ranges (v11)

On Wed 19-03-14 09:49:18, Minchan Kim wrote:
> On Tue, Mar 18, 2014 at 11:07:50AM -0700, John Stultz wrote:
> > On Tue, Mar 18, 2014 at 8:11 AM, Minchan Kim <> wrote:
> > > 1) SIGBUS
> > >
> > > It's one of the arguable issue because some user want to get a
> > > SIGBUS(ex, Firefox) while other want a just zero page(ex, Google
> > > address sanitizer) without signal so it should be option.
> > >
> > >         int vrange(start, len, VRANGE_VOLATILE|VRANGE_ZERO, &purged);
> > >         int vrange(start, len, VRANGE_VOLATILE|VRANGE_SIGNAL, &purged);
> > 
> > So, the zero-fill on volatile access feels like a *very* special case
> > to me, since a null page could be valid data in many cases. Since
> > support/interest for volatile ranges has been middling at best, I want
> > to start culling the stranger use cases. I'm open in the future to
> > adding a special flag or something if it really make sense, but at
> > this point, lets just get the more general volatile range use cases
> > supported.
> I'm not sure it's special case. Because some user could reserve
> a big volatile VMA and want to use the range by circle queue for
> caching so overwriting could happen easily.
> We should call vrange(NOVOLATILE) to prevent SIGBUS right before
> overwriting. I feel it's unnecessary overhead and we could avoid
> the cost with VRANGE_ZERO.
> Do you think this usecase would be rare?
  If I understand it correctly the buffer would be volatile all the time
and userspace would like to opportunistically access it. Hum, but then with
your automatic zero-filling it could see half of the page with data and
half of the page zeroed out (the page got evicted in the middle of
userspace reading it). I don't think that's a very comfortable interface to
work with (you would have to very carefully verify the data you've read is
really valid). And frankly in most cases I'm afraid the application would
fail to do proper verification and crash randomly under memory pressure. So
I wouldn't provide VRANGE_ZERO unless I come across real people for which
avoiding marking the range as NONVOLATILE is a big deal and they are OK with
handling all the odd situations that can happen.

That being said I agree with you that it makes sense to extend the syscall
with flags argument so that we have some room for different modifications
of the functionality.

Jan Kara <>
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists