On Thu, 2021-05-13 at 12:23 -0500, Benjamin Marzinski wrote:
> There are many possible outcomes of calling ev_remove_path(), and not
> all callers agree on which outcomes are a success and which are a
> failure. So ev_remove_path() should simply return a different value
> for
> each outcome, and th
On Thu, 2021-05-13 at 12:23 -0500, Benjamin Marzinski wrote:
> When ev_remove_path() returns success, callers assume that the path
> (and
> possibly the map) has been removed. When ev_remove_path() returns
> failure, callers assume that the path has not been removed. However,
> the
> path could be
On Thu, 2021-05-13 at 12:23 -0500, Benjamin Marzinski wrote:
> configure() can retry multiple times, each time reallocing a maps and
> paths vector, and leaking the previous ones. Fix this by always
> freeing
> the vectors before configure() exits. Found by coverity.
>
> Signed-off-by: Benjamin Ma
On Thu, 2021-05-13 at 12:23 -0500, Benjamin Marzinski wrote:
> In ev_remove_path(), if update_mpp_paths() fails, we delete the
> entire
> map. However, since update_mpp_paths() happens before we call
> set_path_removed(), pp->initialized isn't set to INIT_REMOVED, so
> remove_map_and_stop_waiter()
From: Martin Wilck
To avoid race conditions with pending RCU callbacks on exit, it's
necessary to call rcu_barrier() in cleanup_rcu() (see
https://lists.lttng.org/pipermail/lttng-dev/2021-May/029958.html and
follow-ups).
rcu_barrier() is only available in User-space RCU v0.8 and newer.
Fix it by
On Thu, 2021-05-13 at 11:35 -0500, Benjamin Marzinski wrote:
> >
> > diff --git a/multipathd/Makefile b/multipathd/Makefile
> > index d053c1e..dc7eb32 100644
> > --- a/multipathd/Makefile
> > +++ b/multipathd/Makefile
> > @@ -16,6 +16,8 @@ LDFLAGS += $(BIN_LDFLAGS)
> > LIBDEPS += -L$(multipathdir
On Wed, 2021-05-12 at 16:52 -0500, Benjamin Marzinski wrote:
> On Wed, May 12, 2021 at 08:36:49PM +, Martin Wilck wrote:
> > On Wed, 2021-05-12 at 14:53 -0500, Benjamin Marzinski wrote:
> > > On Wed, May 12, 2021 at 11:38:08AM +, Martin Wilck wrote:
> > > > On Tue, 2021-05-11 at 18:22 -0500
On 5/13/21 12:22 PM, Mikulas Patocka wrote:
> We already had problems with too large bios in dm-crypt and we fixed it by
> adding this piece of code:
>
> /*
> * Check if bio is too large, split as needed.
> */
> if (unlikely(bio->bi_iter.bi_size > (BIO_MAX_VECS <
> On 5/13/21 7:15 AM, Theodore Ts'o wrote:
> > On Thu, May 13, 2021 at 06:42:22PM +0900, Changheun Lee wrote:
> >>
> >> Problem might be casued by exhausting of memory. And memory exhausting
> >> would be caused by setting of small bio_max_size. Actually it was not
> >> reproduced in my VM envir
remove_map_and_stop_waiter() already calls orphan_paths() so flush_map()
doesn't need to call orphan_paths() before calling
remove_map_and_stop_waiter().
Signed-off-by: Benjamin Marzinski
Reviewed-by: Martin Wilck
---
multipathd/main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/multipat
This is collection of issues found by coverity. The first three patches
deal with ev_remove_path() removing the path, but returning failure,
causing a use-after-free error. The next two patches fix memory leaks.
The final patch cleans up the returns from ev_remove_path().
Changes from v1:
0001: ch
When ev_remove_path() returns success, callers assume that the path (and
possibly the map) has been removed. When ev_remove_path() returns
failure, callers assume that the path has not been removed. However, the
path could be removed on both success or failure. This could cause
callers to derefere
If a new block was allocated, but couldn't be filled, getblock will
discard it. When it does so, it needs to free the block to avoid leaking
memory. Found by coverity.
Signed-off-by: Benjamin Marzinski
Reviewed-by: Martin Wilck
---
kpartx/kpartx.c | 2 ++
1 file changed, 2 insertions(+)
diff -
In ev_remove_path(), if update_mpp_paths() fails, we delete the entire
map. However, since update_mpp_paths() happens before we call
set_path_removed(), pp->initialized isn't set to INIT_REMOVED, so
remove_map_and_stop_waiter() doesn't remove the path when in removes the
map. But with the map remo
configure() can retry multiple times, each time reallocing a maps and
paths vector, and leaking the previous ones. Fix this by always freeing
the vectors before configure() exits. Found by coverity.
Signed-off-by: Benjamin Marzinski
---
multipath/main.c | 7 ++-
1 file changed, 6 insertions(
There are many possible outcomes of calling ev_remove_path(), and not
all callers agree on which outcomes are a success and which are a
failure. So ev_remove_path() should simply return a different value for
each outcome, and the callers can decide how to deal with them.
Signed-off-by: Benjamin Ma
On Wed, May 12, 2021 at 11:17:05PM +0200, mwi...@suse.com wrote:
> From: Martin Wilck
>
> To avoid race conditions with pending RCU callbacks on exit, it's
> necessary to call rcu_barrier() in cleanup_rcu() (see
> https://lists.lttng.org/pipermail/lttng-dev/2021-May/029958.html and
> follow-ups).
17 matches
Mail list logo
