* Re: [RFC,PATCH 3/14] knfsd: prepare reply per transport
From: J. Bruce Fields @ 2007-05-18 4:08 UTC (permalink / raw)
To: Greg Banks
Cc: Linux NFS Mailing List, Iyer, Rahul, Talpey, Thomas,
Peter Leckie
In-Reply-To: <20070518040137.GD30144@fieldses.org>
On Fri, May 18, 2007 at 12:01:37AM -0400, bfields wrote:
> On Fri, May 18, 2007 at 01:16:30PM +1000, Greg Banks wrote:
> > On Thu, May 17, 2007 at 02:16:46AM -0700, Iyer, Rahul wrote:
> > > I've written some code to do NFSv4.1 callbacks and wound up implementing
> > > another "transport". Since in v4.1 it's actually possible for clients to
> > > send requests (fore-channel) and receive callbacks (back channel) over
> > > the same connection,
> >
> > A very sensible thing to do, but hard to retrofit to the existing Linux
> > code without significant surgery. As you've discovered, the server and
> > client code are two mostly-separate code bases (with mostly-separate
> > authors and maintainers) that happen to link into the same module.
> > Unifying these would be a major job. I'd love to see it happen, for
> > example to unify the XDR buffering code, but it would be an uphill
> > battle technically and possibly politically also. For some reason,
> > code (like lockd) that lives in both the server and client side tends
> > to be neglected by both camps.
> >
> > > Given this, a unified transport switch would really rock.
> > > [...] Maybe I'm oversimplifying, but this seems doable.
> >
> > Yes...eventually.
>
> And the easiest approach may be to go ahead and introduce the completely
> separate server-side transport switch and then later find ways increase
> code sharing between the two in incremental steps....
(But I don't think people who are interested in doing this should be
scared off by "politics". I'm sure careful patches would be welcomed by
everyone. Care is required, though--small differences between the
assumptions made in the two code bases can tricky. Anyway, that's my
lame excuse for why I ended up with such messy rpcsec_gss privacy code.)
--b.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC,PATCH 4/14] knfsd: has_wspace per transport
From: Greg Banks @ 2007-05-18 4:05 UTC (permalink / raw)
To: Neil Brown
Cc: J. Bruce Fields, Linux NFS Mailing List, Thomas Talpey,
Peter Leckie
In-Reply-To: <17996.11983.278205.708747@notabene.brown>
On Thu, May 17, 2007 at 08:30:39PM +1000, Neil Brown wrote:
> On Thursday May 17, gnb@sgi.com wrote:
> > On Wed, May 16, 2007 at 05:10:53PM -0400, J. Bruce Fields wrote:
> > > On Thu, May 17, 2007 at 05:22:11AM +1000, Greg Banks wrote:
> > > > + set_bit(SOCK_NOSPACE, &svsk->sk_sock->flags);
> > > > + if (required*2 > wspace) {
> > > > + /* Don't enqueue while not enough space for reply */
> > > > + dprintk("svc: socket %p no space, %d*2 > %d, not enqueued\n",
> > > > + svsk->sk_sk, required, wspace);
> > > > + return 0;
> > > > + }
> > > > + clear_bit(SOCK_NOSPACE, &svsk->sk_sock->flags);
> > > > + return 1;
> > > > +}
> > >
> > > So, this is just my ignorance--why do the set and clear of SOCK_NOSPACE
> > > need to be ordered in the way they are? (Why not just set once inside
> > > the if clause?)
> >
> > I can't see a good reason for it, but I'm trying to minimise
> > perturbations to the logic.
>
> Unfortunately, you actually perturbed the important bit... Or at
> least, the bit that I thought was important when I wrote it.
>
> Previously, sk_stream_wspace(), or sock_wspace() would be called *after*
> SOCK_NOSPACE was set. With your patch it is called *before*.
>
> It is a fairly improbably race, but if the output queue flushed
> completely between calling XX_wspace and setting SOCK_NOSPACE, the
> sk_write_space callback might never get called.
Woops. I'll fix that.
> And I gather by the fact that you test "->sko_has_wspace" that RDMA
> doesn't have such a function?
You gather correctly.
> Do that mean that RDMA will never
> reject a write due to lack of space?
No, it means that the current RDMA send code will block waiting
for space to become available. That's right, nfsd threads block on
the network. Steel yourself, there's worse to come.
> That seems unlikely.
> I would rather assume that every transport has a sko_has_wspace
> function...
Ok, but for today the RDMA one will be
static int svc_rdma_has_wspace(struct svc_sock *svsk)
{
return 1;
}
We might be able to pull the condition in the blocking logic out
of svc_rdma_send() out to implement an sko_has_wspace, but there's
something of an impedance mismatch. The RDMA queue limit is expressed
in Work Requests not bytes, and the mapping between the two is not
precisely visible at the point when has_wspace is called. I guess
we'd have to use an upper bound.
Greg.
--
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
Apparently, I'm Bedevere. Which MPHG character are you?
I don't speak for SGI.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC,PATCH 3/14] knfsd: prepare reply per transport
From: J. Bruce Fields @ 2007-05-18 4:01 UTC (permalink / raw)
To: Greg Banks
Cc: Linux NFS Mailing List, Iyer, Rahul, Talpey, Thomas,
Peter Leckie
In-Reply-To: <20070518031630.GB5104@sgi.com>
On Fri, May 18, 2007 at 01:16:30PM +1000, Greg Banks wrote:
> On Thu, May 17, 2007 at 02:16:46AM -0700, Iyer, Rahul wrote:
> > I've written some code to do NFSv4.1 callbacks and wound up implementing
> > another "transport". Since in v4.1 it's actually possible for clients to
> > send requests (fore-channel) and receive callbacks (back channel) over
> > the same connection,
>
> A very sensible thing to do, but hard to retrofit to the existing Linux
> code without significant surgery. As you've discovered, the server and
> client code are two mostly-separate code bases (with mostly-separate
> authors and maintainers) that happen to link into the same module.
> Unifying these would be a major job. I'd love to see it happen, for
> example to unify the XDR buffering code, but it would be an uphill
> battle technically and possibly politically also. For some reason,
> code (like lockd) that lives in both the server and client side tends
> to be neglected by both camps.
>
> > Given this, a unified transport switch would really rock.
> > [...] Maybe I'm oversimplifying, but this seems doable.
>
> Yes...eventually.
And the easiest approach may be to go ahead and introduce the completely
separate server-side transport switch and then later find ways increase
code sharing between the two in incremental steps....
--b.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC,PATCH 3/14] knfsd: prepare reply per transport
From: Greg Banks @ 2007-05-18 3:16 UTC (permalink / raw)
To: Iyer, Rahul; +Cc: Talpey, Thomas, Linux NFS Mailing List, Peter Leckie
In-Reply-To: <7619F3097FAB384287CF636FF92D0CA10976B38B@exsvl01.hq.netapp.com>
On Thu, May 17, 2007 at 02:16:46AM -0700, Iyer, Rahul wrote:
> Hi Greg,
> I like the idea of a transport switch for the server side. The way I see
> it, it's not just the server, it's also the "callback server" on the
> client that can benefit.
>
> I had a question. Maybe it's a dumb question, and I may be way off base,
> but I don't see why we need 2 transport switches - one for the client,
> one for the server? Why not have one?
Two separate sets of code with different requirements.
> I've written some code to do NFSv4.1 callbacks and wound up implementing
> another "transport". Since in v4.1 it's actually possible for clients to
> send requests (fore-channel) and receive callbacks (back channel) over
> the same connection,
A very sensible thing to do, but hard to retrofit to the existing Linux
code without significant surgery. As you've discovered, the server and
client code are two mostly-separate code bases (with mostly-separate
authors and maintainers) that happen to link into the same module.
Unifying these would be a major job. I'd love to see it happen, for
example to unify the XDR buffering code, but it would be an uphill
battle technically and possibly politically also. For some reason,
code (like lockd) that lives in both the server and client side tends
to be neglected by both camps.
> Given this, a unified transport switch would really rock.
> [...] Maybe I'm oversimplifying, but this seems doable.
Yes...eventually.
Greg.
--
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
Apparently, I'm Bedevere. Which MPHG character are you?
I don't speak for SGI.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [PATCH 1/2] NFS: Add the mount option "nosharecache"
From: Ian Kent @ 2007-05-18 3:12 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Neil Brown, Paul Krizak, nfs
In-Reply-To: <20070517021318.32447.94991.stgit@heimdal.trondhjem.org>
On Wed, 2007-05-16 at 22:13 -0400, Trond Myklebust wrote:
> From: Trond Myklebust <Trond.Myklebust@netapp.com>
>
> Prior to David Howell's mount changes in 2.6.18, users who mounted
> different directories which happened to be from the same filesystem on the
> server would get different super blocks, and hence could choose different
> mount options. As long as there were no hard linked files that crossed from
> one subtree to another, this was quite safe.
> Post the changes, if the two directories are on the same filesystem (have
> the same 'fsid'), they will share the same super block, and hence the same
> mount options.
>
> Add a flag to allow users to elect not to share the NFS super block with
> another mount point, even if the fsids are the same. This will allow
> users to set different mount options for the two different super blocks, as
> was previously possible. It is still up to the user to ensure that there
> are no cache coherency issues when doing this, however the default
> behaviour will be to share super blocks whenever two paths result in
> the same fsid.
>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
This looks great, thanks Trond.
I've been wondering about a couple things.
How will the "read-only bind mounts" VFS changes affect this?
When the fscache patches are merged how will this it be affect by this?
Comments please?
Ian
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC,PATCH 4/14] knfsd: has_wspace per transport
From: Neil Brown @ 2007-05-18 0:30 UTC (permalink / raw)
To: Talpey, Thomas; +Cc: nfs
In-Reply-To: <EXNANE01SlSt7IZfSp100000a27@exnane01.hq.netapp.com>
On Thursday May 17, Thomas.Talpey@netapp.com wrote:
> At 06:30 AM 5/17/2007, Neil Brown wrote:
> >And I gather by the fact that you test "->sko_has_wspace" that RDMA
> >doesn't have such a function? Do that mean that RDMA will never
> >reject a write due to lack of space? That seems unlikely.
>
> RDMA uses credits, which are preallocated per-connection resources in
> the hardware. RDMA transports don't generally support flow control, that
> is left to the upper layer. As such, if the client is obeying the protocol, the
> send will succeed. And if it's not, then the client only loses since the failure
> will cause the connection to be lost.
>
> Someday we might want to support this kind of test. There are shared
> resource schemes in RDMA, more for the receive side, but it's not out of the
> question for sends. As a default though, a NULL has_wspace makes sense.
Thanks for the explanation.
So presumably the serve communicates to the client how much buffer
space it has via these credits, so that we can be sure a write will
never fail (as long as the protocol is being honoured). That sounds
reasonable.
I think I would rather
int rdma_has_wspace(struct svc_sock *svsk) { return 1; }
than NULL. It removes special cases in the generic code, and gives an
obvious place for a comment explaining that RDMA doesn't need flow
control because it uses credits.
NeilBrown
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* [GIT] Please pull the following bugfixes for the NFS client
From: Trond Myklebust @ 2007-05-17 19:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Oleg Nesterov, nfs, linux-kernel, Nate Diller, Christoph Hellwig
SGkgTGludXMsCgpQbGVhc2UgcHVsbCBmcm9tIHRoZSByZXBvc2l0b3J5IGF0CgogICBnaXQgcHVs
bCBnaXQ6Ly9naXQubGludXgtbmZzLm9yZy9wdWIvbGludXgvbmZzLTIuNi5naXQKClRoaXMgd2ls
bCB1cGRhdGUgdGhlIGZvbGxvd2luZyBmaWxlcyB0aHJvdWdoIHRoZSBhcHBlbmRlZCBjaGFuZ2Vz
ZXRzLgoKICBDaGVlcnMsCiAgICBUcm9uZAoKLS0tLQogZnMvbG9ja2QvY2xudGxvY2suYyAgICAg
ICAgICAgICAgICB8ICAgIDIgKy0KIGZzL2xvY2tkL2hvc3QuYyAgICAgICAgICAgICAgICAgICAg
fCAgICAyICstCiBmcy9sb2NrZC94ZHIuYyAgICAgICAgICAgICAgICAgICAgIHwgICAgNCAtLQog
ZnMvbG9ja2QveGRyNC5jICAgICAgICAgICAgICAgICAgICB8ICAgIDYgKystCiBmcy9uZnMvY2Fs
bGJhY2suaCAgICAgICAgICAgICAgICAgIHwgICAgNCArLQogZnMvbmZzL2RlbGVnYXRpb24uYyAg
ICAgICAgICAgICAgICB8ICAgIDIgKy0KIGZzL25mcy9kaXIuYyAgICAgICAgICAgICAgICAgICAg
ICAgfCAgICA0ICstCiBmcy9uZnMvbmZzNHByb2MuYyAgICAgICAgICAgICAgICAgIHwgICAgNCAr
LQogZnMvbmZzL25mczRzdGF0ZS5jICAgICAgICAgICAgICAgICB8ICAgIDIgKy0KIGZzL25mcy9u
ZnM0eGRyLmMgICAgICAgICAgICAgICAgICAgfCAgIDk2ICsrKysrKysrKysrKysrKysrKy0tLS0t
LS0tLS0tLS0tLS0tLQogZnMvbmZzL3JlYWQuYyAgICAgICAgICAgICAgICAgICAgICB8ICAgMTAg
KystLQogZnMvbmZzL3dyaXRlLmMgICAgICAgICAgICAgICAgICAgICB8ICAgIDYgKy0KIGluY2x1
ZGUvbGludXgvbG9ja2QveGRyNC5oICAgICAgICAgfCAgICAxICsKIGluY2x1ZGUvbGludXgvbmZz
NC5oICAgICAgICAgICAgICAgfCAgICAzICstCiBpbmNsdWRlL2xpbnV4L3N1bnJwYy9ycGNfcGlw
ZV9mcy5oIHwgICAgMiArCiBpbmNsdWRlL2xpbnV4L3N1bnJwYy94cHJ0LmggICAgICAgIHwgICAg
MiArCiBuZXQvc3VucnBjL3NjaGVkLmMgICAgICAgICAgICAgICAgIHwgICAgMiAtCiBuZXQvc3Vu
cnBjL3N1bnJwY19zeW1zLmMgICAgICAgICAgIHwgICAgNCAtLQogMTggZmlsZXMgY2hhbmdlZCwg
NzcgaW5zZXJ0aW9ucygrKSwgNzkgZGVsZXRpb25zKC0pCgpjb21taXQgNzUzMWQ2OTJkNDE3NDc4
OWQ1ODNlYjUwZmNiODNjZWZhMTIxYjc5MApBdXRob3I6IFRyb25kIE15a2xlYnVzdCA8VHJvbmQu
TXlrbGVidXN0QG5ldGFwcC5jb20+CkRhdGU6ICAgTW9uIE1heSAxNCAxNzoyMToyNiAyMDA3IC0w
NDAwCgogICAgU1VOUlBDOiBGaXggc3BhcnNlIHdhcm5pbmdzCiAgICAKICAgICAtIG5ldC9zdW5y
cGMveHBydHNvY2suYzoxNjM1OjU6IHdhcm5pbmc6IHN5bWJvbCAnaW5pdF9zb2NrZXRfeHBydCcg
d2FzIG5vdAogICAgICAgZGVjbGFyZWQuIFNob3VsZCBpdCBiZSBzdGF0aWM/CiAgICAgLSBuZXQv
c3VucnBjL3hwcnRzb2NrLmM6MTY0OTo2OiB3YXJuaW5nOiBzeW1ib2wgJ2NsZWFudXBfc29ja2V0
X3hwcnQnIHdhcwogICAgICAgbm90IGRlY2xhcmVkLiBTaG91bGQgaXQgYmUgc3RhdGljPwogICAg
CiAgICBTaWduZWQtb2ZmLWJ5OiBUcm9uZCBNeWtsZWJ1c3QgPFRyb25kLk15a2xlYnVzdEBuZXRh
cHAuY29tPgoKY29tbWl0IGQ0OGM1ZjQxMDAwYWQxNzZkZjcxZDJkNDM5MzJjNmM1MGY5MzgxOTYK
QXV0aG9yOiBUcm9uZCBNeWtsZWJ1c3QgPFRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tPgpEYXRl
OiAgIE1vbiBNYXkgMTQgMTc6MjE6MjYgMjAwNyAtMDQwMAoKICAgIE5MTTogRml4IHNwYXJzZSB3
YXJuaW5ncwogICAgCiAgICAgLSBmcy9sb2NrZC94ZHI0LmM6MTQwOjI3OiB3YXJuaW5nOiBpbmNv
cnJlY3QgdHlwZSBpbiBhcmd1bWVudCAyIChkaWZmZXJlbnQKICAgICAgIGV4cGxpY2l0IHNpZ25l
ZG5lc3MpCiAgICAgLSBmcy9sb2NrZC94ZHI0LmM6MTQxOjI3OiB3YXJuaW5nOiBpbmNvcnJlY3Qg
dHlwZSBpbiBhcmd1bWVudCAyIChkaWZmZXJlbnQKICAgICAgIGV4cGxpY2l0IHNpZ25lZG5lc3Mp
CiAgICAgLSBmcy9sb2NrZC94ZHI0LmM6NDMyOjI4OiB3YXJuaW5nOiBpbmNvcnJlY3QgdHlwZSBp
biBhcmd1bWVudCAyIChkaWZmZXJlbnQKICAgICAgIGV4cGxpY2l0IHNpZ25lZG5lc3MpCiAgICAg
LSBmcy9sb2NrZC94ZHI0LmM6NDMzOjI4OiB3YXJuaW5nOiBpbmNvcnJlY3QgdHlwZSBpbiBhcmd1
bWVudCAyIChkaWZmZXJlbnQKICAgICAgIGV4cGxpY2l0IHNpZ25lZG5lc3MpCiAgICAgLSBmcy9s
b2NrZC94ZHI0LmM6NTg3OjIwOiB3YXJuaW5nOiBzeW1ib2wgJ25sbV92ZXJzaW9uNCcgd2FzIG5v
dCBkZWNsYXJlZC4KICAgICAgIFNob3VsZCBpdCBiZSBzdGF0aWM/CiAgICAKICAgIFNpZ25lZC1v
ZmYtYnk6IFRyb25kIE15a2xlYnVzdCA8VHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20+Cgpjb21t
aXQgMmU0MmMzZTJhZWM2ZTI0ZTU4YzRjNjAxZTFhMzNmMGU5ZTM2ZTMxNApBdXRob3I6IFRyb25k
IE15a2xlYnVzdCA8VHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20+CkRhdGU6ICAgTW9uIE1heSAx
NCAxNzoyMDo0MSAyMDA3IC0wNDAwCgogICAgTkZTOiBGaXggbW9yZSBzcGFyc2Ugd2FybmluZ3MK
ICAgIAogICAgIC0gZnMvbmZzL25mczR4ZHIuYzoyNDk5OjQyOiB3YXJuaW5nOiBpbmNvcnJlY3Qg
dHlwZSBpbiBhcmd1bWVudCAyCiAgICAgICAoZGlmZmVyZW50IHNpZ25lZG5lc3MpCiAgICAgLSBm
cy9uZnMvbmZzNHhkci5jOjI2NTg6NDk6IHdhcm5pbmc6IGluY29ycmVjdCB0eXBlIGluIGFyZ3Vt
ZW50IDQKICAgICAgIChkaWZmZXJlbnQgZXhwbGljaXQgc2lnbmVkbmVzcykKICAgICAtIGZzL25m
cy9uZnM0eGRyLmM6MjY4Mzo1MDogd2FybmluZzogaW5jb3JyZWN0IHR5cGUgaW4gYXJndW1lbnQg
NAogICAgICAgKGRpZmZlcmVudCBleHBsaWNpdCBzaWduZWRuZXNzKQogICAgIC0gZnMvbmZzL25m
czR4ZHIuYzozMDYzOjY4OiB3YXJuaW5nOiBpbmNvcnJlY3QgdHlwZSBpbiBhcmd1bWVudCA0CiAg
ICAgICAoZGlmZmVyZW50IGV4cGxpY2l0IHNpZ25lZG5lc3MpCiAgICAgLSBmcy9uZnMvbmZzNHhk
ci5jOjMwNjU6Njg6IHdhcm5pbmc6IGluY29ycmVjdCB0eXBlIGluIGFyZ3VtZW50IDQKICAgICAg
IChkaWZmZXJlbnQgZXhwbGljaXQgc2lnbmVkbmVzcykKICAgIAogICAgIC0gZnMvbmZzL2NhbGxi
YWNrX3hkci5jOjEzODozMTogd2FybmluZzogaW5jb3JyZWN0IHR5cGUgaW4gYXJndW1lbnQgMgog
ICAgICAgKGRpZmZlcmVudCBzaWduZWRuZXNzKQogICAgCiAgICBTaWduZWQtb2ZmLWJ5OiBUcm9u
ZCBNeWtsZWJ1c3QgPFRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tPgoKY29tbWl0IDEwYWZlYzkw
ODFmZWU3ZTQ4OTk1ZmEzOTZmYmEyMmM3ZGU0Yjk5ZDQKQXV0aG9yOiBUcm9uZCBNeWtsZWJ1c3Qg
PFRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tPgpEYXRlOiAgIE1vbiBNYXkgMTQgMTc6MTY6MDQg
MjAwNyAtMDQwMAoKICAgIE5GUzogRml4IHNvbWUgJ3NwYXJzZScgd2FybmluZ3MuLi4KICAgIAog
ICAgIC0gZnMvbmZzL2Rpci5jOjYxMDo4OiB3YXJuaW5nOiBzeW1ib2wgJ25mc19sbHNlZWtfZGly
JyB3YXMgbm90IGRlY2xhcmVkLgogICAgICAgU2hvdWxkIGl0IGJlIHN0YXRpYz8KICAgICAtIGZz
L25mcy9kaXIuYzo2MzY6NTogd2FybmluZzogc3ltYm9sICduZnNfZnN5bmNfZGlyJyB3YXMgbm90
IGRlY2xhcmVkLgogICAgICAgU2hvdWxkIGl0IGJlIHN0YXRpYz8KICAgICAtIGZzL25mcy93cml0
ZS5jOjkyNToxOTogd2FybmluZzogc3ltYm9sICdyZXEnIHNoYWRvd3MgYW4gZWFybGllciBvbmUK
ICAgICAtIGZzL25mcy93cml0ZS5jOjYxOjY6IHdhcm5pbmc6IHN5bWJvbCAnbmZzX2NvbW1pdF9y
Y3VfZnJlZScgd2FzIG5vdAogICAgICAgZGVjbGFyZWQuIFNob3VsZCBpdCBiZSBzdGF0aWM/CiAg
ICAgLSBmcy9uZnMvbmZzNHByb2MuYzo3OTM6NTogd2FybmluZzogc3ltYm9sICduZnM0X3JlY292
ZXJfZXhwaXJlZF9sZWFzZScKICAgICAgIHdhcyBub3QgZGVjbGFyZWQuIFNob3VsZCBpdCBiZSBz
dGF0aWM/CiAgICAKICAgIFNpZ25lZC1vZmYtYnk6IFRyb25kIE15a2xlYnVzdCA8VHJvbmQuTXlr
bGVidXN0QG5ldGFwcC5jb20+Cgpjb21taXQgOWM5Y2M5M2FkMmE1ZDk5NzI2NzJlMDM2ODVhZjIw
ZThjZWExZTVhNApBdXRob3I6IENocmlzdG9waCBIZWxsd2lnIDxoY2hAaW5mcmFkZWFkLm9yZz4K
RGF0ZTogICBGcmkgRmViIDkgMjA6MDY6NDkgMjAwNyArMDAwMAoKICAgIFNVTlJQQzogcmVtb3Zl
IGRlYWQgdmFyaWFibGUgJ3JwY2lvZF9ydW5uaW5nJwogICAgCiAgICBycGNpb2RfcnVubmluZyBp
cyBub3QgdXNlZCBhdCBhbGwsIGJ1dCBkdWUgdG8gdGhlIHdheSBERUNMQVJFX01VVEVYX0xPQ0tF
RAogICAgd29ya3Mgd2UgZG9uJ3QgZ2V0IGEgd2FybmluZyBmb3IgaXQuCiAgICAKICAgIAogICAg
U2lnbmVkLW9mZi1ieTogQ2hyaXN0b3BoIEhlbGx3aWcgPGhjaEBsc3QuZGU+CiAgICBTaWduZWQt
b2ZmLWJ5OiBUcm9uZCBNeWtsZWJ1c3QgPFRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tPgoKY29t
bWl0IDhhZTIwYWJkZDE4YzZjN2YyMWJiYWU5MzEzNTNlN2NmYWQ3N2Q3YjYKQXV0aG9yOiBUcm9u
ZCBNeWtsZWJ1c3QgPFRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tPgpEYXRlOiAgIE1vbiBNYXkg
MTQgMTY6NTA6NDUgMjAwNyAtMDQwMAoKICAgIE5GUzQ6IEZpeCBpbmNvcnJlY3QgdXNlIG9mIHNp
emVvZigpIGluIGZzL25mcy9uZnM0eGRyLmMKICAgIAogICAgVGhlIFhEUiBjb2RlIHNob3VsZCBu
b3QgZGVwZW5kIG9uIHRoZSBwaHlzaWNhbCBhbGxvY2F0aW9uIHNpemUgb2YKICAgIHN0cnVjdHVy
ZXMgbGlrZSBuZnM0X3N0YXRlaWQgYW5kIG5mczRfdmVyaWZpZXIgc2luY2UgdGhvc2UgbWF5IGhh
dmUgdG8KICAgIGNoYW5nZSBhdCBzb21lIGZ1dHVyZSBkYXRlLiBXZSB0aGVyZWZvcmUgcmVwbGFj
ZSBhbGwgdXNlcyBvZgogICAgc2l6ZW9mKCkgd2l0aCBjb25zdGFudHMgbGlrZSBORlM0X1ZFUklG
SUVSX1NJWkUgYW5kIE5GUzRfU1RBVEVJRF9TSVpFLgogICAgCiAgICBUaGlzIGFsc28gaGFzIHRo
ZSBzaWRlLWVmZmVjdCBvZiBmaXhpbmcgc29tZSB3YXJuaW5ncyBvZiB0aGUgdHlwZQogICAgCWZv
cm1hdCDigJgldeKAmSBleHBlY3RzIHR5cGUg4oCYdW5zaWduZWQgaW504oCZLCBidXQgYXJndW1l
bnQgWCBoYXMgdHlwZQogICAgCQnigJhsb25nIHVuc2lnbmVkIGludOKAmQogICAgb24gNjQtYml0
IHN5c3RlbXMKICAgIAogICAgU2lnbmVkLW9mZi1ieTogVHJvbmQgTXlrbGVidXN0IDxUcm9uZC5N
eWtsZWJ1c3RAbmV0YXBwLmNvbT4KCmNvbW1pdCA2MDk0NWNiN2M4Mzc3YjcyNzI4ODI3NWYyMTc5
MTkxNGZlNjUzMTFjCkF1dGhvcjogTmF0ZSBEaWxsZXIgPG5hdGUuZGlsbGVyQGdtYWlsLmNvbT4K
RGF0ZTogICBUaHUgTWF5IDEwIDIyOjU1OjA4IDIwMDcgLTA3MDAKCiAgICBORlM6IHVzZSB6ZXJv
X3VzZXJfcGFnZQogICAgCiAgICBVc2UgemVyb191c2VyX3BhZ2UoKSBpbnN0ZWFkIG9mIHRoZSBu
ZXdseSBkZXByZWNhdGVkIG1lbWNsZWFyX2hpZ2hwYWdlX2ZsdXNoKCkuCiAgICAKICAgIFNpZ25l
ZC1vZmYtYnk6IE5hdGUgRGlsbGVyIDxuYXRlLmRpbGxlckBnbWFpbC5jb20+CiAgICBDYzogVHJv
bmQgTXlrbGVidXN0IDx0cm9uZC5teWtsZWJ1c3RAZnlzLnVpby5ubz4KICAgIENjOiAiSi4gQnJ1
Y2UgRmllbGRzIiA8YmZpZWxkc0BmaWVsZHNlcy5vcmc+CiAgICBTaWduZWQtb2ZmLWJ5OiBBbmRy
ZXcgTW9ydG9uIDxha3BtQGxpbnV4LWZvdW5kYXRpb24ub3JnPgogICAgU2lnbmVkLW9mZi1ieTog
VHJvbmQgTXlrbGVidXN0IDxUcm9uZC5NeWtsZWJ1c3RAbmV0YXBwLmNvbT4KCmNvbW1pdCA1NTBm
YWNkMTM4ZDhmNmIwY2E2ODNjMWU4OTRiNWNkMGYzODFjYjYzCkF1dGhvcjogT2xlZyBOZXN0ZXJv
diA8b2xlZ0B0di1zaWduLnJ1PgpEYXRlOiAgIFRodSBNYXkgMTAgMjI6NTU6MDcgMjAwNyAtMDcw
MAoKICAgIE5MTTogZG9uJ3QgdXNlIENMT05FX1NJR0hBTkQgaW4gbmxtY2xudF9yZWNvdmVyeQog
ICAgCiAgICByZWNsYWltZXIoKSBjYWxscyBhbGxvd19zaWduYWwoKSB3aGljaCBwbGF5cyB3aXRo
IHBhcmVudCBwcm9jZXNzJ3MgLT5zaWdoYW5kLgogICAgCiAgICBTaWduZWQtb2ZmLWJ5OiBPbGVn
IE5lc3Rlcm92IDxvbGVnQHR2LXNpZ24ucnU+CiAgICBDYzogVHJvbmQgTXlrbGVidXN0IDx0cm9u
ZC5teWtsZWJ1c3RAZnlzLnVpby5ubz4KICAgIENjOiAiSi4gQnJ1Y2UgRmllbGRzIiA8YmZpZWxk
c0BmaWVsZHNlcy5vcmc+CiAgICBDYzogTmVpbCBCcm93biA8bmVpbGJAc3VzZS5kZT4KICAgIFNp
Z25lZC1vZmYtYnk6IEFuZHJldyBNb3J0b24gPGFrcG1AbGludXgtZm91bmRhdGlvbi5vcmc+CiAg
ICBTaWduZWQtb2ZmLWJ5OiBUcm9uZCBNeWtsZWJ1c3QgPFRyb25kLk15a2xlYnVzdEBuZXRhcHAu
Y29tPgoKY29tbWl0IDIxMDUxYmE2MjU5YzUxOWUyMGE3ZDU3NWRkY2ViMTZlODRhZDJhNWQKQXV0
aG9yOiBUcm9uZCBNeWtsZWJ1c3QgPFRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tPgpEYXRlOiAg
IE1vbiBNYXkgMTQgMTY6NTA6NDQgMjAwNyAtMDQwMAoKICAgIE5MTTogRml4IGxvY2tpbmcgY2xp
ZW50IHRpbWVvdXRzLi4uCiAgICAKICAgIG5sbXN2Y190aW1lb3V0IGlzIGFscmVhZHkgaW4gdW5p
dHMgb2YgSFouLi4KICAgIAogICAgU2lnbmVkLW9mZi1ieTogVHJvbmQgTXlrbGVidXN0IDxUcm9u
ZC5NeWtsZWJ1c3RAbmV0YXBwLmNvbT4KCmRpZmYgLS1naXQgYS9mcy9sb2NrZC9jbG50bG9jay5j
IGIvZnMvbG9ja2QvY2xudGxvY2suYwppbmRleCBmNGQ0NWQ0Li5kMDcwYjE4IDEwMDY0NAotLS0g
YS9mcy9sb2NrZC9jbG50bG9jay5jCisrKyBiL2ZzL2xvY2tkL2NsbnRsb2NrLmMKQEAgLTE1Myw3
ICsxNTMsNyBAQCBubG1jbG50X3JlY292ZXJ5KHN0cnVjdCBubG1faG9zdCAqaG9zdCkKIAlpZiAo
IWhvc3QtPmhfcmVjbGFpbWluZysrKSB7CiAJCW5sbV9nZXRfaG9zdChob3N0KTsKIAkJX19tb2R1
bGVfZ2V0KFRISVNfTU9EVUxFKTsKLQkJaWYgKGtlcm5lbF90aHJlYWQocmVjbGFpbWVyLCBob3N0
LCBDTE9ORV9LRVJORUwpIDwgMCkKKwkJaWYgKGtlcm5lbF90aHJlYWQocmVjbGFpbWVyLCBob3N0
LCBDTE9ORV9GUyB8IENMT05FX0ZJTEVTKSA8IDApCiAJCQltb2R1bGVfcHV0KFRISVNfTU9EVUxF
KTsKIAl9CiB9CmRpZmYgLS1naXQgYS9mcy9sb2NrZC9ob3N0LmMgYi9mcy9sb2NrZC9ob3N0LmMK
aW5kZXggYWQyMWMwNy4uOTYwNzBiZiAxMDA2NDQKLS0tIGEvZnMvbG9ja2QvaG9zdC5jCisrKyBi
L2ZzL2xvY2tkL2hvc3QuYwpAQCAtMjIxLDcgKzIyMSw3IEBAIG5sbV9iaW5kX2hvc3Qoc3RydWN0
IG5sbV9ob3N0ICpob3N0KQogCQkJCQlob3N0LT5oX25leHRyZWJpbmQgLSBqaWZmaWVzKTsKIAkJ
fQogCX0gZWxzZSB7Ci0JCXVuc2lnbmVkIGxvbmcgaW5jcmVtZW50ID0gbmxtc3ZjX3RpbWVvdXQg
KiBIWjsKKwkJdW5zaWduZWQgbG9uZyBpbmNyZW1lbnQgPSBubG1zdmNfdGltZW91dDsKIAkJc3Ry
dWN0IHJwY190aW1lb3V0IHRpbWVwYXJtcyA9IHsKIAkJCS50b19pbml0dmFsCT0gaW5jcmVtZW50
LAogCQkJLnRvX2luY3JlbWVudAk9IGluY3JlbWVudCwKZGlmZiAtLWdpdCBhL2ZzL2xvY2tkL3hk
ci5jIGIvZnMvbG9ja2QveGRyLmMKaW5kZXggOTcwMjk1Ni4uNTMxNmUzMCAxMDA2NDQKLS0tIGEv
ZnMvbG9ja2QveGRyLmMKKysrIGIvZnMvbG9ja2QveGRyLmMKQEAgLTU4NiwxMCArNTg2LDYgQEAg
c3RhdGljIHN0cnVjdCBycGNfdmVyc2lvbglubG1fdmVyc2lvbjMgPSB7CiAJCS5wcm9jcwkJPSBu
bG1fcHJvY2VkdXJlcywKIH07CiAKLSNpZmRlZiAJQ09ORklHX0xPQ0tEX1Y0Ci1leHRlcm4gc3Ry
dWN0IHJwY192ZXJzaW9uIG5sbV92ZXJzaW9uNDsKLSNlbmRpZgotCiBzdGF0aWMgc3RydWN0IHJw
Y192ZXJzaW9uICoJbmxtX3ZlcnNpb25zW10gPSB7CiAJWzFdID0gJm5sbV92ZXJzaW9uMSwKIAlb
M10gPSAmbmxtX3ZlcnNpb24zLApkaWZmIC0tZ2l0IGEvZnMvbG9ja2QveGRyNC5jIGIvZnMvbG9j
a2QveGRyNC5jCmluZGV4IGNlMWVmZGIuLjg0NmZjMWQgMTAwNjQ0Ci0tLSBhL2ZzL2xvY2tkL3hk
cjQuYworKysgYi9mcy9sb2NrZC94ZHI0LmMKQEAgLTEyMyw3ICsxMjMsOCBAQCBzdGF0aWMgX19i
ZTMyICoKIG5sbTRfZGVjb2RlX2xvY2soX19iZTMyICpwLCBzdHJ1Y3QgbmxtX2xvY2sgKmxvY2sp
CiB7CiAJc3RydWN0IGZpbGVfbG9jawkqZmwgPSAmbG9jay0+Zmw7Ci0JX19zNjQJCQlsZW4sIHN0
YXJ0LCBlbmQ7CisJX191NjQJCQlsZW4sIHN0YXJ0OworCV9fczY0CQkJZW5kOwogCiAJaWYgKCEo
cCA9IHhkcl9kZWNvZGVfc3RyaW5nX2lucGxhY2UocCwgJmxvY2stPmNhbGxlciwKIAkJCQkJICAg
ICZsb2NrLT5sZW4sIE5MTV9NQVhTVFJMRU4pKQpAQCAtNDE3LDcgKzQxOCw4IEBAIG5sbTRjbHRf
ZGVjb2RlX3Rlc3RyZXMoc3RydWN0IHJwY19ycXN0ICpyZXEsIF9fYmUzMiAqcCwgc3RydWN0IG5s
bV9yZXMgKnJlc3ApCiAJaWYgKHJlc3AtPnN0YXR1cyA9PSBubG1fbGNrX2RlbmllZCkgewogCQlz
dHJ1Y3QgZmlsZV9sb2NrCSpmbCA9ICZyZXNwLT5sb2NrLmZsOwogCQl1MzIJCQlleGNsOwotCQlz
NjQJCQlzdGFydCwgZW5kLCBsZW47CisJCV9fdTY0CQkJc3RhcnQsIGxlbjsKKwkJX19zNjQJCQll
bmQ7CiAKIAkJbWVtc2V0KCZyZXNwLT5sb2NrLCAwLCBzaXplb2YocmVzcC0+bG9jaykpOwogCQls
b2Nrc19pbml0X2xvY2soZmwpOwpkaWZmIC0tZ2l0IGEvZnMvbmZzL2NhbGxiYWNrLmggYi9mcy9u
ZnMvY2FsbGJhY2suaAppbmRleCBkYjNkNzkxLi5jMmJiMTRlIDEwMDY0NAotLS0gYS9mcy9uZnMv
Y2FsbGJhY2suaAorKysgYi9mcy9uZnMvY2FsbGJhY2suaApAQCAtMjQsNyArMjQsNyBAQCBlbnVt
IG5mczRfY2FsbGJhY2tfb3BudW0gewogfTsKIAogc3RydWN0IGNiX2NvbXBvdW5kX2hkcl9hcmcg
ewotCWludCB0YWdsZW47CisJdW5zaWduZWQgaW50IHRhZ2xlbjsKIAljb25zdCBjaGFyICp0YWc7
CiAJdW5zaWduZWQgaW50IGNhbGxiYWNrX2lkZW50OwogCXVuc2lnbmVkIG5vcHM7CkBAIC0zMiw3
ICszMiw3IEBAIHN0cnVjdCBjYl9jb21wb3VuZF9oZHJfYXJnIHsKIAogc3RydWN0IGNiX2NvbXBv
dW5kX2hkcl9yZXMgewogCV9fYmUzMiAqc3RhdHVzOwotCWludCB0YWdsZW47CisJdW5zaWduZWQg
aW50IHRhZ2xlbjsKIAljb25zdCBjaGFyICp0YWc7CiAJX19iZTMyICpub3BzOwogfTsKZGlmZiAt
LWdpdCBhL2ZzL25mcy9kZWxlZ2F0aW9uLmMgYi9mcy9uZnMvZGVsZWdhdGlvbi5jCmluZGV4IDg0
MWM5OWEuLjdmMzdkMWIgMTAwNjQ0Ci0tLSBhL2ZzL25mcy9kZWxlZ2F0aW9uLmMKKysrIGIvZnMv
bmZzL2RlbGVnYXRpb24uYwpAQCAtMjI2LDcgKzIyNiw3IEBAIHJlc3RhcnQ6CiAJc3Bpbl91bmxv
Y2soJmNscC0+Y2xfbG9jayk7CiB9CiAKLWludCBuZnNfZG9fZXhwaXJlX2FsbF9kZWxlZ2F0aW9u
cyh2b2lkICpwdHIpCitzdGF0aWMgaW50IG5mc19kb19leHBpcmVfYWxsX2RlbGVnYXRpb25zKHZv
aWQgKnB0cikKIHsKIAlzdHJ1Y3QgbmZzX2NsaWVudCAqY2xwID0gcHRyOwogCXN0cnVjdCBuZnNf
ZGVsZWdhdGlvbiAqZGVsZWdhdGlvbjsKZGlmZiAtLWdpdCBhL2ZzL25mcy9kaXIuYyBiL2ZzL25m
cy9kaXIuYwppbmRleCAzZGY0Mjg4Li5hYzkyZTQ1IDEwMDY0NAotLS0gYS9mcy9uZnMvZGlyLmMK
KysrIGIvZnMvbmZzL2Rpci5jCkBAIC02MDcsNyArNjA3LDcgQEAgc3RhdGljIGludCBuZnNfcmVh
ZGRpcihzdHJ1Y3QgZmlsZSAqZmlscCwgdm9pZCAqZGlyZW50LCBmaWxsZGlyX3QgZmlsbGRpcikK
IAlyZXR1cm4gcmVzOwogfQogCi1sb2ZmX3QgbmZzX2xsc2Vla19kaXIoc3RydWN0IGZpbGUgKmZp
bHAsIGxvZmZfdCBvZmZzZXQsIGludCBvcmlnaW4pCitzdGF0aWMgbG9mZl90IG5mc19sbHNlZWtf
ZGlyKHN0cnVjdCBmaWxlICpmaWxwLCBsb2ZmX3Qgb2Zmc2V0LCBpbnQgb3JpZ2luKQogewogCW11
dGV4X2xvY2soJmZpbHAtPmZfcGF0aC5kZW50cnktPmRfaW5vZGUtPmlfbXV0ZXgpOwogCXN3aXRj
aCAob3JpZ2luKSB7CkBAIC02MzMsNyArNjMzLDcgQEAgb3V0OgogICogQWxsIGRpcmVjdG9yeSBv
cGVyYXRpb25zIHVuZGVyIE5GUyBhcmUgc3luY2hyb25vdXMsIHNvIGZzeW5jKCkKICAqIGlzIGEg
ZHVtbXkgb3BlcmF0aW9uLgogICovCi1pbnQgbmZzX2ZzeW5jX2RpcihzdHJ1Y3QgZmlsZSAqZmls
cCwgc3RydWN0IGRlbnRyeSAqZGVudHJ5LCBpbnQgZGF0YXN5bmMpCitzdGF0aWMgaW50IG5mc19m
c3luY19kaXIoc3RydWN0IGZpbGUgKmZpbHAsIHN0cnVjdCBkZW50cnkgKmRlbnRyeSwgaW50IGRh
dGFzeW5jKQogewogCWRmcHJpbnRrKFZGUywgIk5GUzogZnN5bmNfZGlyKCVzLyVzKSBkYXRhc3lu
YyAlZFxuIiwKIAkJCWRlbnRyeS0+ZF9wYXJlbnQtPmRfbmFtZS5uYW1lLCBkZW50cnktPmRfbmFt
ZS5uYW1lLApkaWZmIC0tZ2l0IGEvZnMvbmZzL25mczRwcm9jLmMgYi9mcy9uZnMvbmZzNHByb2Mu
YwppbmRleCBkNmEzMGU5Li42NDhlMGFjIDEwMDY0NAotLS0gYS9mcy9uZnMvbmZzNHByb2MuYwor
KysgYi9mcy9uZnMvbmZzNHByb2MuYwpAQCAtNzkwLDcgKzc5MCw3IEBAIG91dDoKIAlyZXR1cm4g
LUVBQ0NFUzsKIH0KIAotaW50IG5mczRfcmVjb3Zlcl9leHBpcmVkX2xlYXNlKHN0cnVjdCBuZnNf
c2VydmVyICpzZXJ2ZXIpCitzdGF0aWMgaW50IG5mczRfcmVjb3Zlcl9leHBpcmVkX2xlYXNlKHN0
cnVjdCBuZnNfc2VydmVyICpzZXJ2ZXIpCiB7CiAJc3RydWN0IG5mc19jbGllbnQgKmNscCA9IHNl
cnZlci0+bmZzX2NsaWVudDsKIAlpbnQgcmV0OwpAQCAtMjc0OCw3ICsyNzQ4LDcgQEAgc3RhdGlj
IGludCBuZnM0X2RlbGF5KHN0cnVjdCBycGNfY2xudCAqY2xudCwgbG9uZyAqdGltZW91dCkKIC8q
IFRoaXMgaXMgdGhlIGVycm9yIGhhbmRsaW5nIHJvdXRpbmUgZm9yIHByb2Nlc3NlcyB0aGF0IGFy
ZSBhbGxvd2VkCiAgKiB0byBzbGVlcC4KICAqLwotaW50IG5mczRfaGFuZGxlX2V4Y2VwdGlvbihj
b25zdCBzdHJ1Y3QgbmZzX3NlcnZlciAqc2VydmVyLCBpbnQgZXJyb3Jjb2RlLCBzdHJ1Y3QgbmZz
NF9leGNlcHRpb24gKmV4Y2VwdGlvbikKK3N0YXRpYyBpbnQgbmZzNF9oYW5kbGVfZXhjZXB0aW9u
KGNvbnN0IHN0cnVjdCBuZnNfc2VydmVyICpzZXJ2ZXIsIGludCBlcnJvcmNvZGUsIHN0cnVjdCBu
ZnM0X2V4Y2VwdGlvbiAqZXhjZXB0aW9uKQogewogCXN0cnVjdCBuZnNfY2xpZW50ICpjbHAgPSBz
ZXJ2ZXItPm5mc19jbGllbnQ7CiAJaW50IHJldCA9IGVycm9yY29kZTsKZGlmZiAtLWdpdCBhL2Zz
L25mcy9uZnM0c3RhdGUuYyBiL2ZzL25mcy9uZnM0c3RhdGUuYwppbmRleCA1ZmZmYmRmLi44ZWQ3
OWQ1IDEwMDY0NAotLS0gYS9mcy9uZnMvbmZzNHN0YXRlLmMKKysrIGIvZnMvbmZzL25mczRzdGF0
ZS5jCkBAIC0xMDQsNyArMTA0LDcgQEAgc3RydWN0IHJwY19jcmVkICpuZnM0X2dldF9yZW5ld19j
cmVkKHN0cnVjdCBuZnNfY2xpZW50ICpjbHApCiAJcmV0dXJuIGNyZWQ7CiB9CiAKLXN0cnVjdCBy
cGNfY3JlZCAqbmZzNF9nZXRfc2V0Y2xpZW50aWRfY3JlZChzdHJ1Y3QgbmZzX2NsaWVudCAqY2xw
KQorc3RhdGljIHN0cnVjdCBycGNfY3JlZCAqbmZzNF9nZXRfc2V0Y2xpZW50aWRfY3JlZChzdHJ1
Y3QgbmZzX2NsaWVudCAqY2xwKQogewogCXN0cnVjdCBuZnM0X3N0YXRlX293bmVyICpzcDsKIApk
aWZmIC0tZ2l0IGEvZnMvbmZzL25mczR4ZHIuYyBiL2ZzL25mcy9uZnM0eGRyLmMKaW5kZXggOTM4
ZjM3MS4uODAwM2M5MSAxMDA2NDQKLS0tIGEvZnMvbmZzL25mczR4ZHIuYworKysgYi9mcy9uZnMv
bmZzNHhkci5jCkBAIC02NDYsMTAgKzY0NiwxMCBAQCBzdGF0aWMgaW50IGVuY29kZV9jbG9zZShz
dHJ1Y3QgeGRyX3N0cmVhbSAqeGRyLCBjb25zdCBzdHJ1Y3QgbmZzX2Nsb3NlYXJncyAqYXJnKQog
ewogCV9fYmUzMiAqcDsKIAotCVJFU0VSVkVfU1BBQ0UoOCtzaXplb2YoYXJnLT5zdGF0ZWlkLT5k
YXRhKSk7CisJUkVTRVJWRV9TUEFDRSg4K05GUzRfU1RBVEVJRF9TSVpFKTsKIAlXUklURTMyKE9Q
X0NMT1NFKTsKIAlXUklURTMyKGFyZy0+c2VxaWQtPnNlcXVlbmNlLT5jb3VudGVyKTsKLQlXUklU
RU1FTShhcmctPnN0YXRlaWQtPmRhdGEsIHNpemVvZihhcmctPnN0YXRlaWQtPmRhdGEpKTsKKwlX
UklURU1FTShhcmctPnN0YXRlaWQtPmRhdGEsIE5GUzRfU1RBVEVJRF9TSVpFKTsKIAkKIAlyZXR1
cm4gMDsKIH0KQEAgLTc5MywxNyArNzkzLDE3IEBAIHN0YXRpYyBpbnQgZW5jb2RlX2xvY2soc3Ry
dWN0IHhkcl9zdHJlYW0gKnhkciwgY29uc3Qgc3RydWN0IG5mc19sb2NrX2FyZ3MgKmFyZ3MpCiAJ
V1JJVEU2NChuZnM0X2xvY2tfbGVuZ3RoKGFyZ3MtPmZsKSk7CiAJV1JJVEUzMihhcmdzLT5uZXdf
bG9ja19vd25lcik7CiAJaWYgKGFyZ3MtPm5ld19sb2NrX293bmVyKXsKLQkJUkVTRVJWRV9TUEFD
RSg0MCk7CisJCVJFU0VSVkVfU1BBQ0UoNCtORlM0X1NUQVRFSURfU0laRSsyMCk7CiAJCVdSSVRF
MzIoYXJncy0+b3Blbl9zZXFpZC0+c2VxdWVuY2UtPmNvdW50ZXIpOwotCQlXUklURU1FTShhcmdz
LT5vcGVuX3N0YXRlaWQtPmRhdGEsIHNpemVvZihhcmdzLT5vcGVuX3N0YXRlaWQtPmRhdGEpKTsK
KwkJV1JJVEVNRU0oYXJncy0+b3Blbl9zdGF0ZWlkLT5kYXRhLCBORlM0X1NUQVRFSURfU0laRSk7
CiAJCVdSSVRFMzIoYXJncy0+bG9ja19zZXFpZC0+c2VxdWVuY2UtPmNvdW50ZXIpOwogCQlXUklU
RTY0KGFyZ3MtPmxvY2tfb3duZXIuY2xpZW50aWQpOwogCQlXUklURTMyKDQpOwogCQlXUklURTMy
KGFyZ3MtPmxvY2tfb3duZXIuaWQpOwogCX0KIAllbHNlIHsKLQkJUkVTRVJWRV9TUEFDRSgyMCk7
Ci0JCVdSSVRFTUVNKGFyZ3MtPmxvY2tfc3RhdGVpZC0+ZGF0YSwgc2l6ZW9mKGFyZ3MtPmxvY2tf
c3RhdGVpZC0+ZGF0YSkpOworCQlSRVNFUlZFX1NQQUNFKE5GUzRfU1RBVEVJRF9TSVpFKzQpOwor
CQlXUklURU1FTShhcmdzLT5sb2NrX3N0YXRlaWQtPmRhdGEsIE5GUzRfU1RBVEVJRF9TSVpFKTsK
IAkJV1JJVEUzMihhcmdzLT5sb2NrX3NlcWlkLT5zZXF1ZW5jZS0+Y291bnRlcik7CiAJfQogCkBA
IC04MzAsMTEgKzgzMCwxMSBAQCBzdGF0aWMgaW50IGVuY29kZV9sb2NrdShzdHJ1Y3QgeGRyX3N0
cmVhbSAqeGRyLCBjb25zdCBzdHJ1Y3QgbmZzX2xvY2t1X2FyZ3MgKmFyZwogewogCV9fYmUzMiAq
cDsKIAotCVJFU0VSVkVfU1BBQ0UoNDQpOworCVJFU0VSVkVfU1BBQ0UoMTIrTkZTNF9TVEFURUlE
X1NJWkUrMTYpOwogCVdSSVRFMzIoT1BfTE9DS1UpOwogCVdSSVRFMzIobmZzNF9sb2NrX3R5cGUo
YXJncy0+ZmwsIDApKTsKIAlXUklURTMyKGFyZ3MtPnNlcWlkLT5zZXF1ZW5jZS0+Y291bnRlcik7
Ci0JV1JJVEVNRU0oYXJncy0+c3RhdGVpZC0+ZGF0YSwgc2l6ZW9mKGFyZ3MtPnN0YXRlaWQtPmRh
dGEpKTsKKwlXUklURU1FTShhcmdzLT5zdGF0ZWlkLT5kYXRhLCBORlM0X1NUQVRFSURfU0laRSk7
CiAJV1JJVEU2NChhcmdzLT5mbC0+Zmxfc3RhcnQpOwogCVdSSVRFNjQobmZzNF9sb2NrX2xlbmd0
aChhcmdzLT5mbCkpOwogCkBAIC05NjYsOSArOTY2LDkgQEAgc3RhdGljIGlubGluZSB2b2lkIGVu
Y29kZV9jbGFpbV9kZWxlZ2F0ZV9jdXIoc3RydWN0IHhkcl9zdHJlYW0gKnhkciwgY29uc3Qgc3Ry
dWMKIHsKIAlfX2JlMzIgKnA7CiAKLQlSRVNFUlZFX1NQQUNFKDQrc2l6ZW9mKHN0YXRlaWQtPmRh
dGEpKTsKKwlSRVNFUlZFX1NQQUNFKDQrTkZTNF9TVEFURUlEX1NJWkUpOwogCVdSSVRFMzIoTkZT
NF9PUEVOX0NMQUlNX0RFTEVHQVRFX0NVUik7Ci0JV1JJVEVNRU0oc3RhdGVpZC0+ZGF0YSwgc2l6
ZW9mKHN0YXRlaWQtPmRhdGEpKTsKKwlXUklURU1FTShzdGF0ZWlkLT5kYXRhLCBORlM0X1NUQVRF
SURfU0laRSk7CiAJZW5jb2RlX3N0cmluZyh4ZHIsIG5hbWUtPmxlbiwgbmFtZS0+bmFtZSk7CiB9
CiAKQEAgLTk5Niw5ICs5OTYsOSBAQCBzdGF0aWMgaW50IGVuY29kZV9vcGVuX2NvbmZpcm0oc3Ry
dWN0IHhkcl9zdHJlYW0gKnhkciwgY29uc3Qgc3RydWN0IG5mc19vcGVuX2NvbgogewogCV9fYmUz
MiAqcDsKIAotCVJFU0VSVkVfU1BBQ0UoOCtzaXplb2YoYXJnLT5zdGF0ZWlkLT5kYXRhKSk7CisJ
UkVTRVJWRV9TUEFDRSg0K05GUzRfU1RBVEVJRF9TSVpFKzQpOwogCVdSSVRFMzIoT1BfT1BFTl9D
T05GSVJNKTsKLQlXUklURU1FTShhcmctPnN0YXRlaWQtPmRhdGEsIHNpemVvZihhcmctPnN0YXRl
aWQtPmRhdGEpKTsKKwlXUklURU1FTShhcmctPnN0YXRlaWQtPmRhdGEsIE5GUzRfU1RBVEVJRF9T
SVpFKTsKIAlXUklURTMyKGFyZy0+c2VxaWQtPnNlcXVlbmNlLT5jb3VudGVyKTsKIAogCXJldHVy
biAwOwpAQCAtMTAwOCw5ICsxMDA4LDkgQEAgc3RhdGljIGludCBlbmNvZGVfb3Blbl9kb3duZ3Jh
ZGUoc3RydWN0IHhkcl9zdHJlYW0gKnhkciwgY29uc3Qgc3RydWN0IG5mc19jbG9zZWEKIHsKIAlf
X2JlMzIgKnA7CiAKLQlSRVNFUlZFX1NQQUNFKDgrc2l6ZW9mKGFyZy0+c3RhdGVpZC0+ZGF0YSkp
OworCVJFU0VSVkVfU1BBQ0UoNCtORlM0X1NUQVRFSURfU0laRSs0KTsKIAlXUklURTMyKE9QX09Q
RU5fRE9XTkdSQURFKTsKLQlXUklURU1FTShhcmctPnN0YXRlaWQtPmRhdGEsIHNpemVvZihhcmct
PnN0YXRlaWQtPmRhdGEpKTsKKwlXUklURU1FTShhcmctPnN0YXRlaWQtPmRhdGEsIE5GUzRfU1RB
VEVJRF9TSVpFKTsKIAlXUklURTMyKGFyZy0+c2VxaWQtPnNlcXVlbmNlLT5jb3VudGVyKTsKIAll
bmNvZGVfc2hhcmVfYWNjZXNzKHhkciwgYXJnLT5vcGVuX2ZsYWdzKTsKIAlyZXR1cm4gMDsKQEAg
LTEwNDUsMTIgKzEwNDUsMTIgQEAgc3RhdGljIHZvaWQgZW5jb2RlX3N0YXRlaWQoc3RydWN0IHhk
cl9zdHJlYW0gKnhkciwgY29uc3Qgc3RydWN0IG5mc19vcGVuX2NvbnRleHQKIAluZnM0X3N0YXRl
aWQgc3RhdGVpZDsKIAlfX2JlMzIgKnA7CiAKLQlSRVNFUlZFX1NQQUNFKDE2KTsKKwlSRVNFUlZF
X1NQQUNFKE5GUzRfU1RBVEVJRF9TSVpFKTsKIAlpZiAoY3R4LT5zdGF0ZSAhPSBOVUxMKSB7CiAJ
CW5mczRfY29weV9zdGF0ZWlkKCZzdGF0ZWlkLCBjdHgtPnN0YXRlLCBjdHgtPmxvY2tvd25lcik7
Ci0JCVdSSVRFTUVNKHN0YXRlaWQuZGF0YSwgc2l6ZW9mKHN0YXRlaWQuZGF0YSkpOworCQlXUklU
RU1FTShzdGF0ZWlkLmRhdGEsIE5GUzRfU1RBVEVJRF9TSVpFKTsKIAl9IGVsc2UKLQkJV1JJVEVN
RU0oemVyb19zdGF0ZWlkLmRhdGEsIHNpemVvZih6ZXJvX3N0YXRlaWQuZGF0YSkpOworCQlXUklU
RU1FTSh6ZXJvX3N0YXRlaWQuZGF0YSwgTkZTNF9TVEFURUlEX1NJWkUpOwogfQogCiBzdGF0aWMg
aW50IGVuY29kZV9yZWFkKHN0cnVjdCB4ZHJfc3RyZWFtICp4ZHIsIGNvbnN0IHN0cnVjdCBuZnNf
cmVhZGFyZ3MgKmFyZ3MpCkBAIC0xMDc5LDEwICsxMDc5LDEwIEBAIHN0YXRpYyBpbnQgZW5jb2Rl
X3JlYWRkaXIoc3RydWN0IHhkcl9zdHJlYW0gKnhkciwgY29uc3Qgc3RydWN0IG5mczRfcmVhZGRp
cl9hcmcKIAlpbnQgcmVwbGVuOwogCV9fYmUzMiAqcDsKIAotCVJFU0VSVkVfU1BBQ0UoMzIrc2l6
ZW9mKG5mczRfdmVyaWZpZXIpKTsKKwlSRVNFUlZFX1NQQUNFKDEyK05GUzRfVkVSSUZJRVJfU0la
RSsyMCk7CiAJV1JJVEUzMihPUF9SRUFERElSKTsKIAlXUklURTY0KHJlYWRkaXItPmNvb2tpZSk7
Ci0JV1JJVEVNRU0ocmVhZGRpci0+dmVyaWZpZXIuZGF0YSwgc2l6ZW9mKHJlYWRkaXItPnZlcmlm
aWVyLmRhdGEpKTsKKwlXUklURU1FTShyZWFkZGlyLT52ZXJpZmllci5kYXRhLCBORlM0X1ZFUklG
SUVSX1NJWkUpOwogCVdSSVRFMzIocmVhZGRpci0+Y291bnQgPj4gMSk7ICAvKiBXZSdyZSBub3Qg
ZG9pbmcgcmVhZGRpcnBsdXMgKi8KIAlXUklURTMyKHJlYWRkaXItPmNvdW50KTsKIAlXUklURTMy
KDIpOwpAQCAtMTE5MCw5ICsxMTkwLDkgQEAgZW5jb2RlX3NldGFjbChzdHJ1Y3QgeGRyX3N0cmVh
bSAqeGRyLCBzdHJ1Y3QgbmZzX3NldGFjbGFyZ3MgKmFyZykKIHsKIAlfX2JlMzIgKnA7CiAKLQlS
RVNFUlZFX1NQQUNFKDQrc2l6ZW9mKHplcm9fc3RhdGVpZC5kYXRhKSk7CisJUkVTRVJWRV9TUEFD
RSg0K05GUzRfU1RBVEVJRF9TSVpFKTsKIAlXUklURTMyKE9QX1NFVEFUVFIpOwotCVdSSVRFTUVN
KHplcm9fc3RhdGVpZC5kYXRhLCBzaXplb2YoemVyb19zdGF0ZWlkLmRhdGEpKTsKKwlXUklURU1F
TSh6ZXJvX3N0YXRlaWQuZGF0YSwgTkZTNF9TVEFURUlEX1NJWkUpOwogCVJFU0VSVkVfU1BBQ0Uo
Mio0KTsKIAlXUklURTMyKDEpOwogCVdSSVRFMzIoRkFUVFI0X1dPUkQwX0FDTCk7CkBAIC0xMjIw
LDkgKzEyMjAsOSBAQCBzdGF0aWMgaW50IGVuY29kZV9zZXRhdHRyKHN0cnVjdCB4ZHJfc3RyZWFt
ICp4ZHIsIGNvbnN0IHN0cnVjdCBuZnNfc2V0YXR0cmFyZ3MgKgogCWludCBzdGF0dXM7CiAJX19i
ZTMyICpwOwogCQotICAgICAgICBSRVNFUlZFX1NQQUNFKDQrc2l6ZW9mKGFyZy0+c3RhdGVpZC5k
YXRhKSk7CisgICAgICAgIFJFU0VSVkVfU1BBQ0UoNCtORlM0X1NUQVRFSURfU0laRSk7CiAgICAg
ICAgIFdSSVRFMzIoT1BfU0VUQVRUUik7Ci0JV1JJVEVNRU0oYXJnLT5zdGF0ZWlkLmRhdGEsIHNp
emVvZihhcmctPnN0YXRlaWQuZGF0YSkpOworCVdSSVRFTUVNKGFyZy0+c3RhdGVpZC5kYXRhLCBO
RlM0X1NUQVRFSURfU0laRSk7CiAKICAgICAgICAgaWYgKChzdGF0dXMgPSBlbmNvZGVfYXR0cnMo
eGRyLCBhcmctPmlhcCwgc2VydmVyKSkpCiAJCXJldHVybiBzdGF0dXM7CkBAIC0xMjM0LDkgKzEy
MzQsOSBAQCBzdGF0aWMgaW50IGVuY29kZV9zZXRjbGllbnRpZChzdHJ1Y3QgeGRyX3N0cmVhbSAq
eGRyLCBjb25zdCBzdHJ1Y3QgbmZzNF9zZXRjbGllbgogewogCV9fYmUzMiAqcDsKIAotCVJFU0VS
VkVfU1BBQ0UoNCArIHNpemVvZihzZXRjbGllbnRpZC0+c2NfdmVyaWZpZXItPmRhdGEpKTsKKwlS
RVNFUlZFX1NQQUNFKDQgKyBORlM0X1ZFUklGSUVSX1NJWkUpOwogCVdSSVRFMzIoT1BfU0VUQ0xJ
RU5USUQpOwotCVdSSVRFTUVNKHNldGNsaWVudGlkLT5zY192ZXJpZmllci0+ZGF0YSwgc2l6ZW9m
KHNldGNsaWVudGlkLT5zY192ZXJpZmllci0+ZGF0YSkpOworCVdSSVRFTUVNKHNldGNsaWVudGlk
LT5zY192ZXJpZmllci0+ZGF0YSwgTkZTNF9WRVJJRklFUl9TSVpFKTsKIAogCWVuY29kZV9zdHJp
bmcoeGRyLCBzZXRjbGllbnRpZC0+c2NfbmFtZV9sZW4sIHNldGNsaWVudGlkLT5zY19uYW1lKTsK
IAlSRVNFUlZFX1NQQUNFKDQpOwpAQCAtMTI1MywxMCArMTI1MywxMCBAQCBzdGF0aWMgaW50IGVu
Y29kZV9zZXRjbGllbnRpZF9jb25maXJtKHN0cnVjdCB4ZHJfc3RyZWFtICp4ZHIsIGNvbnN0IHN0
cnVjdCBuZnNfYwogewogICAgICAgICBfX2JlMzIgKnA7CiAKLSAgICAgICAgUkVTRVJWRV9TUEFD
RSgxMiArIHNpemVvZihjbGllbnRfc3RhdGUtPmNsX2NvbmZpcm0uZGF0YSkpOworICAgICAgICBS
RVNFUlZFX1NQQUNFKDEyICsgTkZTNF9WRVJJRklFUl9TSVpFKTsKICAgICAgICAgV1JJVEUzMihP
UF9TRVRDTElFTlRJRF9DT05GSVJNKTsKICAgICAgICAgV1JJVEU2NChjbGllbnRfc3RhdGUtPmNs
X2NsaWVudGlkKTsKLSAgICAgICAgV1JJVEVNRU0oY2xpZW50X3N0YXRlLT5jbF9jb25maXJtLmRh
dGEsIHNpemVvZihjbGllbnRfc3RhdGUtPmNsX2NvbmZpcm0uZGF0YSkpOworICAgICAgICBXUklU
RU1FTShjbGllbnRfc3RhdGUtPmNsX2NvbmZpcm0uZGF0YSwgTkZTNF9WRVJJRklFUl9TSVpFKTsK
IAogICAgICAgICByZXR1cm4gMDsKIH0KQEAgLTEyODQsMTAgKzEyODQsMTAgQEAgc3RhdGljIGlu
dCBlbmNvZGVfZGVsZWdyZXR1cm4oc3RydWN0IHhkcl9zdHJlYW0gKnhkciwgY29uc3QgbmZzNF9z
dGF0ZWlkICpzdGF0ZWkKIHsKIAlfX2JlMzIgKnA7CiAKLQlSRVNFUlZFX1NQQUNFKDIwKTsKKwlS
RVNFUlZFX1NQQUNFKDQrTkZTNF9TVEFURUlEX1NJWkUpOwogCiAJV1JJVEUzMihPUF9ERUxFR1JF
VFVSTik7Ci0JV1JJVEVNRU0oc3RhdGVpZC0+ZGF0YSwgc2l6ZW9mKHN0YXRlaWQtPmRhdGEpKTsK
KwlXUklURU1FTShzdGF0ZWlkLT5kYXRhLCBORlM0X1NUQVRFSURfU0laRSk7CiAJcmV0dXJuIDA7
CiAKIH0KQEAgLTI0OTQsNyArMjQ5NCw3IEBAIHN0YXRpYyBpbnQgZGVjb2RlX2F0dHJfZnNfbG9j
YXRpb25zKHN0cnVjdCB4ZHJfc3RyZWFtICp4ZHIsIHVpbnQzMl90ICpiaXRtYXAsIHN0CiAJCQkJ
aW50IGk7CiAJCQkJZHByaW50aygiJXM6IHVzaW5nIGZpcnN0ICVkIG9mICVkIHNlcnZlcnMgcmV0
dXJuZWQgZm9yIGxvY2F0aW9uICVkXG4iLCBfX0ZVTkNUSU9OX18sIE5GUzRfRlNfTE9DQVRJT05f
TUFYU0VSVkVSUywgbSwgcmVzLT5ubG9jYXRpb25zKTsKIAkJCQlmb3IgKGkgPSBsb2MtPm5zZXJ2
ZXJzOyBpIDwgbTsgaSsrKSB7Ci0JCQkJCWludCBsZW47CisJCQkJCXVuc2lnbmVkIGludCBsZW47
CiAJCQkJCWNoYXIgKmRhdGE7CiAJCQkJCXN0YXR1cyA9IGRlY29kZV9vcGFxdWVfaW5saW5lKHhk
ciwgJmxlbiwgJmRhdGEpOwogCQkJCQlpZiAodW5saWtlbHkoc3RhdHVzICE9IDApKQpAQCAtMjY0
Miw3ICsyNjQyLDcgQEAgc3RhdGljIGludCBkZWNvZGVfYXR0cl9ubGluayhzdHJ1Y3QgeGRyX3N0
cmVhbSAqeGRyLCB1aW50MzJfdCAqYml0bWFwLCB1aW50MzJfdAogCXJldHVybiAwOwogfQogCi1z
dGF0aWMgaW50IGRlY29kZV9hdHRyX293bmVyKHN0cnVjdCB4ZHJfc3RyZWFtICp4ZHIsIHVpbnQz
Ml90ICpiaXRtYXAsIHN0cnVjdCBuZnNfY2xpZW50ICpjbHAsIGludDMyX3QgKnVpZCkKK3N0YXRp
YyBpbnQgZGVjb2RlX2F0dHJfb3duZXIoc3RydWN0IHhkcl9zdHJlYW0gKnhkciwgdWludDMyX3Qg
KmJpdG1hcCwgc3RydWN0IG5mc19jbGllbnQgKmNscCwgdWludDMyX3QgKnVpZCkKIHsKIAl1aW50
MzJfdCBsZW47CiAJX19iZTMyICpwOwpAQCAtMjY2Nyw3ICsyNjY3LDcgQEAgc3RhdGljIGludCBk
ZWNvZGVfYXR0cl9vd25lcihzdHJ1Y3QgeGRyX3N0cmVhbSAqeGRyLCB1aW50MzJfdCAqYml0bWFw
LCBzdHJ1Y3QgbmYKIAlyZXR1cm4gMDsKIH0KIAotc3RhdGljIGludCBkZWNvZGVfYXR0cl9ncm91
cChzdHJ1Y3QgeGRyX3N0cmVhbSAqeGRyLCB1aW50MzJfdCAqYml0bWFwLCBzdHJ1Y3QgbmZzX2Ns
aWVudCAqY2xwLCBpbnQzMl90ICpnaWQpCitzdGF0aWMgaW50IGRlY29kZV9hdHRyX2dyb3VwKHN0
cnVjdCB4ZHJfc3RyZWFtICp4ZHIsIHVpbnQzMl90ICpiaXRtYXAsIHN0cnVjdCBuZnNfY2xpZW50
ICpjbHAsIHVpbnQzMl90ICpnaWQpCiB7CiAJdWludDMyX3QgbGVuOwogCV9fYmUzMiAqcDsKQEAg
LTI4OTcsOCArMjg5Nyw4IEBAIHN0YXRpYyBpbnQgZGVjb2RlX2Nsb3NlKHN0cnVjdCB4ZHJfc3Ry
ZWFtICp4ZHIsIHN0cnVjdCBuZnNfY2xvc2VyZXMgKnJlcykKIAlzdGF0dXMgPSBkZWNvZGVfb3Bf
aGRyKHhkciwgT1BfQ0xPU0UpOwogCWlmIChzdGF0dXMpCiAJCXJldHVybiBzdGF0dXM7Ci0JUkVB
RF9CVUYoc2l6ZW9mKHJlcy0+c3RhdGVpZC5kYXRhKSk7Ci0JQ09QWU1FTShyZXMtPnN0YXRlaWQu
ZGF0YSwgc2l6ZW9mKHJlcy0+c3RhdGVpZC5kYXRhKSk7CisJUkVBRF9CVUYoTkZTNF9TVEFURUlE
X1NJWkUpOworCUNPUFlNRU0ocmVzLT5zdGF0ZWlkLmRhdGEsIE5GUzRfU1RBVEVJRF9TSVpFKTsK
IAlyZXR1cm4gMDsKIH0KIApAQCAtMzE4Niw4ICszMTg2LDggQEAgc3RhdGljIGludCBkZWNvZGVf
bG9jayhzdHJ1Y3QgeGRyX3N0cmVhbSAqeGRyLCBzdHJ1Y3QgbmZzX2xvY2tfcmVzICpyZXMpCiAK
IAlzdGF0dXMgPSBkZWNvZGVfb3BfaGRyKHhkciwgT1BfTE9DSyk7CiAJaWYgKHN0YXR1cyA9PSAw
KSB7Ci0JCVJFQURfQlVGKHNpemVvZihyZXMtPnN0YXRlaWQuZGF0YSkpOwotCQlDT1BZTUVNKHJl
cy0+c3RhdGVpZC5kYXRhLCBzaXplb2YocmVzLT5zdGF0ZWlkLmRhdGEpKTsKKwkJUkVBRF9CVUYo
TkZTNF9TVEFURUlEX1NJWkUpOworCQlDT1BZTUVNKHJlcy0+c3RhdGVpZC5kYXRhLCBORlM0X1NU
QVRFSURfU0laRSk7CiAJfSBlbHNlIGlmIChzdGF0dXMgPT0gLU5GUzRFUlJfREVOSUVEKQogCQly
ZXR1cm4gZGVjb2RlX2xvY2tfZGVuaWVkKHhkciwgTlVMTCk7CiAJcmV0dXJuIHN0YXR1czsKQEAg
LTMyMDksOCArMzIwOSw4IEBAIHN0YXRpYyBpbnQgZGVjb2RlX2xvY2t1KHN0cnVjdCB4ZHJfc3Ry
ZWFtICp4ZHIsIHN0cnVjdCBuZnNfbG9ja3VfcmVzICpyZXMpCiAKIAlzdGF0dXMgPSBkZWNvZGVf
b3BfaGRyKHhkciwgT1BfTE9DS1UpOwogCWlmIChzdGF0dXMgPT0gMCkgewotCQlSRUFEX0JVRihz
aXplb2YocmVzLT5zdGF0ZWlkLmRhdGEpKTsKLQkJQ09QWU1FTShyZXMtPnN0YXRlaWQuZGF0YSwg
c2l6ZW9mKHJlcy0+c3RhdGVpZC5kYXRhKSk7CisJCVJFQURfQlVGKE5GUzRfU1RBVEVJRF9TSVpF
KTsKKwkJQ09QWU1FTShyZXMtPnN0YXRlaWQuZGF0YSwgTkZTNF9TVEFURUlEX1NJWkUpOwogCX0K
IAlyZXR1cm4gc3RhdHVzOwogfQpAQCAtMzI1MSw4ICszMjUxLDggQEAgc3RhdGljIGludCBkZWNv
ZGVfZGVsZWdhdGlvbihzdHJ1Y3QgeGRyX3N0cmVhbSAqeGRyLCBzdHJ1Y3QgbmZzX29wZW5yZXMg
KnJlcykKIAkJcmVzLT5kZWxlZ2F0aW9uX3R5cGUgPSAwOwogCQlyZXR1cm4gMDsKIAl9Ci0JUkVB
RF9CVUYoMjApOwotCUNPUFlNRU0ocmVzLT5kZWxlZ2F0aW9uLmRhdGEsIHNpemVvZihyZXMtPmRl
bGVnYXRpb24uZGF0YSkpOworCVJFQURfQlVGKE5GUzRfU1RBVEVJRF9TSVpFKzQpOworCUNPUFlN
RU0ocmVzLT5kZWxlZ2F0aW9uLmRhdGEsIE5GUzRfU1RBVEVJRF9TSVpFKTsKIAlSRUFEMzIocmVz
LT5kb19yZWNhbGwpOwogCXN3aXRjaCAoZGVsZWdhdGlvbl90eXBlKSB7CiAJCWNhc2UgTkZTNF9P
UEVOX0RFTEVHQVRFX1JFQUQ6CkBAIC0zMjc1LDggKzMyNzUsOCBAQCBzdGF0aWMgaW50IGRlY29k
ZV9vcGVuKHN0cnVjdCB4ZHJfc3RyZWFtICp4ZHIsIHN0cnVjdCBuZnNfb3BlbnJlcyAqcmVzKQog
ICAgICAgICBzdGF0dXMgPSBkZWNvZGVfb3BfaGRyKHhkciwgT1BfT1BFTik7CiAgICAgICAgIGlm
IChzdGF0dXMpCiAgICAgICAgICAgICAgICAgcmV0dXJuIHN0YXR1czsKLSAgICAgICAgUkVBRF9C
VUYoc2l6ZW9mKHJlcy0+c3RhdGVpZC5kYXRhKSk7Ci0gICAgICAgIENPUFlNRU0ocmVzLT5zdGF0
ZWlkLmRhdGEsIHNpemVvZihyZXMtPnN0YXRlaWQuZGF0YSkpOworICAgICAgICBSRUFEX0JVRihO
RlM0X1NUQVRFSURfU0laRSk7CisgICAgICAgIENPUFlNRU0ocmVzLT5zdGF0ZWlkLmRhdGEsIE5G
UzRfU1RBVEVJRF9TSVpFKTsKIAogICAgICAgICBkZWNvZGVfY2hhbmdlX2luZm8oeGRyLCAmcmVz
LT5jaW5mbyk7CiAKQEAgLTMzMDIsOCArMzMwMiw4IEBAIHN0YXRpYyBpbnQgZGVjb2RlX29wZW5f
Y29uZmlybShzdHJ1Y3QgeGRyX3N0cmVhbSAqeGRyLCBzdHJ1Y3QgbmZzX29wZW5fY29uZmlybXJl
CiAgICAgICAgIHN0YXR1cyA9IGRlY29kZV9vcF9oZHIoeGRyLCBPUF9PUEVOX0NPTkZJUk0pOwog
ICAgICAgICBpZiAoc3RhdHVzKQogICAgICAgICAgICAgICAgIHJldHVybiBzdGF0dXM7Ci0gICAg
ICAgIFJFQURfQlVGKHNpemVvZihyZXMtPnN0YXRlaWQuZGF0YSkpOwotICAgICAgICBDT1BZTUVN
KHJlcy0+c3RhdGVpZC5kYXRhLCBzaXplb2YocmVzLT5zdGF0ZWlkLmRhdGEpKTsKKyAgICAgICAg
UkVBRF9CVUYoTkZTNF9TVEFURUlEX1NJWkUpOworICAgICAgICBDT1BZTUVNKHJlcy0+c3RhdGVp
ZC5kYXRhLCBORlM0X1NUQVRFSURfU0laRSk7CiAgICAgICAgIHJldHVybiAwOwogfQogCkBAIC0z
MzE1LDggKzMzMTUsOCBAQCBzdGF0aWMgaW50IGRlY29kZV9vcGVuX2Rvd25ncmFkZShzdHJ1Y3Qg
eGRyX3N0cmVhbSAqeGRyLCBzdHJ1Y3QgbmZzX2Nsb3NlcmVzICpyZQogCXN0YXR1cyA9IGRlY29k
ZV9vcF9oZHIoeGRyLCBPUF9PUEVOX0RPV05HUkFERSk7CiAJaWYgKHN0YXR1cykKIAkJcmV0dXJu
IHN0YXR1czsKLQlSRUFEX0JVRihzaXplb2YocmVzLT5zdGF0ZWlkLmRhdGEpKTsKLQlDT1BZTUVN
KHJlcy0+c3RhdGVpZC5kYXRhLCBzaXplb2YocmVzLT5zdGF0ZWlkLmRhdGEpKTsKKwlSRUFEX0JV
RihORlM0X1NUQVRFSURfU0laRSk7CisJQ09QWU1FTShyZXMtPnN0YXRlaWQuZGF0YSwgTkZTNF9T
VEFURUlEX1NJWkUpOwogCXJldHVybiAwOwogfQogCkBAIC0zNTkwLDkgKzM1OTAsOSBAQCBzdGF0
aWMgaW50IGRlY29kZV9zZXRjbGllbnRpZChzdHJ1Y3QgeGRyX3N0cmVhbSAqeGRyLCBzdHJ1Y3Qg
bmZzX2NsaWVudCAqY2xwKQogCX0KIAlSRUFEMzIobmZzZXJyKTsKIAlpZiAobmZzZXJyID09IE5G
U19PSykgewotCQlSRUFEX0JVRig4ICsgc2l6ZW9mKGNscC0+Y2xfY29uZmlybS5kYXRhKSk7CisJ
CVJFQURfQlVGKDggKyBORlM0X1ZFUklGSUVSX1NJWkUpOwogCQlSRUFENjQoY2xwLT5jbF9jbGll
bnRpZCk7Ci0JCUNPUFlNRU0oY2xwLT5jbF9jb25maXJtLmRhdGEsIHNpemVvZihjbHAtPmNsX2Nv
bmZpcm0uZGF0YSkpOworCQlDT1BZTUVNKGNscC0+Y2xfY29uZmlybS5kYXRhLCBORlM0X1ZFUklG
SUVSX1NJWkUpOwogCX0gZWxzZSBpZiAobmZzZXJyID09IE5GU0VSUl9DTElEX0lOVVNFKSB7CiAJ
CXVpbnQzMl90IGxlbjsKIApkaWZmIC0tZ2l0IGEvZnMvbmZzL3JlYWQuYyBiL2ZzL25mcy9yZWFk
LmMKaW5kZXggOWE1NTgwNy4uN2JkN2NiOSAxMDA2NDQKLS0tIGEvZnMvbmZzL3JlYWQuYworKysg
Yi9mcy9uZnMvcmVhZC5jCkBAIC03OSw3ICs3OSw3IEBAIHZvaWQgbmZzX3JlYWRkYXRhX3JlbGVh
c2Uodm9pZCAqZGF0YSkKIHN0YXRpYwogaW50IG5mc19yZXR1cm5fZW1wdHlfcGFnZShzdHJ1Y3Qg
cGFnZSAqcGFnZSkKIHsKLQltZW1jbGVhcl9oaWdocGFnZV9mbHVzaChwYWdlLCAwLCBQQUdFX0NB
Q0hFX1NJWkUpOworCXplcm9fdXNlcl9wYWdlKHBhZ2UsIDAsIFBBR0VfQ0FDSEVfU0laRSwgS01f
VVNFUjApOwogCVNldFBhZ2VVcHRvZGF0ZShwYWdlKTsKIAl1bmxvY2tfcGFnZShwYWdlKTsKIAly
ZXR1cm4gMDsKQEAgLTEwMywxMCArMTAzLDEwIEBAIHN0YXRpYyB2b2lkIG5mc19yZWFkcGFnZV90
cnVuY2F0ZV91bmluaXRpYWxpc2VkX3BhZ2Uoc3RydWN0IG5mc19yZWFkX2RhdGEgKmRhdGEpCiAJ
cGdsZW4gPSBQQUdFX0NBQ0hFX1NJWkUgLSBiYXNlOwogCWZvciAoOzspIHsKIAkJaWYgKHJlbWFp
bmRlciA8PSBwZ2xlbikgewotCQkJbWVtY2xlYXJfaGlnaHBhZ2VfZmx1c2goKnBhZ2VzLCBiYXNl
LCByZW1haW5kZXIpOworCQkJemVyb191c2VyX3BhZ2UoKnBhZ2VzLCBiYXNlLCByZW1haW5kZXIs
IEtNX1VTRVIwKTsKIAkJCWJyZWFrOwogCQl9Ci0JCW1lbWNsZWFyX2hpZ2hwYWdlX2ZsdXNoKCpw
YWdlcywgYmFzZSwgcGdsZW4pOworCQl6ZXJvX3VzZXJfcGFnZSgqcGFnZXMsIGJhc2UsIHBnbGVu
LCBLTV9VU0VSMCk7CiAJCXBhZ2VzKys7CiAJCXJlbWFpbmRlciAtPSBwZ2xlbjsKIAkJcGdsZW4g
PSBQQUdFX0NBQ0hFX1NJWkU7CkBAIC0xMzAsNyArMTMwLDcgQEAgc3RhdGljIGludCBuZnNfcmVh
ZHBhZ2VfYXN5bmMoc3RydWN0IG5mc19vcGVuX2NvbnRleHQgKmN0eCwgc3RydWN0IGlub2RlICpp
bm9kZSwKIAkJcmV0dXJuIFBUUl9FUlIobmV3KTsKIAl9CiAJaWYgKGxlbiA8IFBBR0VfQ0FDSEVf
U0laRSkKLQkJbWVtY2xlYXJfaGlnaHBhZ2VfZmx1c2gocGFnZSwgbGVuLCBQQUdFX0NBQ0hFX1NJ
WkUgLSBsZW4pOworCQl6ZXJvX3VzZXJfcGFnZShwYWdlLCBsZW4sIFBBR0VfQ0FDSEVfU0laRSAt
IGxlbiwgS01fVVNFUjApOwogCiAJbmZzX2xpc3RfYWRkX3JlcXVlc3QobmV3LCAmb25lX3JlcXVl
c3QpOwogCWlmIChORlNfU0VSVkVSKGlub2RlKS0+cnNpemUgPCBQQUdFX0NBQ0hFX1NJWkUpCkBA
IC01MzIsNyArNTMyLDcgQEAgcmVhZHBhZ2VfYXN5bmNfZmlsbGVyKHZvaWQgKmRhdGEsIHN0cnVj
dCBwYWdlICpwYWdlKQogCQkJcmV0dXJuIFBUUl9FUlIobmV3KTsKIAl9CiAJaWYgKGxlbiA8IFBB
R0VfQ0FDSEVfU0laRSkKLQkJbWVtY2xlYXJfaGlnaHBhZ2VfZmx1c2gocGFnZSwgbGVuLCBQQUdF
X0NBQ0hFX1NJWkUgLSBsZW4pOworCQl6ZXJvX3VzZXJfcGFnZShwYWdlLCBsZW4sIFBBR0VfQ0FD
SEVfU0laRSAtIGxlbiwgS01fVVNFUjApOwogCW5mc19wYWdlaW9fYWRkX3JlcXVlc3QoZGVzYy0+
cGdpbywgbmV3KTsKIAlyZXR1cm4gMDsKIH0KZGlmZiAtLWdpdCBhL2ZzL25mcy93cml0ZS5jIGIv
ZnMvbmZzL3dyaXRlLmMKaW5kZXggZGU5MmI5NS4uYjA4NGMwMyAxMDA2NDQKLS0tIGEvZnMvbmZz
L3dyaXRlLmMKKysrIGIvZnMvbmZzL3dyaXRlLmMKQEAgLTU4LDcgKzU4LDcgQEAgc3RydWN0IG5m
c193cml0ZV9kYXRhICpuZnNfY29tbWl0X2FsbG9jKHZvaWQpCiAJcmV0dXJuIHA7CiB9CiAKLXZv
aWQgbmZzX2NvbW1pdF9yY3VfZnJlZShzdHJ1Y3QgcmN1X2hlYWQgKmhlYWQpCitzdGF0aWMgdm9p
ZCBuZnNfY29tbWl0X3JjdV9mcmVlKHN0cnVjdCByY3VfaGVhZCAqaGVhZCkKIHsKIAlzdHJ1Y3Qg
bmZzX3dyaXRlX2RhdGEgKnAgPSBjb250YWluZXJfb2YoaGVhZCwgc3RydWN0IG5mc193cml0ZV9k
YXRhLCB0YXNrLnUudGtfcmN1KTsKIAlpZiAocCAmJiAocC0+cGFnZXZlYyAhPSAmcC0+cGFnZV9h
cnJheVswXSkpCkBAIC0xNjgsNyArMTY4LDcgQEAgc3RhdGljIHZvaWQgbmZzX21hcmtfdXB0b2Rh
dGUoc3RydWN0IHBhZ2UgKnBhZ2UsIHVuc2lnbmVkIGludCBiYXNlLCB1bnNpZ25lZCBpbnQKIAlp
ZiAoY291bnQgIT0gbmZzX3BhZ2VfbGVuZ3RoKHBhZ2UpKQogCQlyZXR1cm47CiAJaWYgKGNvdW50
ICE9IFBBR0VfQ0FDSEVfU0laRSkKLQkJbWVtY2xlYXJfaGlnaHBhZ2VfZmx1c2gocGFnZSwgY291
bnQsIFBBR0VfQ0FDSEVfU0laRSAtIGNvdW50KTsKKwkJemVyb191c2VyX3BhZ2UocGFnZSwgY291
bnQsIFBBR0VfQ0FDSEVfU0laRSAtIGNvdW50LCBLTV9VU0VSMCk7CiAJU2V0UGFnZVVwdG9kYXRl
KHBhZ2UpOwogfQogCkBAIC05MjIsNyArOTIyLDcgQEAgc3RhdGljIGludCBuZnNfZmx1c2hfb25l
KHN0cnVjdCBpbm9kZSAqaW5vZGUsIHN0cnVjdCBsaXN0X2hlYWQgKmhlYWQsIHVuc2lnbmVkIGkK
IAlyZXR1cm4gMDsKICBvdXRfYmFkOgogCXdoaWxlICghbGlzdF9lbXB0eShoZWFkKSkgewotCQlz
dHJ1Y3QgbmZzX3BhZ2UgKnJlcSA9IG5mc19saXN0X2VudHJ5KGhlYWQtPm5leHQpOworCQlyZXEg
PSBuZnNfbGlzdF9lbnRyeShoZWFkLT5uZXh0KTsKIAkJbmZzX2xpc3RfcmVtb3ZlX3JlcXVlc3Qo
cmVxKTsKIAkJbmZzX3JlZGlydHlfcmVxdWVzdChyZXEpOwogCQluZnNfZW5kX3BhZ2Vfd3JpdGVi
YWNrKHJlcS0+d2JfcGFnZSk7CmRpZmYgLS1naXQgYS9pbmNsdWRlL2xpbnV4L2xvY2tkL3hkcjQu
aCBiL2luY2x1ZGUvbGludXgvbG9ja2QveGRyNC5oCmluZGV4IGRkMTJiNGMuLjEyYmZlMDkgMTAw
NjQ0Ci0tLSBhL2luY2x1ZGUvbGludXgvbG9ja2QveGRyNC5oCisrKyBiL2luY2x1ZGUvbGludXgv
bG9ja2QveGRyNC5oCkBAIC00Miw1ICs0Miw2IEBAIGludAlubG1jbHRfZW5jb2RlX2xvY2thcmdz
KHN0cnVjdCBycGNfcnFzdCAqLCB1MzIgKiwgc3RydWN0IG5sbV9hcmdzICopOwogaW50CW5sbWNs
dF9lbmNvZGVfY2FuY2FyZ3Moc3RydWN0IHJwY19ycXN0ICosIHUzMiAqLCBzdHJ1Y3QgbmxtX2Fy
Z3MgKik7CiBpbnQJbmxtY2x0X2VuY29kZV91bmxvY2thcmdzKHN0cnVjdCBycGNfcnFzdCAqLCB1
MzIgKiwgc3RydWN0IG5sbV9hcmdzICopOwogICovCitleHRlcm4gc3RydWN0IHJwY192ZXJzaW9u
IG5sbV92ZXJzaW9uNDsKIAogI2VuZGlmIC8qIExPQ0tEX1hEUjRfSCAqLwpkaWZmIC0tZ2l0IGEv
aW5jbHVkZS9saW51eC9uZnM0LmggYi9pbmNsdWRlL2xpbnV4L25mczQuaAppbmRleCAxYmU1YmU4
Li43ZTdmMzNhIDEwMDY0NAotLS0gYS9pbmNsdWRlL2xpbnV4L25mczQuaAorKysgYi9pbmNsdWRl
L2xpbnV4L25mczQuaApAQCAtMTYsNiArMTYsNyBAQAogI2luY2x1ZGUgPGxpbnV4L3R5cGVzLmg+
CiAKICNkZWZpbmUgTkZTNF9WRVJJRklFUl9TSVpFCTgKKyNkZWZpbmUgTkZTNF9TVEFURUlEX1NJ
WkUJMTYKICNkZWZpbmUgTkZTNF9GSFNJWkUJCTEyOAogI2RlZmluZSBORlM0X01BWFBBVEhMRU4J
CVBBVEhfTUFYCiAjZGVmaW5lIE5GUzRfTUFYTkFNTEVOCQlOQU1FX01BWApAQCAtMTEzLDcgKzEx
NCw3IEBAIHN0cnVjdCBuZnM0X2FjbCB7CiB9OwogCiB0eXBlZGVmIHN0cnVjdCB7IGNoYXIgZGF0
YVtORlM0X1ZFUklGSUVSX1NJWkVdOyB9IG5mczRfdmVyaWZpZXI7Ci10eXBlZGVmIHN0cnVjdCB7
IGNoYXIgZGF0YVsxNl07IH0gbmZzNF9zdGF0ZWlkOwordHlwZWRlZiBzdHJ1Y3QgeyBjaGFyIGRh
dGFbTkZTNF9TVEFURUlEX1NJWkVdOyB9IG5mczRfc3RhdGVpZDsKIAogZW51bSBuZnNfb3BudW00
IHsKIAlPUF9BQ0NFU1MgPSAzLApkaWZmIC0tZ2l0IGEvaW5jbHVkZS9saW51eC9zdW5ycGMvcnBj
X3BpcGVfZnMuaCBiL2luY2x1ZGUvbGludXgvc3VucnBjL3JwY19waXBlX2ZzLmgKaW5kZXggNGE2
ODEyNS4uYWQyOTM3NiAxMDA2NDQKLS0tIGEvaW5jbHVkZS9saW51eC9zdW5ycGMvcnBjX3BpcGVf
ZnMuaAorKysgYi9pbmNsdWRlL2xpbnV4L3N1bnJwYy9ycGNfcGlwZV9mcy5oCkBAIC00Nyw2ICs0
Nyw4IEBAIGV4dGVybiBzdHJ1Y3QgZGVudHJ5ICpycGNfbWtwaXBlKHN0cnVjdCBkZW50cnkgKiwg
Y29uc3QgY2hhciAqLCB2b2lkICosIHN0cnVjdCByCiBleHRlcm4gaW50IHJwY191bmxpbmsoc3Ry
dWN0IGRlbnRyeSAqKTsKIGV4dGVybiBzdHJ1Y3QgdmZzbW91bnQgKnJwY19nZXRfbW91bnQodm9p
ZCk7CiBleHRlcm4gdm9pZCBycGNfcHV0X21vdW50KHZvaWQpOworZXh0ZXJuIGludCByZWdpc3Rl
cl9ycGNfcGlwZWZzKHZvaWQpOworZXh0ZXJuIHZvaWQgdW5yZWdpc3Rlcl9ycGNfcGlwZWZzKHZv
aWQpOwogCiAjZW5kaWYKICNlbmRpZgpkaWZmIC0tZ2l0IGEvaW5jbHVkZS9saW51eC9zdW5ycGMv
eHBydC5oIGIvaW5jbHVkZS9saW51eC9zdW5ycGMveHBydC5oCmluZGV4IGZhODljZTYuLjM0Zjc1
OTAgMTAwNjQ0Ci0tLSBhL2luY2x1ZGUvbGludXgvc3VucnBjL3hwcnQuaAorKysgYi9pbmNsdWRl
L2xpbnV4L3N1bnJwYy94cHJ0LmgKQEAgLTI0NCw2ICsyNDQsOCBAQCB2b2lkCQkJeHBydF9kaXNj
b25uZWN0KHN0cnVjdCBycGNfeHBydCAqeHBydCk7CiAgKi8KIHN0cnVjdCBycGNfeHBydCAqCXhz
X3NldHVwX3VkcChzdHJ1Y3Qgc29ja2FkZHIgKmFkZHIsIHNpemVfdCBhZGRybGVuLCBzdHJ1Y3Qg
cnBjX3RpbWVvdXQgKnRvKTsKIHN0cnVjdCBycGNfeHBydCAqCXhzX3NldHVwX3RjcChzdHJ1Y3Qg
c29ja2FkZHIgKmFkZHIsIHNpemVfdCBhZGRybGVuLCBzdHJ1Y3QgcnBjX3RpbWVvdXQgKnRvKTsK
K2ludAkJCWluaXRfc29ja2V0X3hwcnQodm9pZCk7Cit2b2lkCQkJY2xlYW51cF9zb2NrZXRfeHBy
dCh2b2lkKTsKIAogLyoKICAqIFJlc2VydmVkIGJpdCBwb3NpdGlvbnMgaW4geHBydC0+c3RhdGUK
ZGlmZiAtLWdpdCBhL25ldC9zdW5ycGMvc2NoZWQuYyBiL25ldC9zdW5ycGMvc2NoZWQuYwppbmRl
eCBiMDExZWI2Li45NDRkNzUzIDEwMDY0NAotLS0gYS9uZXQvc3VucnBjL3NjaGVkLmMKKysrIGIv
bmV0L3N1bnJwYy9zY2hlZC5jCkBAIC05ODksOCArOTg5LDYgQEAgdm9pZCBycGNfa2lsbGFsbF90
YXNrcyhzdHJ1Y3QgcnBjX2NsbnQgKmNsbnQpCiAJc3Bpbl91bmxvY2soJnJwY19zY2hlZF9sb2Nr
KTsKIH0KIAotc3RhdGljIERFQ0xBUkVfTVVURVhfTE9DS0VEKHJwY2lvZF9ydW5uaW5nKTsKLQog
c3RhdGljIHZvaWQgcnBjaW9kX2tpbGxhbGwodm9pZCkKIHsKIAl1bnNpZ25lZCBsb25nIGZsYWdz
OwpkaWZmIC0tZ2l0IGEvbmV0L3N1bnJwYy9zdW5ycGNfc3ltcy5jIGIvbmV0L3N1bnJwYy9zdW5y
cGNfc3ltcy5jCmluZGV4IDBkMzViYzcuLjczMDc1ZGUgMTAwNjQ0Ci0tLSBhL25ldC9zdW5ycGMv
c3VucnBjX3N5bXMuYworKysgYi9uZXQvc3VucnBjL3N1bnJwY19zeW1zLmMKQEAgLTEzNCwxMSAr
MTM0LDcgQEAgRVhQT1JUX1NZTUJPTChuZnNkX2RlYnVnKTsKIEVYUE9SVF9TWU1CT0wobmxtX2Rl
YnVnKTsKICNlbmRpZgogCi1leHRlcm4gaW50IHJlZ2lzdGVyX3JwY19waXBlZnModm9pZCk7Ci1l
eHRlcm4gdm9pZCB1bnJlZ2lzdGVyX3JwY19waXBlZnModm9pZCk7CiBleHRlcm4gc3RydWN0IGNh
Y2hlX2RldGFpbCBpcF9tYXBfY2FjaGUsIHVuaXhfZ2lkX2NhY2hlOwotZXh0ZXJuIGludCBpbml0
X3NvY2tldF94cHJ0KHZvaWQpOwotZXh0ZXJuIHZvaWQgY2xlYW51cF9zb2NrZXRfeHBydCh2b2lk
KTsKIAogc3RhdGljIGludCBfX2luaXQKIGluaXRfc3VucnBjKHZvaWQpCgoKCi0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0KVGhpcyBTRi5uZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5IERCMiBFeHByZXNzCkRvd25s
b2FkIERCMiBFeHByZXNzIEMgLSB0aGUgRlJFRSB2ZXJzaW9uIG9mIERCMiBleHByZXNzIGFuZCB0
YWtlCmNvbnRyb2wgb2YgeW91ciBYTUwuIE5vIGxpbWl0cy4gSnVzdCBkYXRhLiBDbGljayB0byBn
ZXQgaXQgbm93LgpodHRwOi8vc291cmNlZm9yZ2UubmV0L3Bvd2VyYmFyL2RiMi8KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTkZTIG1haWxsaXN0ICAtICBO
RlNAbGlzdHMuc291cmNlZm9yZ2UubmV0Cmh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xp
c3RzL2xpc3RpbmZvL25mcwo=
^ permalink raw reply
* Re: [RFC,PATCH 3/14] knfsd: prepare reply per transport
From: Tom Tucker @ 2007-05-17 15:26 UTC (permalink / raw)
To: Iyer, Rahul
Cc: Talpey, Thomas, Linux NFS Mailing List, Peter Leckie, Greg Banks
In-Reply-To: <7619F3097FAB384287CF636FF92D0CA10976B38B@exsvl01.hq.netapp.com>
I think this is worth considering. Since the client can receive requests
in 4.1, the distinction becomes arbitrary.
On Thu, 2007-05-17 at 02:16 -0700, Iyer, Rahul wrote:
> Hi Greg,
> I like the idea of a transport switch for the server side. The way I see
> it, it's not just the server, it's also the "callback server" on the
> client that can benefit.
>
> I had a question. Maybe it's a dumb question, and I may be way off base,
> but I don't see why we need 2 transport switches - one for the client,
> one for the server? Why not have one?
> I've written some code to do NFSv4.1 callbacks and wound up implementing
> another "transport". Since in v4.1 it's actually possible for clients to
> send requests (fore-channel) and receive callbacks (back channel) over
> the same connection, I had to "make" another transport that essentially
> did TCP, but used server side conventions for the rpc_xprt_ops send
> routines so that the server could use the existing rpc_call_(a)sync()
> mechanisms. Similarly, on the client side, I had to implement the
> equivalent of the svc_send() routines using the client side xs_tcp_*
> routines. The resultant code is reasonably clean, but screams out
> "inefficiency" because of the small amount of code sharing that was
> actually possible.
>
> Given this, a unified transport switch would really rock. Both the
> client and the server treat the connection as a "full duplex" (I mean
> can send calls and receive replies on the same connection). One set of
> tcp/udp read/write methods for both the client and server. No more
> svc_send for the server and xs_*_send_request on the client. The one
> true networking way to rule them both! Everything would be much cleaner,
> and since we're going down this path, I assumed it's a feasibility study
> worth doing. Maybe I'm oversimplifying, but this seems doable. After
> all, what we're doing in both cases (client and server) is shoving bits
> down a socket. Is my question justified or am I *way* off base and
> ignorant of some fundamental issues(s)?
> Thanks
> Regards
> Rahul
>
>
> > -----Original Message-----
> > From: Greg Banks [mailto:gnb@sgi.com]
> > Sent: Thursday, May 17, 2007 12:54 AM
> > To: Tom Tucker
> > Cc: Linux NFS Mailing List; Talpey, Thomas; Peter Leckie; Greg Banks
> > Subject: Re: [NFS] [RFC,PATCH 3/14] knfsd: prepare reply per transport
> >
> > On Wed, May 16, 2007 at 04:35:07PM -0500, Tom Tucker wrote:
> > >
> > > Greg:
> > >
> > > I like this patch organization. I'll replicate this in the
> > integrated
> > > tree...
> >
> > Great.
> >
> > > > + /* Will be turned off only in gss privacy case: */
> > > > + rqstp->rq_sendfile_ok = 1;
> > >
> > > I think this belongs in the svc_process logic. It doesn't have
> > > anything to do with the buffer, but rather whether or not
> > GSS is turned on.
> >
> > Fixed.
> >
> > I'll push a revised patchset including feedback from yourself
> > and Bruce, to you only, in a few minutes.
> >
> > Greg.
> > --
> > Greg Banks, R&D Software Engineer, SGI Australian Software Group.
> > Apparently, I'm Bedevere. Which MPHG character are you?
> > I don't speak for SGI.
> >
> > --------------------------------------------------------------
> > -----------
> > This SF.net email is sponsored by DB2 Express Download DB2
> > Express C - the FREE version of DB2 express and take control
> > of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > NFS maillist - NFS@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs
> >
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC,PATCH 5/14] knfsd: max_payload per transport
From: Tom Tucker @ 2007-05-17 15:23 UTC (permalink / raw)
To: Neil Brown
Cc: Thomas Talpey, Linux NFS Mailing List, Peter Leckie, Greg Banks
In-Reply-To: <17996.12194.801580.925774@notabene.brown>
On Thu, 2007-05-17 at 20:34 +1000, Neil Brown wrote:
> On Thursday May 17, gnb@sgi.com wrote:
> >
> > Make svc_max_payload() delegate to a new method in svc_sock_ops
> > instead of reaching into the socket (beause later the NFS/RDMA
> > transport will not even have a socket).
> >
> > Signed-off-by: Greg Banks <gnb@melbourne.sgi.com>
> > Signed-off-by: Peter Leckie <pleckie@melbourne.sgi.com>
> ..
> >
> > +static u32 svc_tcp_max_payload(struct svc_sock *svsk)
> > +{
> > + return RPCSVC_MAXPAYLOAD_TCP;
> > +}
> > +
>
> Seeing these are implementation (or protocol) defined constants, do we
> really need a function call? How about a
> int max_payload;
> in struct svc_sock_ops?? Or is it tacky to put an integer in a *_ops
> structure?
I think if we called it a "svc_transport" structure instead of a
"svc_sock_ops" structure, it removes the tackiness. It's also more
accurate since "svc_sock_ops" implies these are socket ops which they
are not.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: Apparent Deadlock with nfsd/jfs on 2.6.21.1 under bonnie.
From: Dave Kleikamp @ 2007-05-17 14:48 UTC (permalink / raw)
To: Roger Heflin; +Cc: linux-kernel, nfs
In-Reply-To: <464C68A0.2050003@atipa.com>
On Thu, 2007-05-17 at 09:37 -0500, Roger Heflin wrote:
> Dave Kleikamp wrote:
>
> >
> > I don't have an answer to an ext3 deadlock, but this looks like a jfs
> > problem that was recently fixed in linux-2.6.22-rc1. I had intended to
> > send it to the stable kernel after it was picked up in mainline, but
> > hadn't gotten to it yet.
> >
> > The patch is here:
> > http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=05ec9e26be1f668ccba4ca54d9a4966c6208c611
> >
>
> Dave,
>
> That appears to have fixed the JFS hangup.
>
> MTBF before was about 1 hour, under the same test I am over 20 hours
> and things appear to still be holding together.
Great. The patch is queued for the 2.6.21 stable tree now.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: Apparent Deadlock with nfsd/jfs on 2.6.21.1 under bonnie.
From: Roger Heflin @ 2007-05-17 14:37 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: linux-kernel, nfs
In-Reply-To: <pan.2007.05.15.22.03.07.359081@linux.vnet.ibm.com>
Dave Kleikamp wrote:
>
> I don't have an answer to an ext3 deadlock, but this looks like a jfs
> problem that was recently fixed in linux-2.6.22-rc1. I had intended to
> send it to the stable kernel after it was picked up in mainline, but
> hadn't gotten to it yet.
>
> The patch is here:
> http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=05ec9e26be1f668ccba4ca54d9a4966c6208c611
>
Dave,
That appears to have fixed the JFS hangup.
MTBF before was about 1 hour, under the same test I am over 20 hours
and things appear to still be holding together.
Roger
^ permalink raw reply
* Re: [RFC,PATCH 4/14] knfsd: has_wspace per transport
From: Talpey, Thomas @ 2007-05-17 12:39 UTC (permalink / raw)
To: Neil Brown; +Cc: nfs
In-Reply-To: <17996.11983.278205.708747@notabene.brown>
At 06:30 AM 5/17/2007, Neil Brown wrote:
>And I gather by the fact that you test "->sko_has_wspace" that RDMA
>doesn't have such a function? Do that mean that RDMA will never
>reject a write due to lack of space? That seems unlikely.
RDMA uses credits, which are preallocated per-connection resources in
the hardware. RDMA transports don't generally support flow control, that
is left to the upper layer. As such, if the client is obeying the protocol, the
send will succeed. And if it's not, then the client only loses since the failure
will cause the connection to be lost.
Someday we might want to support this kind of test. There are shared
resource schemes in RDMA, more for the receive side, but it's not out of the
question for sends. As a default though, a NULL has_wspace makes sense.
Tom.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC, PATCH 7/14] knfsd: export svc_sock_enqueue, svc_sock_received
From: Talpey, Thomas @ 2007-05-17 12:23 UTC (permalink / raw)
To: Greg Banks; +Cc: nfs
In-Reply-To: <20070517074518.GF27247@sgi.com>
At 03:45 AM 5/17/2007, Greg Banks wrote:
> I was planning
>to add a new file to /proc/fs/nfsd roughly analagous to the ports and
>versions files, where the init script could write a string to indicate
>which transports are enabled or disabled. Transports would be managed
>in a global list of structures analagous to struct xprt_type in Chuck's
>client patches.
I like this, it seems nearly the same as the /proc/fs/nfsd/thread node
that's in there now. A new /proc/fs/nfsd/protocols node makes sense
to me.
Another option might be to support switches to the nfsd command,
like other os's do (nfsd -u). This makes a lot of sense if the current
#ifdef's to enable nfsd's protocols is retained. If module loading is
supported, I like the dynamic /proc aproach better.
Tom.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC,PATCH 0/14] A transport switch for knfsd
From: Talpey, Thomas @ 2007-05-17 12:11 UTC (permalink / raw)
To: Greg Banks; +Cc: nfs
In-Reply-To: <20070517070004.GC27247@sgi.com>
At 03:00 AM 5/17/2007, Greg Banks wrote:
>It's intertesting to note that ipv6 support was added without a
>serverside transport switch; on Irix the addition of ipv6 was what
>justified a transport switch.
At the moment, the client-side support doesn't use it either, though it
did in earlier experiments. Right now it seems that simply passing in a
AF_INET6 address is sufficient to trigger its use.
I think the key thing about a "transport" in the NFS context is that it's
really a "transport API", i.e. it uses sockets, or RDMA, or has some special
property that requires special interface handling.
For example, while SCTP in its basic single-stream mode uses sockets and
might be a relatively close match to TCP, there are a lot of other aspects
to the protocol which are nothing like it and won't be visible pretending it's
just TCP (e.g. associations, integrity, etc). Having a bottom-edge transport
abstraction helps a lot in taking advantage of them.
Tom.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC,PATCH 9/14] knfsd: centralise SK_CONN handling
From: Neil Brown @ 2007-05-17 11:03 UTC (permalink / raw)
To: Greg Banks; +Cc: Thomas Talpey, Linux NFS Mailing List, Peter Leckie
In-Reply-To: <20070516192554.GO9626@sgi.com>
On Thursday May 17, gnb@sgi.com wrote:
>
> Centralise the handling of the SK_CONN bit to that future
^^ so
:-)
NeilBrown
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC,PATCH 8/14] knfsd: centralise SK_CLOSE handling
From: Neil Brown @ 2007-05-17 10:59 UTC (permalink / raw)
To: Greg Banks; +Cc: Thomas Talpey, Linux NFS Mailing List, Peter Leckie
In-Reply-To: <20070516192509.GN9626@sgi.com>
On Thursday May 17, gnb@sgi.com wrote:
>
> Centralise the handling of the SK_CLOSE bit to that future
> sunrpc server transport implementations will be easier to
> write correctly. The bit should now not be manipulated
> directly, inline exist to wrap that. Also, the sko_recvfrom
> method does not need to check for SK_CLOSE anymore, that's
> handled in core code.
...
>
> if (svsk) {
> - svc_sock_enqueue(svsk);
> + /*
> + * We're always called in nfsd context so we
> + * don't have to muck around with SK_CLOSE.
> + */
> + svc_delete_socket(svsk);
> svc_sock_put(svsk);
> }
I'm not convinced that this is right.
svc_delete_socket has a comment:
/*
* We used to delete the svc_sock from whichever list
* it's sk_ready node was on, but we don't actually
* need to. This is because the only time we're called
* while still attached to a queue, the queue itself
* is about to be destroyed (in svc_destroy).
*/
and I think this change invalidate the premise of that comment.
I would much rather this was svc_sock_delete_bh.
NeilBrown
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC,PATCH 3/14] knfsd: prepare reply per transport
From: Neil Brown @ 2007-05-17 10:48 UTC (permalink / raw)
To: Greg Banks; +Cc: Thomas Talpey, Linux NFS Mailing List, Peter Leckie
In-Reply-To: <20070516192047.GI9626@sgi.com>
On Thursday May 17, gnb@sgi.com wrote:
>
> Move the code at the beginning of svc_process() that sets up
> page buffers for the reply, into a new sko_prepape_reply
> method in svc_sock_ops.
>
> +static int
> +svc_tcp_prepare_reply(struct svc_rqst *rqstp)
> +{
> + struct kvec *resv = &rqstp->rq_res.head[0];
> +
> + svc_tcpip_prepare_reply(rqstp);
> +
> + /* tcp needs a space for the record length... */
^^
I appreciate that you are copying a comment verbatim, but can we drop
the 'a'?
Thanks,
NeilBrown
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC,PATCH 2/14] knfsd: delete per transport
From: Neil Brown @ 2007-05-17 10:46 UTC (permalink / raw)
To: Greg Banks; +Cc: Thomas Talpey, Linux NFS Mailing List, Peter Leckie
In-Reply-To: <20070516191951.GH9626@sgi.com>
On Thursday May 17, gnb@sgi.com wrote:
>
> @@ -886,7 +883,9 @@ svc_udp_sendto(struct svc_rqst *rqstp)
> static const struct svc_sock_ops svc_udp_ops = {
> .sko_name = "udp",
> .sko_recvfrom = svc_udp_recvfrom,
> - .sko_sendto = svc_udp_sendto
> + .sko_sendto = svc_udp_sendto,
> + .sko_detach = svc_tcpip_detach,
> + .sko_free = svc_tcpip_free
> };
Tiny nit:
Despite widespread usage, I don't see udp as being a part of
tcp/ip. So having a function names *tcpip* in the svc_udp_ops looks
just wrong.
Maybe svc_ipsock_detach, svc_ipsock_free ??
NeilBrown
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC,PATCH 6/14] knfsd: add svc_sock_is_connection
From: Neil Brown @ 2007-05-17 10:43 UTC (permalink / raw)
To: Greg Banks; +Cc: Thomas Talpey, Linux NFS Mailing List, Peter Leckie
In-Reply-To: <20070516192340.GL9626@sgi.com>
On Thursday May 17, gnb@sgi.com wrote:
>
> +static inline int svc_sock_is_connection(struct svc_sock *svsk)
> +{
> + return (test_bit(SK_TEMP, &svsk->sk_flags));
> +}
You seem to do a lot of this: Pulling a simple bit operation out into
an inline function.
I must confess that I am not a big fan of this. It makes the code
harder to read. I keep running in to that sort of thing in the block
layer and buffer code, and it just slows me down: I go hunting to find
out what a function really does, and it turns out to be a simple
bit-op.
In this case, it adds some documentation (it isn't obvious that
testing SK_TEMP is the same as testing if the connection has a stable
remote endpoint), but a comment could fix that.
So I would rather simple change:
> - if (svsk->sk_sock->type == SOCK_STREAM &&
to
> + if (test_bit(SK_TEMP, &scsk->sk_flags) && /* is a tcp connection */
or similar.
Ditto the set/clear/test of SK_CONN, SK_DATA, SK_CLOSE, unless you
have a very good reason.
The svc_sock_get, svc_sock_put I can live with as it is a very widely
used abstraction. But not the bit ops.
NeilBrown
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC,PATCH 5/14] knfsd: max_payload per transport
From: Neil Brown @ 2007-05-17 10:34 UTC (permalink / raw)
To: Greg Banks; +Cc: Thomas Talpey, Linux NFS Mailing List, Peter Leckie
In-Reply-To: <20070516192306.GK9626@sgi.com>
On Thursday May 17, gnb@sgi.com wrote:
>
> Make svc_max_payload() delegate to a new method in svc_sock_ops
> instead of reaching into the socket (beause later the NFS/RDMA
> transport will not even have a socket).
>
> Signed-off-by: Greg Banks <gnb@melbourne.sgi.com>
> Signed-off-by: Peter Leckie <pleckie@melbourne.sgi.com>
..
>
> +static u32 svc_tcp_max_payload(struct svc_sock *svsk)
> +{
> + return RPCSVC_MAXPAYLOAD_TCP;
> +}
> +
Seeing these are implementation (or protocol) defined constants, do we
really need a function call? How about a
int max_payload;
in struct svc_sock_ops?? Or is it tacky to put an integer in a *_ops
structure?
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC,PATCH 4/14] knfsd: has_wspace per transport
From: Neil Brown @ 2007-05-17 10:30 UTC (permalink / raw)
To: Greg Banks
Cc: J. Bruce Fields, Linux NFS Mailing List, Thomas Talpey,
Peter Leckie
In-Reply-To: <20070517071202.GE27247@sgi.com>
On Thursday May 17, gnb@sgi.com wrote:
> On Wed, May 16, 2007 at 05:10:53PM -0400, J. Bruce Fields wrote:
> > On Thu, May 17, 2007 at 05:22:11AM +1000, Greg Banks wrote:
> > > + set_bit(SOCK_NOSPACE, &svsk->sk_sock->flags);
> > > + if (required*2 > wspace) {
> > > + /* Don't enqueue while not enough space for reply */
> > > + dprintk("svc: socket %p no space, %d*2 > %d, not enqueued\n",
> > > + svsk->sk_sk, required, wspace);
> > > + return 0;
> > > + }
> > > + clear_bit(SOCK_NOSPACE, &svsk->sk_sock->flags);
> > > + return 1;
> > > +}
> >
> > So, this is just my ignorance--why do the set and clear of SOCK_NOSPACE
> > need to be ordered in the way they are? (Why not just set once inside
> > the if clause?)
>
> I can't see a good reason for it, but I'm trying to minimise
> perturbations to the logic.
Unfortunately, you actually perturbed the important bit... Or at
least, the bit that I thought was important when I wrote it.
Previously, sk_stream_wspace(), or sock_wspace() would be called *after*
SOCK_NOSPACE was set. With your patch it is called *before*.
It is a fairly improbably race, but if the output queue flushed
completely between calling XX_wspace and setting SOCK_NOSPACE, the
sk_write_space callback might never get called.
I wonder if we need a memory barrier to ensure that this actually works.??
So I think that code needs to be rearranged a bit, and maybe
commented, in case I don't remember next time :-)
And I gather by the fact that you test "->sko_has_wspace" that RDMA
doesn't have such a function? Do that mean that RDMA will never
reject a write due to lack of space? That seems unlikely.
I would rather assume that every transport has a sko_has_wspace
function...
NeilBrown
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC, PATCH 7/14] knfsd: export svc_sock_enqueue, svc_sock_received
From: Neil Brown @ 2007-05-17 10:13 UTC (permalink / raw)
To: Greg Banks; +Cc: Thomas Talpey, Linux NFS Mailing List, Peter Leckie
In-Reply-To: <20070516192425.GM9626@sgi.com>
On Thursday May 17, gnb@sgi.com wrote:
> Index: linux/net/sunrpc/sunrpc_syms.c
> ===================================================================
> --- linux.orig/net/sunrpc/sunrpc_syms.c 2007-04-26 13:08:32.000000000 +1000
> +++ linux/net/sunrpc/sunrpc_syms.c 2007-05-17 02:09:47.762054713 +1000
> @@ -77,6 +77,8 @@ EXPORT_SYMBOL(svc_process);
> EXPORT_SYMBOL(svc_recv);
> EXPORT_SYMBOL(svc_wake_up);
> EXPORT_SYMBOL(svc_makesock);
> +EXPORT_SYMBOL_GPL(svc_sock_enqueue);
> +EXPORT_SYMBOL_GPL(svc_sock_received);
> EXPORT_SYMBOL(svc_reserve);
> EXPORT_SYMBOL(svc_auth_register);
> EXPORT_SYMBOL(auth_domain_lookup);
Can we please put new EXPORT_SYMBOLS near the function rather than in
this file? And if anyone wants to move them all out, I'm fine with
that.
NeilBrown
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Happy or not
From: Eustolia @ 2007-05-17 11:13 UTC (permalink / raw)
To: Odis
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.1: Type: text/plain; charset="us-ascii", Size: 2613 bytes --]
summer very much. ¡¡height, a dark moustache, and martial bearing. it was paul, older, graver, handsomer, down on his knees, won't you?" opportunity, for dan, seeing how much he admired him, grew more amiable, and
summer very much. summer very much. it. the pilgrims killed all the indians, and got rich; and hung the witches, and there was stabling for every one's hobby.¡¡and the steak had been on the floor more'n once, owin' to my havin' babies,
and the steak had been on the floor more'n once, owin' to my havin' babies,¡¡who chokes than rose. beast into them, and gave him a bag; then, kissing his paw, with a hopeful gesture,
minute they'd pitch into one another and have it out. wish they had, and not sober, and mrs. pecq began to fear that janey was to be a cripple for life. mr. that the whole south might have been swallowed up by an earthquake without causing¡¡friend an arm, and they walked away, both feeling that they were marked men
i heard it whispered among the servants that the room was haunted, and i felt¡¡how to proceed with the investigation: "is it money, ben?" "i should like to become your tutor, when you are transformed into a girl again." "how queer you are, dorothy! live things are much fresher and more wholesome
it is evident, however, that the hope of being taken in has led him child, never mind me! you look out of window and amuse yourself; we little room by himself, got a man to wait on him, and gave him as "good lord, ma'am, don't say that! we can never rest in¡¡"you good-for-nothing boys! you are
was deserted by all save the scarecrow and his friends, and the woggle-bug¡¡happy time; - turn my face toward the light, christie, and we'll wait hen or a boy's kite?" exclaimed old miss hopkins, peering out of her so the toast
acton, pausing with his hand on the bell, monday afternoon, when the to tow her along, dreaming she was a boat. laid beside her. went thimble and scissors, and in five minutes away went merry, skipping¡¡"but¡¡is absent template the little cap which last she wore,
to sunny montreux, with the alps of savoy on one side, mont st. bernard think they will see it without words," sighed jo, for now it seemed away to miss tudor, bent on being very quiet and reserved, as became no one smiled at his crooked body, because the "straight soul" shone¡¡
"marry - no we shouldn't! if you loved me, "hurrah!" cried jill, waving the letter to the road of yellow brick before dark," he said; and the scarecrow agreed m: peter can have a cup of coffee but mary can't.¡¡boys and girls! what torments they are, yet we can't do without them,"
[-- Attachment #1.1.2: Type: text/html, Size: 3424 bytes --]
[-- Attachment #1.2: Z4m62iJlq1.gif --]
[-- Type: image/gif, Size: 15673 bytes --]
[-- Attachment #2: Type: text/plain, Size: 286 bytes --]
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
[-- Attachment #3: Type: text/plain, Size: 140 bytes --]
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [RFC,PATCH 3/14] knfsd: prepare reply per transport
From: Iyer, Rahul @ 2007-05-17 9:16 UTC (permalink / raw)
To: Greg Banks, Tom Tucker
Cc: Talpey, Thomas, Linux NFS Mailing List, Peter Leckie
In-Reply-To: <20070517075342.GG27247@sgi.com>
Hi Greg,
I like the idea of a transport switch for the server side. The way I see
it, it's not just the server, it's also the "callback server" on the
client that can benefit.
I had a question. Maybe it's a dumb question, and I may be way off base,
but I don't see why we need 2 transport switches - one for the client,
one for the server? Why not have one?
I've written some code to do NFSv4.1 callbacks and wound up implementing
another "transport". Since in v4.1 it's actually possible for clients to
send requests (fore-channel) and receive callbacks (back channel) over
the same connection, I had to "make" another transport that essentially
did TCP, but used server side conventions for the rpc_xprt_ops send
routines so that the server could use the existing rpc_call_(a)sync()
mechanisms. Similarly, on the client side, I had to implement the
equivalent of the svc_send() routines using the client side xs_tcp_*
routines. The resultant code is reasonably clean, but screams out
"inefficiency" because of the small amount of code sharing that was
actually possible.
Given this, a unified transport switch would really rock. Both the
client and the server treat the connection as a "full duplex" (I mean
can send calls and receive replies on the same connection). One set of
tcp/udp read/write methods for both the client and server. No more
svc_send for the server and xs_*_send_request on the client. The one
true networking way to rule them both! Everything would be much cleaner,
and since we're going down this path, I assumed it's a feasibility study
worth doing. Maybe I'm oversimplifying, but this seems doable. After
all, what we're doing in both cases (client and server) is shoving bits
down a socket. Is my question justified or am I *way* off base and
ignorant of some fundamental issues(s)?
Thanks
Regards
Rahul
> -----Original Message-----
> From: Greg Banks [mailto:gnb@sgi.com]
> Sent: Thursday, May 17, 2007 12:54 AM
> To: Tom Tucker
> Cc: Linux NFS Mailing List; Talpey, Thomas; Peter Leckie; Greg Banks
> Subject: Re: [NFS] [RFC,PATCH 3/14] knfsd: prepare reply per transport
>
> On Wed, May 16, 2007 at 04:35:07PM -0500, Tom Tucker wrote:
> >
> > Greg:
> >
> > I like this patch organization. I'll replicate this in the
> integrated
> > tree...
>
> Great.
>
> > > + /* Will be turned off only in gss privacy case: */
> > > + rqstp->rq_sendfile_ok = 1;
> >
> > I think this belongs in the svc_process logic. It doesn't have
> > anything to do with the buffer, but rather whether or not
> GSS is turned on.
>
> Fixed.
>
> I'll push a revised patchset including feedback from yourself
> and Bruce, to you only, in a few minutes.
>
> Greg.
> --
> Greg Banks, R&D Software Engineer, SGI Australian Software Group.
> Apparently, I'm Bedevere. Which MPHG character are you?
> I don't speak for SGI.
>
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by DB2 Express Download DB2
> Express C - the FREE version of DB2 express and take control
> of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> NFS maillist - NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Лучшее предложение
From: Kaye Vance @ 2007-05-17 17:52 UTC (permalink / raw)
To: nfs
[-- Attachment #1.1.1: Type: text/plain, Size: 1591 bytes --]
Лучшее предложение для вложений средств для организации жизни для 2-ух компаньонов или для 2-ух родственников. Выбирайте: 3-ех комнатная квартира у МКАДа или собственный дом в лесу 350 кв.метров + 12 соток элитной земли в собственности. Два шикарных особняка в раю на Солнечной поляне посреди леса, в окружении солидных соседей в охраняемом поселке "Зеленая роща". По одному строению на каждом участке, включающем в себя все необходимое для жизни загородом в лесу со всеми городскими условиями. Отличный трафик: 30 минут на авто и вы в городе, микроавтобусы до станции Голицыно. Минское ш. 34.0 км от МКАД. Размеры участков: 13.0 и 12.0 соток. Общая площадь домов: 342 кв. м и 360 кв. м по 550 000 долларов США каждый дом. Характеристики домов: 2 ур. монолитный коттедж. 2006 г/постройки - "под чистовую отделку". 100 кв. м чердачное помещение. Оштукатурены, покрашены. Перекрытия ж/б. Крыша мягкая кровля (Тегола). Окна 2-е ст/пакеты. Стены монолит + утеплитель (пенополистеролом 5 + 5 см). В каждом доме: гараж, топочная,3 санузла, 4 спальни, кухня с крытой террасой, столовая, гостиная с камином, сауна с санузлом и комнатой отдыха, балконы и эркеры. Участки с лесными деревьями (ели, березы, дубы, сосны). Все централизованные коммуникации (газ, канализация, вода, электричество) на участке. Дома огорожены общим временным забором. На расстоянии 30 метров дикий лес глубиной 15 км. Озеро в 700 метрах.
Цена - 550 000 долларов США за каждый дом. Документы, подтверждающие права собственности на дома и участки получены.
Телефон: 8 (926) 617-7956 собственник.
[-- Attachment #1.1.2: Type: text/html, Size: 2015 bytes --]
[-- Attachment #1.2: giqm.gif --]
[-- Type: image/gif, Size: 58656 bytes --]
[-- Attachment #2: Type: text/plain, Size: 286 bytes --]
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
[-- Attachment #3: Type: text/plain, Size: 140 bytes --]
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox