linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
To: Zhilong Liu <zlliu@suse.com>
Cc: linux-raid@vger.kernel.org, jes.sorensen@gmail.com
Subject: Re: [PATCH] Monitor: don't assume mdadm parameter is a block device
Date: Mon, 19 Jun 2017 11:16:58 +0200	[thread overview]
Message-ID: <20170619091658.GA9305@proton.igk.intel.com> (raw)
In-Reply-To: <585FFF8D-0238-4AB3-AA77-4C3C00C3C55D@suse.com>

On Sun, Jun 18, 2017 at 10:10:02PM +0800, Zhilong Liu wrote:
> 
> 
> > 在 2017年6月16日,22:02,Tomasz Majchrzak <tomasz.majchrzak@intel.com> 写道:
> > 
> > If symlink (e.g. /dev/md/raid) is passed as a parameter to mdadm --wait,
> > it fails as it's not able to find a corresponding entry in /proc/mdstat
> > output. Get parameter file major:minor and look for block device name in
> > sysfs. This commit is partial revert of commit 9e04ac1c43e6
> > ("mdadm/util: unify fstat checking blkdev into function").
> > 
> 
> Thanks very much for catching this.  Just remind a typo in (commit title), correct fstat as stat.

Will do.

> 
> > Signed-off-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
> > ---
> > Monitor.c | 13 +++++++++++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> > 
> > v2:
> > next Zhilong Liu commit id
> > 
> > diff --git a/Monitor.c b/Monitor.c
> > index bef2f1b..c9f24bd 100644
> > --- a/Monitor.c
> > +++ b/Monitor.c
> > @@ -982,12 +982,21 @@ static void link_containers_with_subarrays(struct state *list)
> > int Wait(char *dev)
> > {
> >    char devnm[32];
> > +    dev_t rdev;
> > +    char *tmp;
> >    int rv = 1;
> >    int frozen_remaining = 3;
> > 
> > -    if (!stat_is_blkdev(dev, NULL))
> > +    if (!stat_is_blkdev(dev, &rdev))
> > +        return 2;
> > +
> > +    tmp = devid2devnm(rdev);
> > +    if (!tmp) {
> > +        pr_err("Cannot get md device name.\n");
> >        return 2;
> > -    strcpy(devnm, dev);
> > +    }
> > +
> > +    strcpy(devnm, tmp);
> > 
> 
> Quite agreed with the code here, just a small question,  I may use 
> > strcpy(devnm, devid2devnm(rdev));
> directly since stat_is_blkdev() has returned the major/minor devid. I don't know "get md device name " would be failed in which scenario. 
> I'm asking this question since I haven't been familiar with all raids situations. :-)
> 
> Thanks again,
> Zhilong

Well, there could be a race and RAID array might get stopped between two
calls (stat_is_blkdev, devid2devnm) so corresponding sysfs entry would not
exist. Also I don't think we should assume devid2devnm implementation won't
change one day. I just did it safe way, otherwise static code analyzers
would complain.

Tomek

  parent reply	other threads:[~2017-06-19  9:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-16 14:02 [PATCH] Monitor: don't assume mdadm parameter is a block device Tomasz Majchrzak
     [not found] ` <585FFF8D-0238-4AB3-AA77-4C3C00C3C55D@suse.com>
2017-06-19  9:16   ` Tomasz Majchrzak [this message]
2017-06-19  9:19     ` [PATCH v2] " Tomasz Majchrzak
2017-07-10 17:40       ` Jes Sorensen
2017-06-20  0:30     ` [PATCH] " Zhilong Liu

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=20170619091658.GA9305@proton.igk.intel.com \
    --to=tomasz.majchrzak@intel.com \
    --cc=jes.sorensen@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=zlliu@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).