Re: [PATCH v2] blktrace: put bounds on BLKTRACESETUP buf_size and buf_nr

[Bart Van Assche <bvanassche@acm.org>]

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.