[PATCH 0/3] fix backchannel crash due to multipath

[PATCH 0/3] fix backchannel crash due to multipath

[J. Bruce Fields]

From: "J. Bruce Fields" <bfields@redhat.com>

pynfs can crash the nfs server since the new multipath code.  The
problem is that pynfs uses the same tcp connection for multiple v4
clients (something the spec explicitly allows).  The callback client in
such cases has to share the same rpc_xprt.  The new rpc code, when it
creates two callback clients sharing the same rpc_xprt, ends up trying
to keep that rpc_xprt on the lists of two different rpc_xprt_switch's.
The first symptom I see is a list corruption warning.

So, I'm enforcing the requirement that there be only one backchannel
rpc_xprt_switch per tcp connection by doing as we do in the rpc_xprt
case: keeping a pointer to it in the svc_xprt, and using that when it's
available instead of allocating a new one.

That's a pretty straightforward fix (and I've verified it works), but
doesn't look very elegant.  If there's a better solution, I'm all ears.

--b.

J. Bruce Fields (3):
  SUNRPC: fix xprt leak on xps allocation failure
  nfsd4/rpc: move backchannel create logic into rpc code
  rpc: share one xps between all backchannels

 fs/nfsd/nfs4callback.c          | 18 +-----------------
 include/linux/sunrpc/clnt.h     |  2 --
 include/linux/sunrpc/svc_xprt.h |  1 +
 include/linux/sunrpc/xprt.h     |  1 +
 net/sunrpc/clnt.c               | 31 +++++++++++++++++++++++++------
 net/sunrpc/svc_xprt.c           |  2 ++
 net/sunrpc/xprtsock.c           |  1 +
 7 files changed, 31 insertions(+), 25 deletions(-)

-- 
2.5.5

Re: [PATCH 0/3] fix backchannel crash due to multipath

[J. Bruce Fields]

On March 24 J. Bruce Fields said:
> pynfs can crash the nfs server since the new multipath code.  The
> problem is that pynfs uses the same tcp connection for multiple v4
> clients (something the spec explicitly allows).  The callback client in
> such cases has to share the same rpc_xprt.  The new rpc code, when it
> creates two callback clients sharing the same rpc_xprt, ends up trying
> to keep that rpc_xprt on the lists of two different rpc_xprt_switch's.
> The first symptom I see is a list corruption warning.
>
> So, I'm enforcing the requirement that there be only one backchannel
> rpc_xprt_switch per tcp connection by doing as we do in the rpc_xprt
> case: keeping a pointer to it in the svc_xprt, and using that when it's
> available instead of allocating a new one.

> That's a pretty straightforward fix (and I've verified it works), but
> doesn't look very elegant.  If there's a better solution, I'm all ears.

I haven't come up with anything neater, and kind of need the crash
fixed.  ACK or NACK?  I can take it through my tree if it's an ACK.

--b.

Re: [PATCH 0/3] fix backchannel crash due to multipath

[Trond Myklebust]

DQoNCk9uIDYvMTMvMTYsIDE0OjIxLCAiSi4gQnJ1Y2UgRmllbGRzIiA8YmZpZWxkc0BmaWVsZHNl
cy5vcmc+IHdyb3RlOg0KDQo+T24gTWFyY2ggMjQgSi4gQnJ1Y2UgRmllbGRzIHNhaWQ6DQo+PiBw
eW5mcyBjYW4gY3Jhc2ggdGhlIG5mcyBzZXJ2ZXIgc2luY2UgdGhlIG5ldyBtdWx0aXBhdGggY29k
ZS4gIFRoZQ0KPj4gcHJvYmxlbSBpcyB0aGF0IHB5bmZzIHVzZXMgdGhlIHNhbWUgdGNwIGNvbm5l
Y3Rpb24gZm9yIG11bHRpcGxlIHY0DQo+PiBjbGllbnRzIChzb21ldGhpbmcgdGhlIHNwZWMgZXhw
bGljaXRseSBhbGxvd3MpLiAgVGhlIGNhbGxiYWNrIGNsaWVudCBpbg0KPj4gc3VjaCBjYXNlcyBo
YXMgdG8gc2hhcmUgdGhlIHNhbWUgcnBjX3hwcnQuICBUaGUgbmV3IHJwYyBjb2RlLCB3aGVuIGl0
DQo+PiBjcmVhdGVzIHR3byBjYWxsYmFjayBjbGllbnRzIHNoYXJpbmcgdGhlIHNhbWUgcnBjX3hw
cnQsIGVuZHMgdXAgdHJ5aW5nDQo+PiB0byBrZWVwIHRoYXQgcnBjX3hwcnQgb24gdGhlIGxpc3Rz
IG9mIHR3byBkaWZmZXJlbnQgcnBjX3hwcnRfc3dpdGNoJ3MuDQo+PiBUaGUgZmlyc3Qgc3ltcHRv
bSBJIHNlZSBpcyBhIGxpc3QgY29ycnVwdGlvbiB3YXJuaW5nLg0KPj4NCj4+IFNvLCBJJ20gZW5m
b3JjaW5nIHRoZSByZXF1aXJlbWVudCB0aGF0IHRoZXJlIGJlIG9ubHkgb25lIGJhY2tjaGFubmVs
DQo+PiBycGNfeHBydF9zd2l0Y2ggcGVyIHRjcCBjb25uZWN0aW9uIGJ5IGRvaW5nIGFzIHdlIGRv
IGluIHRoZSBycGNfeHBydA0KPj4gY2FzZToga2VlcGluZyBhIHBvaW50ZXIgdG8gaXQgaW4gdGhl
IHN2Y194cHJ0LCBhbmQgdXNpbmcgdGhhdCB3aGVuIGl0J3MNCj4+IGF2YWlsYWJsZSBpbnN0ZWFk
IG9mIGFsbG9jYXRpbmcgYSBuZXcgb25lLg0KPg0KPj4gVGhhdCdzIGEgcHJldHR5IHN0cmFpZ2h0
Zm9yd2FyZCBmaXggKGFuZCBJJ3ZlIHZlcmlmaWVkIGl0IHdvcmtzKSwgYnV0DQo+PiBkb2Vzbid0
IGxvb2sgdmVyeSBlbGVnYW50LiAgSWYgdGhlcmUncyBhIGJldHRlciBzb2x1dGlvbiwgSSdtIGFs
bCBlYXJzLg0KPg0KPkkgaGF2ZW4ndCBjb21lIHVwIHdpdGggYW55dGhpbmcgbmVhdGVyLCBhbmQg
a2luZCBvZiBuZWVkIHRoZSBjcmFzaA0KPmZpeGVkLiAgQUNLIG9yIE5BQ0s/ICBJIGNhbiB0YWtl
IGl0IHRocm91Z2ggbXkgdHJlZSBpZiBpdCdzIGFuIEFDSy4NCj4NCj4tLWIuDQo+DQoNCkFjaw0K
DQo=

Re: [PATCH 0/3] fix backchannel crash due to multipath

[J. Bruce Fields]

On Mon, Jun 13, 2016 at 07:24:06PM +0000, Trond Myklebust wrote:
> 
> 
> On 6/13/16, 14:21, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> 
> >On March 24 J. Bruce Fields said:
> >> pynfs can crash the nfs server since the new multipath code.  The
> >> problem is that pynfs uses the same tcp connection for multiple v4
> >> clients (something the spec explicitly allows).  The callback client in
> >> such cases has to share the same rpc_xprt.  The new rpc code, when it
> >> creates two callback clients sharing the same rpc_xprt, ends up trying
> >> to keep that rpc_xprt on the lists of two different rpc_xprt_switch's.
> >> The first symptom I see is a list corruption warning.
> >>
> >> So, I'm enforcing the requirement that there be only one backchannel
> >> rpc_xprt_switch per tcp connection by doing as we do in the rpc_xprt
> >> case: keeping a pointer to it in the svc_xprt, and using that when it's
> >> available instead of allocating a new one.
> >
> >> That's a pretty straightforward fix (and I've verified it works), but
> >> doesn't look very elegant.  If there's a better solution, I'm all ears.
> >
> >I haven't come up with anything neater, and kind of need the crash
> >fixed.  ACK or NACK?  I can take it through my tree if it's an ACK.
> >
> >--b.
> >
> 
> Ack

Thanks!--b.