On Mon, Jun 15, 2020 at 07:01:00AM -0700, Bart Van Assche wrote: > 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. Sounds ok. > - 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. While this sounds useful I think it might very well break existing use cases.
