[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] tools/xenstore: Do not abort xenstore-ls if a node disappears while iterating


  • To: David Woodhouse <dwmw2@xxxxxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>
  • From: Juergen Gross <jgross@xxxxxxxx>
  • Date: Mon, 4 Mar 2019 16:14:44 +0100
  • Autocrypt: addr=jgross@xxxxxxxx; prefer-encrypt=mutual; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNHkp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmRlPsLAeQQTAQIAIwUCU4xw6wIbAwcL CQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJELDendYovxMvi4UH/Ri+OXlObzqMANruTd4N zmVBAZgx1VW6jLc8JZjQuJPSsd/a+bNr3BZeLV6lu4Pf1Yl2Log129EX1KWYiFFvPbIiq5M5 kOXTO8Eas4CaScCvAZ9jCMQCgK3pFqYgirwTgfwnPtxFxO/F3ZcS8jovza5khkSKL9JGq8Nk czDTruQ/oy0WUHdUr9uwEfiD9yPFOGqp4S6cISuzBMvaAiC5YGdUGXuPZKXLpnGSjkZswUzY d9BVSitRL5ldsQCg6GhDoEAeIhUC4SQnT9SOWkoDOSFRXZ+7+WIBGLiWMd+yKDdRG5RyP/8f 3tgGiB6cyuYfPDRGsELGjUaTUq3H2xZgIPfOwE0EU4xwFgEIAMsx+gDjgzAY4H1hPVXgoLK8 B93sTQFN9oC6tsb46VpxyLPfJ3T1A6Z6MVkLoCejKTJ3K9MUsBZhxIJ0hIyvzwI6aYJsnOew cCiCN7FeKJ/oA1RSUemPGUcIJwQuZlTOiY0OcQ5PFkV5YxMUX1F/aTYXROXgTmSaw0aC1Jpo w7Ss1mg4SIP/tR88/d1+HwkJDVW1RSxC1PWzGizwRv8eauImGdpNnseneO2BNWRXTJumAWDD pYxpGSsGHXuZXTPZqOOZpsHtInFyi5KRHSFyk2Xigzvh3b9WqhbgHHHE4PUVw0I5sIQt8hJq 5nH5dPqz4ITtCL9zjiJsExHuHKN3NZsAEQEAAcLAXwQYAQIACQUCU4xwFgIbDAAKCRCw3p3W KL8TL0P4B/9YWver5uD/y/m0KScK2f3Z3mXJhME23vGBbMNlfwbr+meDMrJZ950CuWWnQ+d+ Ahe0w1X7e3wuLVODzjcReQ/v7b4JD3wwHxe+88tgB9byc0NXzlPJWBaWV01yB2/uefVKryAf AHYEd0gCRhx7eESgNBe3+YqWAQawunMlycsqKa09dBDL1PFRosF708ic9346GLHRc6Vj5SRA UTHnQqLetIOXZm3a2eQ1gpQK9MmruO86Vo93p39bS1mqnLLspVrL4rhoyhsOyh0Hd28QCzpJ wKeHTd0MAWAirmewHXWPco8p1Wg+V+5xfZzuQY0f4tQxvOpXpt4gQ1817GQ5/Ed/wsDtBBgB CAAgFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAlrd8NACGwIAgQkQsN6d1ii/Ey92IAQZFggA HRYhBFMtsHpB9jjzHji4HoBcYbtP2GO+BQJa3fDQAAoJEIBcYbtP2GO+TYsA/30H/0V6cr/W V+J/FCayg6uNtm3MJLo4rE+o4sdpjjsGAQCooqffpgA+luTT13YZNV62hAnCLKXH9n3+ZAgJ RtAyDWk1B/0SMDVs1wxufMkKC3Q/1D3BYIvBlrTVKdBYXPxngcRoqV2J77lscEvkLNUGsu/z W2pf7+P3mWWlrPMJdlbax00vevyBeqtqNKjHstHatgMZ2W0CFC4hJ3YEetuRBURYPiGzuJXU pAd7a7BdsqWC4o+GTm5tnGrCyD+4gfDSpkOT53S/GNO07YkPkm/8J4OBoFfgSaCnQ1izwgJQ jIpcG2fPCI2/hxf2oqXPYbKr1v4Z1wthmoyUgGN0LPTIm+B5vdY82wI5qe9uN6UOGyTH2B3p hRQUWqCwu2sqkI3LLbTdrnyDZaixT2T0f4tyF5Lfs+Ha8xVMhIyzNb1byDI5FKCb
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
  • Delivery-date: Mon, 04 Mar 2019 15:14:50 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Openpgp: preference=signencrypt

On 04/03/2019 16:10, David Woodhouse wrote:
> On Mon, 2019-03-04 at 15:51 +0100, Juergen Gross wrote:
>> On 04/03/2019 15:31, David Woodhouse wrote:
>>> On Mon, 2019-03-04 at 14:18 +0000, Wei Liu wrote:
>>>> CC Ian as well.
>>>>
>>>> It would be better if you run ./scripts/get_maintainers.pl on
>>>> your
>>>> patches in the future to CC the correct people.
>>>
>>> Will do; thanks.
>>>
>>>> On Fri, Mar 01, 2019 at 12:16:56PM +0000, David Woodhouse wrote:
>>>>> From: David Woodhouse <dwmw@xxxxxxxxxxxx>
>>>>>
>>>>> When recursing, a node sometimes disappears. Deal with it and
>>>>> move on
>>>>> instead of aborting and failing to print the rest of what was
>>>>> requested.
>>>>>     
>>>>> Signed-off-by: David Woodhouse <dwmw@xxxxxxxxxxxx>
>>>>> ---
>>>>> And thus did an extremely sporadic "not going to delete that
>>>>> device
>>>>> because it already doesn't exist" failure mode become painfully
>>>>> obvious
>>>>> in retrospect...
>>>>>
>>>>> diff --git a/tools/xenstore/xenstore_client.c
>>>>> b/tools/xenstore/xenstore_client.c
>>>>> index 3afc630ab8..c089d60a2a 100644
>>>>> --- a/tools/xenstore/xenstore_client.c
>>>>> +++ b/tools/xenstore/xenstore_client.c
>>>>> @@ -153,8 +153,13 @@ static void do_ls(struct xs_handle *h,
>>>>> char
>>>>> *path,
>>>>> int cur_depth, int show_perms
>>>>>        err(1, "malloc in do_ls");
>>>>>  
>>>>>      e = xs_directory(h, XBT_NULL, path, &num);
>>>>> -    if (e == NULL)
>>>>> -        err(1, "xs_directory (%s)", path);
>>>>> +    if (e == NULL) {
>>>>> +        if (!cur_depth)
>>>>> +            err(1, "xs_directory (%s)", path);
>>>>> +
>>>>> +        /* If a node disappears while recursing, silently move
>>>>> on.
>>>>> */
>>>>> +        num = 0;
>>>>> +    }
>>>>
>>>> Can you check if the errno is ENOENT? I would rather not ignore
>>>> other
>>>> types of errors if possible.
>>>
>>> Under what circumstances is it correct for xenstore-ls to abort
>>> immediately and not attempt to print anything more?
>>>
>>> I'm sure there are circumstances where the world is so hosed that
>>> it'll
>>> keep getting errors and *fail* to print anything more. But to
>>> deliberately bail out? Should that really be restricted to ENOENT?
>>
>> EACCES seems to be another candidate for trying to continue.
>>
>> EINVAL, ENOMEM and EIO should never occur, so aborting the operation
>> would be okay IMO.
> 
> If you get one of those errors for a given path, but then everything
> else afterwards works fine.... do you really *want* to abort and not
> print the later ones? I agree it would be OK — at least tolerable — to
> abort. But is it really the most desired outcome?

ENOENT and EACCES could be the result of races, so continuation is
fine as the result is correct (or has been correct at some time).

The other cases would omit some entries so the result would be
incomplete. So aborting is the correct decision IMO (as long as an
information is issued that the operation was aborted due to an error).


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.