All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Wilck <martin.wilck@suse.com>
To: "bmarzins@redhat.com" <bmarzins@redhat.com>,
	"christophe.varoqui@opensvc.com" <christophe.varoqui@opensvc.com>
Cc: "dm-devel@redhat.com" <dm-devel@redhat.com>
Subject: Re: [dm-devel] [PATCH v4 3/6] multipathd: fix ev_remove_path return code handling
Date: Mon, 17 May 2021 19:33:34 +0000	[thread overview]
Message-ID: <7058c8c0c6a6ee765dc2772ae497071228658518.camel@suse.com> (raw)
In-Reply-To: <d18212229ca58f069af5a7489548ff228a3552b6.camel@suse.com>

On Mon, 2021-05-17 at 20:51 +0200, Martin Wilck wrote:
> On Mon, 2021-05-17 at 11:29 -0500, Benjamin Marzinski wrote:
> > When ev_remove_path() returned success, callers assumed that the
> > path
> > (and possibly the map) had been removed.  When ev_remove_path()
> > returned
> > failure, callers assumed that the path had not been removed.
> > However,
> > the path could be removed on both success or failure. This could
> > cause
> > callers to dereference the path after it was removed.
> > 
> > To deal with this, make ev_remove_path() return a different
> > symbolic
> > value for each outcome, and make the callers react appropriately
> > for
> > the different values. Found by coverity.
> > 
> > Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>+
> 
> Reviewed-by: Martin Wilck <mwilck@suse.com>
> 

It just occured to me that we should probably not have set changed the
return code of cli_del_path() because of a strdup() failure for the
reply string. (It was my suggestion, I know).

Anyway, I've pushed this to "queue" already.
We can change this in a follow-up patch.

Regards
Martin


--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


  reply	other threads:[~2021-05-17 19:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17 16:29 [dm-devel] [PATCH v4 0/6] Memory issues found by coverity Benjamin Marzinski
2021-05-17 16:29 ` [dm-devel] [PATCH v4 1/6] multipathd: don't fail to remove path once the map is removed Benjamin Marzinski
2021-05-17 16:29 ` [dm-devel] [PATCH v4 2/6] multipathd: remove duplicate orphan_paths in flush_map Benjamin Marzinski
2021-05-17 16:29 ` [dm-devel] [PATCH v4 3/6] multipathd: fix ev_remove_path return code handling Benjamin Marzinski
2021-05-17 18:51   ` Martin Wilck
2021-05-17 19:33     ` Martin Wilck [this message]
2021-05-18 22:38       ` Benjamin Marzinski
2021-05-17 16:29 ` [dm-devel] [PATCH v4 4/6] multipath: free vectors in configure Benjamin Marzinski
2021-05-17 16:29 ` [dm-devel] [PATCH v4 5/6] kpartx: Don't leak memory when getblock returns NULL Benjamin Marzinski
2021-05-17 16:29 ` [dm-devel] [PATCH v4 6/6] multipathd: don't rescan_path on wwid change in uev_update_path Benjamin Marzinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7058c8c0c6a6ee765dc2772ae497071228658518.camel@suse.com \
    --to=martin.wilck@suse.com \
    --cc=bmarzins@redhat.com \
    --cc=christophe.varoqui@opensvc.com \
    --cc=dm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.