On Thu, 13 May 2021, Bart Van Assche wrote:
> 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.
> > */
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 environment at fi
On Thu, May 13, 2021 at 08:11:13PM +, Martin Wilck wrote:
> 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
On Thu, May 13, 2021 at 09:53:58PM +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).
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 -
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 removes an unnecessary call to rescan_paths() from
uev_update_path()
C
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
If get_uid() is returning a different wwid in uev_update_path(), then
the uid_attribute must have already gotten updated, which was the
purpose behind calling rescan_path() in the first place.
Signed-off-by: Benjamin Marzinski
---
multipathd/main.c | 1 -
1 file changed, 1 deletion(-)
diff --gi
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
Reviewed-by: Martin Wilck
---
multipath/main.c | 7 ++-
1
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 dere
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
On Fri, 2021-05-14 at 15:11 -0500, Benjamin Marzinski wrote:
> If get_uid() is returning a different wwid in uev_update_path(), then
> the uid_attribute must have already gotten updated, which was the
> purpose behind calling rescan_path() in the first place.
>
> Signed-off-by: Benjamin Marzinski
On Fri, 2021-05-14 at 15:10 -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
13 matches
Mail list logo
