Re: [PATCH 0/3] Volatile Ranges (v11)

[Jan Kara]

On Thu 20-03-14 10:09:54, Minchan Kim wrote:
> Hello,
> 
> On Wed, Mar 19, 2014 at 11:12:02AM +0100, Jan Kara wrote:
> > 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 <minchan@xxxxxxxxxx> 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.
> 
> Plaes think following usecase.
> 
> Let's assume big volatile cacne.
> If there is request for cache, it should find a object in a cache
> and if it found, it should call vrange(NOVOLATILE) right before
> passing it to the user and investigate it was purged or not.
> If it wasn't purged, cache manager could pass the object to the user.
> But it's circular cache so if there is no request from user, cache manager
> always overwrites objects so it could encounter SIGBUS easily
> so as current sematic, cache manager always should call vrange(NOVOLATILE)
> right before the overwriting. Otherwise, it should register SIGBUS handler
> to unmark volatile by page unit. SIGH.
> 
> If we support VRANGE_ZERO, cache manager could overwrite object without
> SIGBUS handling or vrange(NOVOLATILE) call. Just need is vrange(NOVOLATILE)
> call while cache manager pass it to the user.
  OK, that makes some sense but I don't think we have to implement this
functionality in the beginning...
								Honza
-- 
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/