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

From: harshad shirwadkar <harshadshirwadkar@gmail.com>
To: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>, shakeelb@google.com
Cc: Bart Van Assche <bvanassche@acm.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH v2] blktrace: put bounds on BLKTRACESETUP buf_size and buf_nr
Date: Fri, 12 Jun 2020 17:57:29 -0700	[thread overview]
Message-ID: <CAD+ocbxsxMCCvW6=ckNtaFoJaGv8CZbbYX7_szhaWESUBs3oTA@mail.gmail.com> (raw)
In-Reply-To: <BYAPR04MB4965B7894160F6EE0861D2A6869E0@BYAPR04MB4965.namprd04.prod.outlook.com>

Thanks for the feedback Chaitanya and Bart.

In an offline sync-up with Shakeel and Bart, Shakeel mentioned that
probably doing the GFP_ACCOUNT is the right approach as long as the
trace buffer allocation lifetime can be tied with the process
lifetime. Given that, we can drop this patch for now. Whenever I get
time, I'll try to submit a new patch with that handled.

On Fri, Jun 12, 2020 at 5:09 PM Chaitanya Kulkarni
<Chaitanya.Kulkarni@wdc.com> wrote:
>
> > Is this the wrong structure to add a limit like blktrace_max_alloc? As
> > far as I can see struct queue_limits is only used for limits that are
> > affected by stacking block devices. My understanding is that the
> > blktrace_max_alloc limit is not affected by device stacking. See also
> > blk_stack_limits().
>
> I can also see that, how about adding a parameter in
> struct request_queue under CONFIG_BLK_DEV_IO_TRACE if we are going that
> route ?
>