On Mon, 1 September 2014 00:57:26 +0300, Sagi Grimberg wrote:
> On 8/28/2014 4:01 AM, Joern Engel wrote:
> >iscsi_release_param_list() cannot handle a NULL pointer. Found by
> >coverity.
> >
> >Signed-off-by: Joern Engel <joern@xxxxxxxxx>
> >---
> > drivers/target/iscsi/iscsi_target_parameters.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_parameters.c
> >index 02f9de26f38a..18c29260b4a2 100644
> >--- a/drivers/target/iscsi/iscsi_target_parameters.c
> >+++ b/drivers/target/iscsi/iscsi_target_parameters.c
> >@@ -601,7 +601,7 @@ int iscsi_copy_param_list(
> > param_list = kzalloc(sizeof(struct iscsi_param_list), GFP_KERNEL);
> > if (!param_list) {
> > pr_err("Unable to allocate memory for struct iscsi_param_list.\n");
> >- goto err_out;
> >+ return -1;
> > }
> > INIT_LIST_HEAD(¶m_list->param_list);
> > INIT_LIST_HEAD(¶m_list->extra_response_list);
> >
>
> Why won't you escalate correct error ENOMEM?
> Although the caller don't care about it...
>
> might be a good idea to follow up if return codes should propagate
> better in this area...
I'm not even sure if we can do anything smarter than we do right now.
To the initiator we are just a disk and the subtle differences between
-ENOMEM, -ETIMEDOUT and -EIO are unlikely to matter after translation
to scsi sense codes.
Then again, I may be entirely wrong and this may be a good project for
someone else to work on.
Jörn
--
The rabbit runs faster than the fox, because the rabbit is rinning for
his life while the fox is only running for his dinner.
-- Aesop
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
