All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@suse.com>
To: lixiaokeng <lixiaokeng@huawei.com>,
	Benjamin Marzinski <bmarzins@redhat.com>,
	Christophe Varoqui <christophe.varoqui@opensvc.com>,
	dm-devel mailing list <dm-devel@redhat.com>
Cc: linfeilong <linfeilong@huawei.com>,
	"liuzhiqiang \(I\)" <liuzhiqiang26@huawei.com>,
	lihaotian9@huawei.com
Subject: Re: [dm-devel] [QUESTION]: multipath device with wrong path lead to metadata err
Date: Thu, 04 Feb 2021 15:56:14 +0100	[thread overview]
Message-ID: <d8e5a777991a31200e6aa85870b5b38b586bc765.camel@suse.com> (raw)
In-Reply-To: <342183ae-ead1-a13f-9384-459d09c04e6c@huawei.com>

On Thu, 2021-02-04 at 19:25 +0800, lixiaokeng wrote:
> 
> Hi Martin,
> 
> On 2021/1/27 7:11, Martin Wilck wrote:
> > So we can only conclude that (if there's no kernel refcounting bug,
> > which I doubt) either orphan_path()->uninitialize_path() had been
> > called (closing the fd),  or that opening the sd device had failed
> > in
> > the first place (in which case the path WWID should have been
> > nulled in
> > pathinfo(). In both cases it makes little sense that the path
> > should
> > still be part of a struct multipath. 
> 
> I have an idea.
> 
> If pp->fd < 0 ("Couldn't open device node"), pathinfo() returns
> PATHINFO_FAILED. Don't close(pp->fd) in orphan_path(). It may solve
> the
> problem (device with wrong path). I will take some time to test it.

Do you have evidence that the fd had been closed in your error case?
The path in question wasn't orphaned, if I understood correctly. You
said it was still member of a map. In that case, the fd *must* be open.

> However, I don’t know if there are potential risks. Do you have
> suggestions about this?

Other than resource usage ... users might be irritated because if we do
this and a device is remove and reappears, it will *always* have a
different device node attached. But the device nodes are random today,
anyway. If we missed a delete event, we might keep this fd open
forever, because a re-added path would never get the same sysfs path
again; not sure if that might hurt in some scenarios. We shouldn't miss
delete events anyway, of course.

So no, at least off the to of my head, I can't think of anything
serious. Famous last words ;-)

We must make sure to close the fd in the free_path() code path, of
course.

Btw, I just double-checked that the kernel really behaves as I thought.
You can run e.g. in python:

>>> import os
>>> f=os.open("/dev/sdh", os.O_RDWR|os.O_EXCL)

This will keep an fd to the device open. Now if you delete the device
and re-add it by scanning the scsi host, it will get a new device ID.

echo 1 >/sys/block/sdh/device/delete 
echo - - - >/sys/class/scsi_host/host2/scan

If you close the fd in python and repeat the delete/re-add (and nothing
else happened in the meantime), it will become "sdh" again.

Cheers,
Martin



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

  reply	other threads:[~2021-02-04 14:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-18 11:08 [dm-devel] [QUESTION]: multipath device with wrong path lead to metadata err lixiaokeng
2021-01-19  9:41 ` Martin Wilck
2021-01-19 12:46   ` lixiaokeng
2021-01-19 21:57 ` Martin Wilck
2021-01-20  2:30   ` lixiaokeng
2021-01-20 14:07     ` Martin Wilck
2021-01-25  1:33       ` lixiaokeng
2021-01-25 12:28         ` Martin Wilck
2021-01-26  6:40           ` lixiaokeng
2021-01-26 11:14           ` lixiaokeng
2021-01-26 23:11             ` Martin Wilck
2021-01-28  8:27               ` lixiaokeng
2021-01-28 21:15                 ` Martin Wilck
2021-02-04 11:25               ` lixiaokeng
2021-02-04 14:56                 ` Martin Wilck [this message]
2021-02-05 11:49                   ` lixiaokeng
2021-01-20 13:02   ` Roger Heflin
2021-01-20 20:45     ` Martin Wilck

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=d8e5a777991a31200e6aa85870b5b38b586bc765.camel@suse.com \
    --to=mwilck@suse.com \
    --cc=bmarzins@redhat.com \
    --cc=christophe.varoqui@opensvc.com \
    --cc=dm-devel@redhat.com \
    --cc=lihaotian9@huawei.com \
    --cc=linfeilong@huawei.com \
    --cc=liuzhiqiang26@huawei.com \
    --cc=lixiaokeng@huawei.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.