cvs commit: src/sys/vm vm_kern.c

[Don Lewis]

On 16 Feb, Robert Watson wrote:
> 
> On Mon, 16 Feb 2004, Scott Long wrote:
> 
>> On Mon, 16 Feb 2004, Robert Watson wrote:
>> >
>> > On Mon, 16 Feb 2004, Dag-Erling Smorgrav wrote:
>> >
>> > >   Log:
>> > >   Don't panic if we fail to satisfy an M_WAITOK request; return 0 instead.
>> > >   The calling code will either handle that gracefully or cause a page fault.
>> >
>> > Also, this turns an easily understood and widely documented kernel panic
>> > message into a page fault.  Prior to this, users could google for the
>> > message and find documentation on increasing the size of the kernel
>> > address space.  Now, it requires facility with the source code in order to
>> > figure out what it is going on (since the page fault trace won't include
>> > the memory allocation).
>> 
>> Agreed on all points.  I thought that there was along discussion on this
>> in the last 1-2 weeks and that all of these issues were brought up. 
>> Please back this out, and lets focus on getting the sematics that you
>> need for procfs rather than just ruining the sematics for everything
>> else. 
> 
> It seems like it all comes down to the perfectly reasonable desire to be
> able to represent the following request: 
> 
>   Userspace wants me to allocate some memory.  I don't know how large
>   rediculous is, but I don't want to panic when I ask for something
>   rediculous and instead get a failure I can report.
> 
> And the origin of part of this problem is that procfs has some notions
> that are hard to implement (or impossible to implement), such as:
> 
>   You can retrieve atomically snapshotted data in fairly unbounded
>   ammounts.
> 
> That's not a property of our procfs implementation as much as a property
> of the "procfs API".

While I think an extra malloc option to get this behaviour is
reasonable, I think this is another situation where it would be better
to wire the user buffer and copy the data directly to user space.
Approximately the same amount of memory will be tied up servicing the
request in either case.

> It is useful to have some notion of the rediculous in memory allocation,
> but I don't think this is the right way to enforce it.  In the general
> case, we handle "reasonable" determination using small fixed-size or
> tunable constants, such as maximum IOVEC size, maximum processes, maximum
> mbufs, etc.  It would be very tempting to do something similar for procfs: 
> "I shall allocate no more than 256k of memory for this buffer"...

This is necessary, but probably not sufficient if the user can do a
bunch of these in parallel.


Disadvantages of doing the snapshot into a malloced kernel buffer:

	An extra copy of the data is required.

	Consumes precious kernel address space, which in some cases might
	require the kernel/user boundary to be moved, which would decrease
	the address space available to all user processes.

	The necessary lifetime of the kernel buffer may be arbitrarily
	long if the copyout is stalled by paging user memory.

	There may need to be per-user limits on the amount of memory
	consumed by these buffers to avoid DoS situations if a user
	forks a large number of processes that are all reading large
	amounts of data from procfs.

Disadvantages of doing the snapshot into a pre-wired user buffer:

	There need to be per-user limits on the amount of wired memory
	to avoid DoS situations if a user forks a large number of
	processes that are all reading large amounts of data from procfs
	or doing other things that wire memory (such as certain sysctl
	calls).