Re: [PATCH 1/2] block: shutdown blktrace in case of fatal signal pending

[Ming Lei]

On Sat, Apr 03, 2021 at 04:10:16PM +0800, Ming Lei wrote:
> On Fri, Apr 02, 2021 at 07:27:30PM +0200, Christoph Hellwig wrote:
> > On Wed, Mar 31, 2021 at 08:16:50AM +0800, Ming Lei wrote:
> > > On Tue, Mar 30, 2021 at 06:53:30PM +0200, Christoph Hellwig wrote:
> > > > On Tue, Mar 23, 2021 at 04:14:39PM +0800, Ming Lei wrote:
> > > > > blktrace may allocate lots of memory, if the process is terminated
> > > > > by user or OOM, we need to provide one chance to remove the trace
> > > > > buffer, otherwise memory leak may be caused.
> > > > > 
> > > > > Fix the issue by shutdown blktrace in case of task exiting in
> > > > > blkdev_close().
> > > > > 
> > > > > Signed-off-by: Ming Lei <ming.lei@xxxxxxxxxx>
> > > > 
> > > > This just seems weird.  blktrace has no relationship to open
> > > > block device instances.
> > > 
> > > blktrace still needs to open one blkdev, then send its own ioctl
> > > commands to block layer. In case of OOM, the allocated memory in
> > > these ioctl commands won't be released.
> > > 
> > > Or any other suggestion?
> > 
> > Not much we can do there I think.  If we want to autorelease memory
> > it needs to be an API that ties the memory allocation to an FD.
> 
> We still may shutdown blktrace if current is the last opener, otherwise
> new blktrace can't be started and memory should be leaked forever, and
> what do you think of the revised version?

This way seems not good enough, another better one is to use
file->private_data for such purpose since blkdev fs doesn't use
file->privete_data, then we can shutdown blktrace just for the
blktrace FD: