[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <611e1210-d89b-9046-ac3f-68a89af6159e@oracle.com>
Date: Fri, 19 May 2023 18:12:01 +0100
From: John Garry <john.g.garry@...cle.com>
To: Bart Van Assche <bvanassche@....org>,
Juergen Gross <jgross@...e.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>
Cc: linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
"James E.J. Bottomley" <jejb@...ux.ibm.com>, stable@...r.kernel.org
Subject: Re: [PATCH] scsi: Let scsi_execute_cmd() mark args->sshdr as invalid
On 19/05/2023 17:54, Bart Van Assche wrote:
> On 5/19/23 09:06, John Garry wrote:
>> Sure, what I describe is ideal,
* not ideal
To be clear, I mean something like:
struct scsi_exec_args {
unsigned char **sense;
}
scsi_execute_cmd()
{
...
*args->sense = kmemdup(scsi_cmd->sense_buffer);
...
}
some_func()
{
unsigned char *sense = NULL;
struct scsi_exec_args = {
.sense = &sense,
};
ret = scsi_execute_cmd();
if (ret < 0)
return ret;
kfree(sense);
}
But not perfect as we need a separate small buffer for sensehdr and we
need to always kfree those buffers.
If only we could pass the actual scsi_cmnd sense buffer to the caller...
>but I still just dislike passing both
>> sensebuf and hdr into scsi_execute_cmd(). The semantics of how
>> scsi_execute_cmd() treats them is vague.
>
> Is this something that can be addressed by improving the
> scsi_execute_cmd() documentation?
Hmmm, I'm not sure documentation helps too much avoiding all programming
errors and better make the code foolproof.
Anyway, if we fix up the callers of scsi_execute_cmd() to properly check
for errors then if is not such a big deal.
Thanks,
John
Powered by blists - more mailing lists