On 2020-06-15 04:52, Christoph Hellwig wrote: > I don't think the configurability makes any sense. We need to put > a hard upper cap on, preferably one that doesn't break widely used > userspace. Just pick a reasonable large value to get started. Hi Christoph, Something that has not been mentioned in the patch description is that this patch addresses an issue that was discovered by syzbot. Do you agree that the following changes are useful on top of a hard upper limit for the blktrace buffer and that these changes will address more potential syzbot issues? - Use __GFP_ACCOUNT in the relay_open() call that allocates blktrace buffers such that the memory allocation is accounted to a process and such that the OOM killer becomes aware of blktrace buffer allocations. - Making blkdev_close(), raw_release() and sg_release() shut down tracing in case the BLKTRACETEARDOWN ioctl has not been invoked. That will cause the blktrace buffers to be freed when e.g. the process that owns these buffers is killed. Thanks, Bart.
