On 5/25/22 2:46 AM, Kanchan Joshi wrote:
> On Tue, May 24, 2022 at 03:37:26PM -0600, Jens Axboe wrote:
>> If the opcode only stores data that needs to be kfree'ed in
>> req->async_data, then it doesn't need special handling in
>> our cleanup handler.
>>
>> This has the added bonus of removing knowledge of those kinds of
>> special async_data to the io_uring core.
>>
>> Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
>> ---
>> fs/io_uring.c | 18 ------------------
>> 1 file changed, 18 deletions(-)
>>
>> diff --git a/fs/io_uring.c b/fs/io_uring.c
>> index 408265a03563..8188c47956ad 100644
>> --- a/fs/io_uring.c
>> +++ b/fs/io_uring.c
>> @@ -8229,24 +8229,6 @@ static void io_clean_op(struct io_kiocb *req)
>>
>> if (req->flags & REQ_F_NEED_CLEANUP) {
>> switch (req->opcode) {
>> - case IORING_OP_READV:
>> - case IORING_OP_READ_FIXED:
>> - case IORING_OP_READ:
>> - case IORING_OP_WRITEV:
>> - case IORING_OP_WRITE_FIXED:
>> - case IORING_OP_WRITE: {
>> - struct io_async_rw *io = req->async_data;
>> -
>> - kfree(io->free_iovec);
>
> Removing this kfree may cause a leak.
> For READV/WRITEV atleast, io->free_iovec will hold the address of
> allocated iovec array if input was larger than UIO_FASTIOV.
I think I was too tired when I did and saw it freeing ->async_data,
which is obviously not the case. I'll drop this one.
--
Jens Axboe
