> Problem: a block device driver (e.g. ramdisk) can go on
That's only an issue for the ramdisk driver. It's very special.
> Let us maintain an array of bitmaps, one per each device minor,
> with all bits cleared initially. Then, in rd_request() we set a bit
> on WRITE and calculate the "hamming weight" over all minors and if
> that exceeds some preset maximum (based on nr_free_pages or specified
> as MODULE_PARM) then we end_request(0). We need a bitmap and not a simple
There's no way you can rely on a fixed MODULE_PARAM info to avoid going
oom in the case where the admin is doing the wrong thing.
> count because we can WRITE the same block multiple times.
With my fix for the dirty-oom bug (different (more serious) issue), you
will know how much protected data is allocated in memory all the time. You
don't need any bitmap to know how much memory is allocated for all ramdisk
minors (all further writes won't be accounted).
>Now, the problem with the above is that once the maximum is reached the
>driver will be completely "stuck". This can be overcome thus: a new ioctl
There is a more serious issue that you assume as easy to solve:
how do you know when the ramdisk driver should stop working?
You should tell the ramdisk driver "stop allocating memory" when the
_buffer_ allocation fails, and at buffer allocation time the buffer is
still freeable (innocent) and even worse getblk is just an oom-deadlock
prone thing even without ramdisk involved.....
The point is that you can't just look at the number of free pages and look
at how many pages are in the page-LRU queue inside the request callback to
know if the system is oom or not. Only after a failed allocation you could
choose to say "ok, this is real OOM and so the ramdisk driver must stop
working". Otherwise you risk to overstimate or understimate, because you
don't know how much of the allocated memory is freeable or swappable.
And only stopping generating protected data can be not enough to avoid a
deadlock.
And stopping working if there we are low on memory would imply that a
malicious memory-hog launced by an luser during the ramdisk construction,
could potentially generate fs corruption on the ramdisk.
>is provided that invalidates buffers for a given minor. The current
>invalidate_buffers() cannot do that but it should be possible to write a
>invalidate_buffers_minor() (same, just a different test before "continue"?).
invalidate_buffers just works per minor basis. You can just say flushb
/dev/ram0 and only release the memory for the 0 ramdisk minor.
>What think ye?
Any fix I can think of, looks worse than the missing check itself 8)
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/