From: Martin Wilck
Crashes have been observed in the unwinder stack of uevent_listen().
This can only be explained by "udev" not being a valid object at that
time. Be sure to pass a valid pointer, and don't call udev_unref() if
it has been set to NULL already.
I'm not quite sure how this would c
From: Martin Wilck
Various minor changes that resulted from recent work on lixiaokeng's
reports, collected here for review.
Martin Wilck (3):
multipathd: avoid crash in uevent_cleanup()
multipathd: ev_add_path: fail if add_map_with_path() fails
libmultipath: check return value of udev_devi
From: Martin Wilck
udev_device_get_devnum() may fail, in which case it returns
makedev(0, 0).
Signed-off-by: Martin Wilck
---
libmultipath/discovery.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libmultipath/discovery.c b/libmultipath/discovery.c
index 921025d..15cf641 100644
--- a/
From: Martin Wilck
If start_waiter was set before and the "rescan" label was used,
we may try to set up an empty/invalid map.
Always fail if add_map_with_path() isn't successful.
Signed-off-by: Martin Wilck
---
multipathd/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 2021/2/3 3:57, mwi...@suse.com wrote:
> From: Martin Wilck
>
> The description of 2d32d6f ("libmultipath: adopt_paths(): don't bail out on
> single path failure") said "we need to check after successful call to
> adopt_paths() if that specific path had been actually added, and fail in the
>
From: Martin Wilck
multipath should allow removing WWIDs of paths even if they
are blacklisted.
Signed-off-by: Martin Wilck
---
libmultipath/configure.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libmultipath/configure.c b/libmultipath/configure.c
index 3263bb0..59
From: Martin Wilck
The of filter_property() depends on the value of pp->uid_attribute.
This may in turn depend on pp->hwe, which is initialized in
sysfs_pathinfo(). To obtain consistent results from pathinfo(),
make sure uid_attribute is correctly set before calling filter_property().
filter_pro
From: Martin Wilck
With the previous change to call filter_property() after sysfs_pathinfo(),
it can't happen any more that filter_property() is called from pathinfo
with uid_attribute not set. This may cause pathinfo() to return failure
in some cases where it should actually proceed (e.g. when c
From: Martin Wilck
This is a spring-off of the previous discussion under the subject
"libmultipath: fix NULL dereference in get_be64".
Repeating part of the text of my last post there:
pp->uid_attribute may be set from the hwtable, which
means that vendor/product must be known, which in turn me
lixiaokeng,
did this fix your "crash on exit" issue?
Martin
On Thu, 2021-01-28 at 22:08 +0100, mwi...@suse.com wrote:
> From: Martin Wilck
>
> Crashes have been observed in the unwinder stack of uevent_listen().
> This can only be explained by "udev" not being a valid object at that
> time. Be
From: Martin Wilck
The description of 2d32d6f ("libmultipath: adopt_paths(): don't bail out on
single path failure") said "we need to check after successful call to
adopt_paths() if that specific path had been actually added, and fail in the
caller otherwise". But the commit failed to actually im
On Thu, Jan 28, 2021 at 10:08:52PM +0100, mwi...@suse.com wrote:
> From: Martin Wilck
>
> Crashes have been observed in the unwinder stack of uevent_listen().
> This can only be explained by "udev" not being a valid object at that
> time. Be sure to pass a valid pointer, and don't call udev_unref
On Tue, 2021-02-02 at 01:18 -0600, Benjamin Marzinski wrote:
> On Mon, Feb 01, 2021 at 11:26:36PM -0600, Benjamin Marzinski wrote:
> > On Mon, Feb 01, 2021 at 04:12:34PM +0100, Martin Wilck wrote:
> > >
> > > The same argument I made above still holds. "pp" wouldn't have
> > > been
> > > added to
On Tue, Feb 02, 2021 at 08:57:44PM +0100, mwi...@suse.com wrote:
> From: Martin Wilck
>
> The description of 2d32d6f ("libmultipath: adopt_paths(): don't bail out on
> single path failure") said "we need to check after successful call to
> adopt_paths() if that specific path had been actually add
On Fri, Jan 22 2021 at 3:43am -0500,
Ahmad Fatoum wrote:
> IS_ENABLED(CONFIG_ENCRYPTED_KEYS) is true whether the option is built-in
> or a module, so use it instead of #if defined checking for each
> separately.
>
> The other #if was to avoid a static function defined, but unused
> warning. As
On Tue, Feb 02, 2021 at 10:43:12AM +0100, mwi...@suse.com wrote:
> From: Martin Wilck
>
> On SAS expanders, node id's have 3 digits. sysfs paths look like this:
>
> /sys/devices/pci:80/:80:02.0/:8b:00.0/:8c:09.0/:8f:00.0/host9/port-9:0/expander-9:0/port-9:0:13/expander-9:1/po
On Mon, 2021-02-01 at 23:26 -0600, Benjamin Marzinski wrote:
> On Mon, Feb 01, 2021 at 04:12:34PM +0100, Martin Wilck wrote:
> > On Mon, 2021-02-01 at 22:50 +0800, lixiaokeng wrote:
> > >
> > > > >
> > > > > cli_add_path
> > > > > ->ev_add_path
> > > > > ->add_map_with_path
> > > > >
On Tue, 2021-02-02 at 10:43 +0100, mwi...@suse.com wrote:
> From: Martin Wilck
>
> On SAS expanders, node id's have 3 digits. sysfs paths look like
> this:
>
> /sys/devices/pci:80/:80:02.0/:8b:00.0/:8c:09.0/:8
> f:00.0/host9/port-9:0/expander-9:0/port-9:0:13/expander-9:1/port
From: Martin Wilck
On SAS expanders, node id's have 3 digits. sysfs paths look like this:
/sys/devices/pci:80/:80:02.0/:8b:00.0/:8c:09.0/:8f:00.0/host9/port-9:0/expander-9:0/port-9:0:13/expander-9:1/port-9:1:12/expander-9:2/port-9:2:4/end_device-9:2:4/target9:0:29/9:0:29:0/bl
On Mon, 2021-02-01 at 21:15 -0600, Benjamin Marzinski wrote:
> On Thu, Jan 28, 2021 at 09:45:41PM +0100, mwi...@suse.com wrote:
> > From: Martin Wilck
> >
> > Hi Christophe, hi Ben,
> >
> > here are 3 patches I'd like to get reviewed before we create a pull
> > request. The first two are related
On Mon, 2021-02-01 at 20:22 -0600, Benjamin Marzinski wrote:
> On Thu, Jan 28, 2021 at 09:45:42PM +0100, mwi...@suse.com wrote:
> > From: Martin Wilck
> >
> > On SAS expanders, node id's have 3 digits. sysfs paths look like
> > this:
> >
> > /sys/devices/pci:80/:80:02.0/:8b:00.0/
dm_table_supports_dax_write_cache() is remained untouched, since I'm not
sure if the semantics requires that 'any underlying device' or 'all
underlying devices' supporting dax_write_cache. At least it seems that
'any underlying device' is sufficient from the current code.
On 2/2/21 11:35 AM, Jeffl
According to the definition of dm_iterate_devices_fn:
* This function must iterate through each section of device used by the
* target until it encounters a non-zero return code, which it then returns.
* Returns zero if no callout returned non-zero.
For some target type (e.g., dm-stripe), one c
On 2021/2/2 13:26, Benjamin Marzinski wrote:
> So, I think the main issue here is that filter_property appears to be
> broken. It only filters if uid_attribute is set, but that will never be
> set the first time it's called in pathinfo. This means that it will
> pass in the pathinfo call in cli
24 matches
Mail list logo
