All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Wei Liu <wl@xen.org>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Paul Durrant <paul@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Jason Andryuk <jandryuk@gmail.com>
Subject: Re: use of "stat -"
Date: Tue, 12 May 2020 16:33:45 +0200	[thread overview]
Message-ID: <fa507eab-547a-c0fb-9620-825aba5f55b2@suse.com> (raw)
In-Reply-To: <20200512141947.yqx4gmbvqs4grx5g@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net>

On 12.05.2020 16:19, Wei Liu wrote:
> On Tue, May 12, 2020 at 12:58:46PM +0200, Jan Beulich wrote:
>> now that I've been able to do a little bit of work from the office
>> again, I've run into a regression from b72682c602b8 "scripts: Use
>> stat to check lock claim". On one of my older machines I've noticed
>> guests wouldn't launch anymore, which I've tracked down to the
>> system having an old stat on it. Yes, the commit says the needed
>> behavior has been available since 2009, but please let's not forget
>> that we continue to support building with tool chains from about
>> 2007.
>>
>> Putting in place and using newer tool chain versions without
>> touching the base distro is pretty straightforward. Replacing the
>> coreutils package isn't, and there's not even an override available
>> by which one could point at an alternative one. Hence I think
>> bumping the minimum required versions of basic tools should be
>> done even more carefully than bumping required tool chain versions
>> (which we've not dared to do in years). After having things
>> successfully working again with a full revert, I'm now going to
>> experiment with adapting behavior to stat's capabilities. Would
>> something like that be acceptable (if it works out)?
> 
> Are you asking for reverting that patch?

Well, I assume the patch has its merits, even if I don't really
understand what they are from its description. I'm instead asking
whether something like the below (meanwhile tested) would be
acceptable.

Jan

--- unstable.orig/tools/hotplug/Linux/locking.sh
+++ unstable/tools/hotplug/Linux/locking.sh
@@ -42,6 +42,12 @@ claim_lock()
     # it being possible to safely remove the lockfile when done.
     # See below for a correctness proof.
     local stat
+    local use_stat
+    local rightfile
+    if stat - 2>/dev/null >/dev/null
+    then
+        use_stat=y
+    fi
     while true; do
         eval "exec $_lockfd<>$_lockfile"
         flock -x $_lockfd || return $?
@@ -56,7 +62,17 @@ claim_lock()
         # WW.XXX
         # YY.ZZZ
         # which need to be separated and compared.
-        if stat=$( stat -L -c '%D.%i' - $_lockfile 0<&$_lockfd 2>/dev/null )
+        if [ x$use_stat != xy ]
+        then
+            # Fall back to the original Perl approach.
+            rightfile=$( perl -e '
+                open STDIN, "<&'$_lockfd'" or die $!;
+                my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
+                my $file_inum = (stat $ARGV[0])[1];
+                print "y\n" if $fd_inum eq $file_inum;
+                                 ' "$_lockfile" )
+            if [ x$rightfile = xy ]; then break; fi
+        elif stat=$( stat -L -c '%D.%i' - $_lockfile 0<&$_lockfd 2>/dev/null )
         then
             local file_stat
             local fd_stat




  reply	other threads:[~2020-05-12 14:34 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-12 10:58 use of "stat -" Jan Beulich
2020-05-12 14:19 ` Wei Liu
2020-05-12 14:33   ` Jan Beulich [this message]
2020-05-12 14:47     ` Andrew Cooper
2020-05-12 14:59       ` Jan Beulich
2020-05-12 15:52         ` Jason Andryuk
2020-05-12 19:50           ` Elliott Mitchell
2020-05-12 19:54             ` Andrew Cooper
2020-05-12 22:54               ` Elliott Mitchell
2020-05-14 11:02                 ` Ian Jackson
2020-05-14 12:39                   ` Jan Beulich
2020-05-18 10:34                   ` Jan Beulich
2020-06-24 15:55                     ` Ping: " Jan Beulich
2020-06-24 16:19                     ` [XEN RFC for-4.14] " Ian Jackson
2020-06-25  2:37                       ` Jason Andryuk
2020-06-25  7:05                         ` Jan Beulich
2020-06-25 12:04                           ` Jason Andryuk
2020-06-25 13:31                           ` Ian Jackson
2020-06-25 13:48                             ` Jan Beulich
2020-06-25 14:16                               ` Jason Andryuk
2020-06-25  7:27                         ` Rich Persaud
2020-06-25 13:27                         ` Ian Jackson
2020-06-25 14:08                           ` Jan Beulich
2020-06-25 14:18                             ` Jason Andryuk
2020-06-25 14:37                               ` Ian Jackson
2020-06-25 14:19                             ` Ian Jackson
2020-06-25  7:03                       ` Paul Durrant

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=fa507eab-547a-c0fb-9620-825aba5f55b2@suse.com \
    --to=jbeulich@suse.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jandryuk@gmail.com \
    --cc=paul@xen.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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.