2016-12-15 14:48:04

by Benjamin Coddington

[permalink] [raw]
Subject: [PATCH] NFS: nfs_rename() handle -ERESTARTSYS dentry left behind

An interrupted rename will leave the old dentry behind if the rename
succeeds. Fix this by forcing a lookup the next time through
->d_revalidate.

Signed-off-by: Benjamin Coddington <[email protected]>
---
fs/nfs/dir.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index 5f1af4cd1a33..5d409616f77e 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -2100,14 +2100,24 @@ int nfs_rename(struct inode *old_dir, struct dentry *old_dentry,
d_rehash(rehash);
trace_nfs_rename_exit(old_dir, old_dentry,
new_dir, new_dentry, error);
- if (!error) {
+
+ switch (error) {
+ case 0:
if (new_inode != NULL)
nfs_drop_nlink(new_inode);
d_move(old_dentry, new_dentry);
nfs_set_verifier(new_dentry,
nfs_save_change_attribute(new_dir));
- } else if (error == -ENOENT)
+ break;
+ case -ENOENT:
nfs_dentry_handle_enoent(old_dentry);
+ break;
+ case -ERESTARTSYS:
+ /* The result of the rename is unknown. Play it safe by
+ * forcing a new lookup */
+ nfs_force_lookup_revalidate(old_dir);
+ nfs_force_lookup_revalidate(new_dir);
+ }

/* new dentry created? */
if (dentry)
--
2.9.3



2016-12-15 15:02:55

by Jeff Layton

[permalink] [raw]
Subject: Re: [PATCH] NFS: nfs_rename() handle -ERESTARTSYS dentry left behind

On Thu, 2016-12-15 at 09:48 -0500, Benjamin Coddington wrote:
> An interrupted rename will leave the old dentry behind if the rename
> succeeds. Fix this by forcing a lookup the next time through
> ->d_revalidate.
>
> Signed-off-by: Benjamin Coddington <[email protected]>
> ---
> fs/nfs/dir.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> index 5f1af4cd1a33..5d409616f77e 100644
> --- a/fs/nfs/dir.c
> +++ b/fs/nfs/dir.c
> @@ -2100,14 +2100,24 @@ int nfs_rename(struct inode *old_dir, struct dentry *old_dentry,
> d_rehash(rehash);
> trace_nfs_rename_exit(old_dir, old_dentry,
> new_dir, new_dentry, error);
> - if (!error) {
> +
> + switch (error) {
> + case 0:
> if (new_inode != NULL)
> nfs_drop_nlink(new_inode);
> d_move(old_dentry, new_dentry);
> nfs_set_verifier(new_dentry,
> nfs_save_change_attribute(new_dir));
> - } else if (error == -ENOENT)
> + break;
> + case -ENOENT:
> nfs_dentry_handle_enoent(old_dentry);
> + break;
> + case -ERESTARTSYS:
> + /* The result of the rename is unknown. Play it safe by
> + * forcing a new lookup */
> + nfs_force_lookup_revalidate(old_dir);
> + nfs_force_lookup_revalidate(new_dir);
> + }
>
> /* new dentry created? */
> if (dentry)

Looks reasonable to me. 

Reviewed-by: Jeff Layton <[email protected]>

2016-12-15 22:38:23

by Trond Myklebust

[permalink] [raw]
Subject: Re: [PATCH] NFS: nfs_rename() handle -ERESTARTSYS dentry left behind

DQo+IE9uIERlYyAxNSwgMjAxNiwgYXQgMDk6NDgsIEJlbmphbWluIENvZGRpbmd0b24gPGJjb2Rk
aW5nQHJlZGhhdC5jb20+IHdyb3RlOg0KPiANCj4gQW4gaW50ZXJydXB0ZWQgcmVuYW1lIHdpbGwg
bGVhdmUgdGhlIG9sZCBkZW50cnkgYmVoaW5kIGlmIHRoZSByZW5hbWUNCj4gc3VjY2VlZHMuICBG
aXggdGhpcyBieSBmb3JjaW5nIGEgbG9va3VwIHRoZSBuZXh0IHRpbWUgdGhyb3VnaA0KPiAtPmRf
cmV2YWxpZGF0ZS4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IEJlbmphbWluIENvZGRpbmd0b24gPGJj
b2RkaW5nQHJlZGhhdC5jb20+DQo+IC0tLQ0KPiBmcy9uZnMvZGlyLmMgfCAxNCArKysrKysrKysr
KystLQ0KPiAxIGZpbGUgY2hhbmdlZCwgMTIgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkN
Cj4gDQo+IGRpZmYgLS1naXQgYS9mcy9uZnMvZGlyLmMgYi9mcy9uZnMvZGlyLmMNCj4gaW5kZXgg
NWYxYWY0Y2QxYTMzLi41ZDQwOTYxNmY3N2UgMTAwNjQ0DQo+IC0tLSBhL2ZzL25mcy9kaXIuYw0K
PiArKysgYi9mcy9uZnMvZGlyLmMNCj4gQEAgLTIxMDAsMTQgKzIxMDAsMjQgQEAgaW50IG5mc19y
ZW5hbWUoc3RydWN0IGlub2RlICpvbGRfZGlyLCBzdHJ1Y3QgZGVudHJ5ICpvbGRfZGVudHJ5LA0K
PiAJCWRfcmVoYXNoKHJlaGFzaCk7DQo+IAl0cmFjZV9uZnNfcmVuYW1lX2V4aXQob2xkX2Rpciwg
b2xkX2RlbnRyeSwNCj4gCQkJbmV3X2RpciwgbmV3X2RlbnRyeSwgZXJyb3IpOw0KPiAtCWlmICgh
ZXJyb3IpIHsNCj4gKw0KPiArCXN3aXRjaCAoZXJyb3IpIHsNCj4gKwljYXNlIDA6DQo+IAkJaWYg
KG5ld19pbm9kZSAhPSBOVUxMKQ0KPiAJCQluZnNfZHJvcF9ubGluayhuZXdfaW5vZGUpOw0KPiAJ
CWRfbW92ZShvbGRfZGVudHJ5LCBuZXdfZGVudHJ5KTsNCj4gCQluZnNfc2V0X3ZlcmlmaWVyKG5l
d19kZW50cnksDQo+IAkJCQkJbmZzX3NhdmVfY2hhbmdlX2F0dHJpYnV0ZShuZXdfZGlyKSk7DQo+
IC0JfSBlbHNlIGlmIChlcnJvciA9PSAtRU5PRU5UKQ0KPiArCQlicmVhazsNCj4gKwljYXNlIC1F
Tk9FTlQ6DQo+IAkJbmZzX2RlbnRyeV9oYW5kbGVfZW5vZW50KG9sZF9kZW50cnkpOw0KPiArCQli
cmVhazsNCj4gKwljYXNlIC1FUkVTVEFSVFNZUzoNCj4gKwkJLyogVGhlIHJlc3VsdCBvZiB0aGUg
cmVuYW1lIGlzIHVua25vd24uIFBsYXkgaXQgc2FmZSBieQ0KPiArCQkgKiBmb3JjaW5nIGEgbmV3
IGxvb2t1cCAqLw0KPiArCQluZnNfZm9yY2VfbG9va3VwX3JldmFsaWRhdGUob2xkX2Rpcik7DQo+
ICsJCW5mc19mb3JjZV9sb29rdXBfcmV2YWxpZGF0ZShuZXdfZGlyKTsNCj4gKwl9DQoNCkRvZXNu
4oCZdCB0aGlzIGVycm9yIGhhbmRsaW5nIGJlbG9uZyBpbiBuZnNfYXN5bmNfcmVuYW1lX2RvbmUo
KSwgb3IgcG9zc2libHkgaW4gaXRzIOKAnGRhdGEtPmNvbXBsZXRlKCnigJ0gY2FsbGJhY2s/IFRo
ZXJlIGlzbuKAmXQgbXVjaCBwb2ludCBpbiBmb3JjaW5nIGEgbmV3IGxvb2t1cCB1bnRpbCB3ZSBr
bm93IHRoZSBSUEMgY2FsbCBoYXMgcnVuIGl0cyBjb3Vyc2UuDQoNCkNoZWVycw0KICBUcm9uZA==

2016-12-16 11:09:10

by Benjamin Coddington

[permalink] [raw]
Subject: Re: [PATCH] NFS: nfs_rename() handle -ERESTARTSYS dentry left behind

On 15 Dec 2016, at 17:38, Trond Myklebust wrote:

>> On Dec 15, 2016, at 09:48, Benjamin Coddington <[email protected]>
>> wrote:
>>
>> An interrupted rename will leave the old dentry behind if the rename
>> succeeds. Fix this by forcing a lookup the next time through
>> ->d_revalidate.
>>
>> Signed-off-by: Benjamin Coddington <[email protected]>
>> ---
>> fs/nfs/dir.c | 14 ++++++++++++--
>> 1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
>> index 5f1af4cd1a33..5d409616f77e 100644
>> --- a/fs/nfs/dir.c
>> +++ b/fs/nfs/dir.c
>> @@ -2100,14 +2100,24 @@ int nfs_rename(struct inode *old_dir, struct
>> dentry *old_dentry,
>> d_rehash(rehash);
>> trace_nfs_rename_exit(old_dir, old_dentry,
>> new_dir, new_dentry, error);
>> - if (!error) {
>> +
>> + switch (error) {
>> + case 0:
>> if (new_inode != NULL)
>> nfs_drop_nlink(new_inode);
>> d_move(old_dentry, new_dentry);
>> nfs_set_verifier(new_dentry,
>> nfs_save_change_attribute(new_dir));
>> - } else if (error == -ENOENT)
>> + break;
>> + case -ENOENT:
>> nfs_dentry_handle_enoent(old_dentry);
>> + break;
>> + case -ERESTARTSYS:
>> + /* The result of the rename is unknown. Play it safe by
>> + * forcing a new lookup */
>> + nfs_force_lookup_revalidate(old_dir);
>> + nfs_force_lookup_revalidate(new_dir);
>> + }
>
> Doesn’t this error handling belong in nfs_async_rename_done(), or
> possibly in its “data->complete()” callback? There isn’t much
> point in forcing a new lookup until we know the RPC call has run its
> course.

That would be more correct, however if moved there, we'd be forcing a
lookup after every rename, not just a rename that was signaled. Is it
worth trying to find a way to inform those functions that the wait was
interrupted?

Ben

2016-12-16 14:23:24

by Trond Myklebust

[permalink] [raw]
Subject: Re: [PATCH] NFS: nfs_rename() handle -ERESTARTSYS dentry left behind

DQo+IE9uIERlYyAxNiwgMjAxNiwgYXQgMDY6MDksIEJlbmphbWluIENvZGRpbmd0b24gPGJjb2Rk
aW5nQHJlZGhhdC5jb20+IHdyb3RlOg0KPiANCj4gT24gMTUgRGVjIDIwMTYsIGF0IDE3OjM4LCBU
cm9uZCBNeWtsZWJ1c3Qgd3JvdGU6DQo+IA0KPj4+IE9uIERlYyAxNSwgMjAxNiwgYXQgMDk6NDgs
IEJlbmphbWluIENvZGRpbmd0b24gPGJjb2RkaW5nQHJlZGhhdC5jb20+IHdyb3RlOg0KPj4+IA0K
Pj4+IEFuIGludGVycnVwdGVkIHJlbmFtZSB3aWxsIGxlYXZlIHRoZSBvbGQgZGVudHJ5IGJlaGlu
ZCBpZiB0aGUgcmVuYW1lDQo+Pj4gc3VjY2VlZHMuICBGaXggdGhpcyBieSBmb3JjaW5nIGEgbG9v
a3VwIHRoZSBuZXh0IHRpbWUgdGhyb3VnaA0KPj4+IC0+ZF9yZXZhbGlkYXRlLg0KPj4+IA0KPj4+
IFNpZ25lZC1vZmYtYnk6IEJlbmphbWluIENvZGRpbmd0b24gPGJjb2RkaW5nQHJlZGhhdC5jb20+
DQo+Pj4gLS0tDQo+Pj4gZnMvbmZzL2Rpci5jIHwgMTQgKysrKysrKysrKysrLS0NCj4+PiAxIGZp
bGUgY2hhbmdlZCwgMTIgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCj4+PiANCj4+PiBk
aWZmIC0tZ2l0IGEvZnMvbmZzL2Rpci5jIGIvZnMvbmZzL2Rpci5jDQo+Pj4gaW5kZXggNWYxYWY0
Y2QxYTMzLi41ZDQwOTYxNmY3N2UgMTAwNjQ0DQo+Pj4gLS0tIGEvZnMvbmZzL2Rpci5jDQo+Pj4g
KysrIGIvZnMvbmZzL2Rpci5jDQo+Pj4gQEAgLTIxMDAsMTQgKzIxMDAsMjQgQEAgaW50IG5mc19y
ZW5hbWUoc3RydWN0IGlub2RlICpvbGRfZGlyLCBzdHJ1Y3QgZGVudHJ5ICpvbGRfZGVudHJ5LA0K
Pj4+IAkJZF9yZWhhc2gocmVoYXNoKTsNCj4+PiAJdHJhY2VfbmZzX3JlbmFtZV9leGl0KG9sZF9k
aXIsIG9sZF9kZW50cnksDQo+Pj4gCQkJbmV3X2RpciwgbmV3X2RlbnRyeSwgZXJyb3IpOw0KPj4+
IC0JaWYgKCFlcnJvcikgew0KPj4+ICsNCj4+PiArCXN3aXRjaCAoZXJyb3IpIHsNCj4+PiArCWNh
c2UgMDoNCj4+PiAJCWlmIChuZXdfaW5vZGUgIT0gTlVMTCkNCj4+PiAJCQluZnNfZHJvcF9ubGlu
ayhuZXdfaW5vZGUpOw0KPj4+IAkJZF9tb3ZlKG9sZF9kZW50cnksIG5ld19kZW50cnkpOw0KPj4+
IAkJbmZzX3NldF92ZXJpZmllcihuZXdfZGVudHJ5LA0KPj4+IAkJCQkJbmZzX3NhdmVfY2hhbmdl
X2F0dHJpYnV0ZShuZXdfZGlyKSk7DQo+Pj4gLQl9IGVsc2UgaWYgKGVycm9yID09IC1FTk9FTlQp
DQo+Pj4gKwkJYnJlYWs7DQo+Pj4gKwljYXNlIC1FTk9FTlQ6DQo+Pj4gCQluZnNfZGVudHJ5X2hh
bmRsZV9lbm9lbnQob2xkX2RlbnRyeSk7DQo+Pj4gKwkJYnJlYWs7DQo+Pj4gKwljYXNlIC1FUkVT
VEFSVFNZUzoNCj4+PiArCQkvKiBUaGUgcmVzdWx0IG9mIHRoZSByZW5hbWUgaXMgdW5rbm93bi4g
UGxheSBpdCBzYWZlIGJ5DQo+Pj4gKwkJICogZm9yY2luZyBhIG5ldyBsb29rdXAgKi8NCj4+PiAr
CQluZnNfZm9yY2VfbG9va3VwX3JldmFsaWRhdGUob2xkX2Rpcik7DQo+Pj4gKwkJbmZzX2ZvcmNl
X2xvb2t1cF9yZXZhbGlkYXRlKG5ld19kaXIpOw0KPj4+ICsJfQ0KPj4gDQo+PiBEb2VzbuKAmXQg
dGhpcyBlcnJvciBoYW5kbGluZyBiZWxvbmcgaW4gbmZzX2FzeW5jX3JlbmFtZV9kb25lKCksIG9y
IHBvc3NpYmx5IGluIGl0cyDigJxkYXRhLT5jb21wbGV0ZSgp4oCdIGNhbGxiYWNrPyBUaGVyZSBp
c27igJl0IG11Y2ggcG9pbnQgaW4gZm9yY2luZyBhIG5ldyBsb29rdXAgdW50aWwgd2Uga25vdyB0
aGUgUlBDIGNhbGwgaGFzIHJ1biBpdHMgY291cnNlLg0KPiANCj4gVGhhdCB3b3VsZCBiZSBtb3Jl
IGNvcnJlY3QsIGhvd2V2ZXIgaWYgbW92ZWQgdGhlcmUsIHdlJ2QgYmUgZm9yY2luZyBhIGxvb2t1
cCBhZnRlciBldmVyeSByZW5hbWUsIG5vdCBqdXN0IGEgcmVuYW1lIHRoYXQgd2FzIHNpZ25hbGVk
LiAgSXMgaXQgd29ydGggdHJ5aW5nIHRvIGZpbmQgYSB3YXkgdG8gaW5mb3JtIHRob3NlIGZ1bmN0
aW9ucyB0aGF0IHRoZSB3YWl0IHdhcyBpbnRlcnJ1cHRlZD8NCj4gDQoNClRoZXJlIGFyZSBhbHJl
YWR5IHByZWNlZGVudHMgZm9yIHRoaXMuIExvb2ssIGZvciBpbnN0YW5jZSwgYXQgaG93IHRoZSBk
YXRhLT5jYW5jZWxsZWQgZmxhZyBpbnRlcm9wZXJhdGVzIGJldHdlZW4gbmZzNF9ydW5fb3Blbl90
YXNrKCkgYW5kIA0KbmZzNF9vcGVuX3JlbGVhc2UoKSB0byB0cmlnZ2VyIHN0YXRlIHJlY292ZXJ5
IChieSBpc3N1aW5nIGEgY2xvc2UpIGlmIHRoZSBSUEMgY2FsbCB3YXMgY29tcGxldGVkLCBidXQg
dGhlIHVzZXIgaW50ZXJydXB0ZWQgdGhlIG9wZXJhdGlvbi4NCg0KQ2hlZXJzDQogIFRyb25k

2016-12-16 14:35:15

by Jeff Layton

[permalink] [raw]
Subject: Re: [PATCH] NFS: nfs_rename() handle -ERESTARTSYS dentry left behind

On Fri, 2016-12-16 at 14:23 +0000, Trond Myklebust wrote:
> >
> > On Dec 16, 2016, at 06:09, Benjamin Coddington <[email protected]> wrote:
> >
> > On 15 Dec 2016, at 17:38, Trond Myklebust wrote:
> >
> > >
> > > >
> > > > On Dec 15, 2016, at 09:48, Benjamin Coddington <[email protected]> wrote:
> > > >
> > > > An interrupted rename will leave the old dentry behind if the rename
> > > > succeeds. Fix this by forcing a lookup the next time through
> > > > ->d_revalidate.
> > > >
> > > > Signed-off-by: Benjamin Coddington <[email protected]>
> > > > ---
> > > > fs/nfs/dir.c | 14 ++++++++++++--
> > > > 1 file changed, 12 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> > > > index 5f1af4cd1a33..5d409616f77e 100644
> > > > --- a/fs/nfs/dir.c
> > > > +++ b/fs/nfs/dir.c
> > > > @@ -2100,14 +2100,24 @@ int nfs_rename(struct inode *old_dir, struct dentry *old_dentry,
> > > > d_rehash(rehash);
> > > > trace_nfs_rename_exit(old_dir, old_dentry,
> > > > new_dir, new_dentry, error);
> > > > - if (!error) {
> > > > +
> > > > + switch (error) {
> > > > + case 0:
> > > > if (new_inode != NULL)
> > > > nfs_drop_nlink(new_inode);
> > > > d_move(old_dentry, new_dentry);
> > > > nfs_set_verifier(new_dentry,
> > > > nfs_save_change_attribute(new_dir));
> > > > - } else if (error == -ENOENT)
> > > > + break;
> > > > + case -ENOENT:
> > > > nfs_dentry_handle_enoent(old_dentry);
> > > > + break;
> > > > + case -ERESTARTSYS:
> > > > + /* The result of the rename is unknown. Play it safe by
> > > > + * forcing a new lookup */
> > > > + nfs_force_lookup_revalidate(old_dir);
> > > > + nfs_force_lookup_revalidate(new_dir);
> > > > + }
> > >
> > > Doesn’t this error handling belong in nfs_async_rename_done(), or possibly in its “data->complete()” callback? There isn’t much point in forcing a new lookup until we know the RPC call has run its course.
> >
> > That would be more correct, however if moved there, we'd be forcing a lookup after every rename, not just a rename that was signaled. Is it worth trying to find a way to inform those functions that the wait was interrupted?
> >
>
> There are already precedents for this. Look, for instance, at how the data->cancelled flag interoperates between nfs4_run_open_task() and
> nfs4_open_release() to trigger state recovery (by issuing a close) if the RPC call was completed, but the user interrupted the operation.
>
> Cheers
> Trond

There is the timing to consider here as well. Once you return from this
function the vfs is going to unlock everything without doing the d_move.

Is it better to mark the directories for revalidation at that point, or
when the RENAME reply comes in? I would think that marking it for reval
immediately would be best. Is there an argument for waiting?

--
Jeff Layton <[email protected]>

2016-12-16 14:44:26

by Trond Myklebust

[permalink] [raw]
Subject: Re: [PATCH] NFS: nfs_rename() handle -ERESTARTSYS dentry left behind

DQo+IE9uIERlYyAxNiwgMjAxNiwgYXQgMDk6MzUsIEplZmYgTGF5dG9uIDxqbGF5dG9uQHBvb2No
aWVyZWRzLm5ldD4gd3JvdGU6DQo+IA0KPiBPbiBGcmksIDIwMTYtMTItMTYgYXQgMTQ6MjMgKzAw
MDAsIFRyb25kIE15a2xlYnVzdCB3cm90ZToNCj4+PiANCj4+PiBPbiBEZWMgMTYsIDIwMTYsIGF0
IDA2OjA5LCBCZW5qYW1pbiBDb2RkaW5ndG9uIDxiY29kZGluZ0ByZWRoYXQuY29tPiB3cm90ZToN
Cj4+PiANCj4+PiBPbiAxNSBEZWMgMjAxNiwgYXQgMTc6MzgsIFRyb25kIE15a2xlYnVzdCB3cm90
ZToNCj4+PiANCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IE9uIERlYyAxNSwgMjAxNiwgYXQgMDk6NDgs
IEJlbmphbWluIENvZGRpbmd0b24gPGJjb2RkaW5nQHJlZGhhdC5jb20+IHdyb3RlOg0KPj4+Pj4g
DQo+Pj4+PiBBbiBpbnRlcnJ1cHRlZCByZW5hbWUgd2lsbCBsZWF2ZSB0aGUgb2xkIGRlbnRyeSBi
ZWhpbmQgaWYgdGhlIHJlbmFtZQ0KPj4+Pj4gc3VjY2VlZHMuICBGaXggdGhpcyBieSBmb3JjaW5n
IGEgbG9va3VwIHRoZSBuZXh0IHRpbWUgdGhyb3VnaA0KPj4+Pj4gLT5kX3JldmFsaWRhdGUuDQo+
Pj4+PiANCj4+Pj4+IFNpZ25lZC1vZmYtYnk6IEJlbmphbWluIENvZGRpbmd0b24gPGJjb2RkaW5n
QHJlZGhhdC5jb20+DQo+Pj4+PiAtLS0NCj4+Pj4+IGZzL25mcy9kaXIuYyB8IDE0ICsrKysrKysr
KysrKy0tDQo+Pj4+PiAxIGZpbGUgY2hhbmdlZCwgMTIgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlv
bnMoLSkNCj4+Pj4+IA0KPj4+Pj4gZGlmZiAtLWdpdCBhL2ZzL25mcy9kaXIuYyBiL2ZzL25mcy9k
aXIuYw0KPj4+Pj4gaW5kZXggNWYxYWY0Y2QxYTMzLi41ZDQwOTYxNmY3N2UgMTAwNjQ0DQo+Pj4+
PiAtLS0gYS9mcy9uZnMvZGlyLmMNCj4+Pj4+ICsrKyBiL2ZzL25mcy9kaXIuYw0KPj4+Pj4gQEAg
LTIxMDAsMTQgKzIxMDAsMjQgQEAgaW50IG5mc19yZW5hbWUoc3RydWN0IGlub2RlICpvbGRfZGly
LCBzdHJ1Y3QgZGVudHJ5ICpvbGRfZGVudHJ5LA0KPj4+Pj4gCQlkX3JlaGFzaChyZWhhc2gpOw0K
Pj4+Pj4gCXRyYWNlX25mc19yZW5hbWVfZXhpdChvbGRfZGlyLCBvbGRfZGVudHJ5LA0KPj4+Pj4g
CQkJbmV3X2RpciwgbmV3X2RlbnRyeSwgZXJyb3IpOw0KPj4+Pj4gLQlpZiAoIWVycm9yKSB7DQo+
Pj4+PiArDQo+Pj4+PiArCXN3aXRjaCAoZXJyb3IpIHsNCj4+Pj4+ICsJY2FzZSAwOg0KPj4+Pj4g
CQlpZiAobmV3X2lub2RlICE9IE5VTEwpDQo+Pj4+PiAJCQluZnNfZHJvcF9ubGluayhuZXdfaW5v
ZGUpOw0KPj4+Pj4gCQlkX21vdmUob2xkX2RlbnRyeSwgbmV3X2RlbnRyeSk7DQo+Pj4+PiAJCW5m
c19zZXRfdmVyaWZpZXIobmV3X2RlbnRyeSwNCj4+Pj4+IAkJCQkJbmZzX3NhdmVfY2hhbmdlX2F0
dHJpYnV0ZShuZXdfZGlyKSk7DQo+Pj4+PiAtCX0gZWxzZSBpZiAoZXJyb3IgPT0gLUVOT0VOVCkN
Cj4+Pj4+ICsJCWJyZWFrOw0KPj4+Pj4gKwljYXNlIC1FTk9FTlQ6DQo+Pj4+PiAJCW5mc19kZW50
cnlfaGFuZGxlX2Vub2VudChvbGRfZGVudHJ5KTsNCj4+Pj4+ICsJCWJyZWFrOw0KPj4+Pj4gKwlj
YXNlIC1FUkVTVEFSVFNZUzoNCj4+Pj4+ICsJCS8qIFRoZSByZXN1bHQgb2YgdGhlIHJlbmFtZSBp
cyB1bmtub3duLiBQbGF5IGl0IHNhZmUgYnkNCj4+Pj4+ICsJCSAqIGZvcmNpbmcgYSBuZXcgbG9v
a3VwICovDQo+Pj4+PiArCQluZnNfZm9yY2VfbG9va3VwX3JldmFsaWRhdGUob2xkX2Rpcik7DQo+
Pj4+PiArCQluZnNfZm9yY2VfbG9va3VwX3JldmFsaWRhdGUobmV3X2Rpcik7DQo+Pj4+PiArCX0N
Cj4+Pj4gDQo+Pj4+IERvZXNu4oCZdCB0aGlzIGVycm9yIGhhbmRsaW5nIGJlbG9uZyBpbiBuZnNf
YXN5bmNfcmVuYW1lX2RvbmUoKSwgb3IgcG9zc2libHkgaW4gaXRzIOKAnGRhdGEtPmNvbXBsZXRl
KCnigJ0gY2FsbGJhY2s/IFRoZXJlIGlzbuKAmXQgbXVjaCBwb2ludCBpbiBmb3JjaW5nIGEgbmV3
IGxvb2t1cCB1bnRpbCB3ZSBrbm93IHRoZSBSUEMgY2FsbCBoYXMgcnVuIGl0cyBjb3Vyc2UuDQo+
Pj4gDQo+Pj4gVGhhdCB3b3VsZCBiZSBtb3JlIGNvcnJlY3QsIGhvd2V2ZXIgaWYgbW92ZWQgdGhl
cmUsIHdlJ2QgYmUgZm9yY2luZyBhIGxvb2t1cCBhZnRlciBldmVyeSByZW5hbWUsIG5vdCBqdXN0
IGEgcmVuYW1lIHRoYXQgd2FzIHNpZ25hbGVkLiAgSXMgaXQgd29ydGggdHJ5aW5nIHRvIGZpbmQg
YSB3YXkgdG8gaW5mb3JtIHRob3NlIGZ1bmN0aW9ucyB0aGF0IHRoZSB3YWl0IHdhcyBpbnRlcnJ1
cHRlZD8NCj4+PiANCj4+IA0KPj4gVGhlcmUgYXJlIGFscmVhZHkgcHJlY2VkZW50cyBmb3IgdGhp
cy4gTG9vaywgZm9yIGluc3RhbmNlLCBhdCBob3cgdGhlIGRhdGEtPmNhbmNlbGxlZCBmbGFnIGlu
dGVyb3BlcmF0ZXMgYmV0d2VlbiBuZnM0X3J1bl9vcGVuX3Rhc2soKSBhbmQgDQo+PiBuZnM0X29w
ZW5fcmVsZWFzZSgpIHRvIHRyaWdnZXIgc3RhdGUgcmVjb3ZlcnkgKGJ5IGlzc3VpbmcgYSBjbG9z
ZSkgaWYgdGhlIFJQQyBjYWxsIHdhcyBjb21wbGV0ZWQsIGJ1dCB0aGUgdXNlciBpbnRlcnJ1cHRl
ZCB0aGUgb3BlcmF0aW9uLg0KPj4gDQo+PiBDaGVlcnMNCj4+ICBUcm9uZA0KPiANCj4gVGhlcmUg
aXMgdGhlIHRpbWluZyB0byBjb25zaWRlciBoZXJlIGFzIHdlbGwuIE9uY2UgeW91IHJldHVybiBm
cm9tIHRoaXMNCj4gZnVuY3Rpb24gdGhlIHZmcyBpcyBnb2luZyB0byB1bmxvY2sgZXZlcnl0aGlu
ZyB3aXRob3V0IGRvaW5nIHRoZSBkX21vdmUuDQo+IA0KPiBJcyBpdCBiZXR0ZXIgdG8gbWFyayB0
aGUgZGlyZWN0b3JpZXMgZm9yIHJldmFsaWRhdGlvbiBhdCB0aGF0IHBvaW50LCBvcg0KPiB3aGVu
IHRoZSBSRU5BTUUgcmVwbHkgY29tZXMgaW4/IEkgd291bGQgdGhpbmsgdGhhdCBtYXJraW5nIGl0
IGZvciByZXZhbA0KPiBpbW1lZGlhdGVseSB3b3VsZCBiZSBiZXN0LiBJcyB0aGVyZSBhbiBhcmd1
bWVudCBmb3Igd2FpdGluZz8NCj4gDQoNClNlZSBhYm92ZS4gSXQgaXMgcG9pbnRsZXNzIHRvIHJl
dmFsaWRhdGUgYmVmb3JlIHRoZSByZW5hbWUoKSBoYXMgY29tcGxldGVkLg0KDQo=