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 <minc...@kernel.org> 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.
Honza
--
Jan Kara <j...@suse.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
