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

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

[Benjamin Coddington]

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 <bcodding@redhat.com>
---
 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

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

[Jeff Layton]

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 <bcodding@redhat.com>
> ---
>  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 <jlayton@redhat.com>

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

[Trond Myklebust]

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==

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

[Benjamin Coddington]

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

>> On Dec 15, 2016, at 09:48, Benjamin Coddington <bcodding@redhat.com> 
>> 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 <bcodding@redhat.com>
>> ---
>> 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

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

[Trond Myklebust]

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

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

[Jeff Layton]

On Fri, 2016-12-16 at 14:23 +0000, Trond Myklebust wrote:
> > 
> > On Dec 16, 2016, at 06:09, Benjamin Coddington <bcodding@redhat.com> wrote:
> > 
> > On 15 Dec 2016, at 17:38, Trond Myklebust wrote:
> > 
> > > 
> > > > 
> > > > On Dec 15, 2016, at 09:48, Benjamin Coddington <bcodding@redhat.com> 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 <bcodding@redhat.com>
> > > > ---
> > > > 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 <jlayton@poochiereds.net>

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

[Trond Myklebust]

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=