linux-stable.git/net, branch v4.18.7

NFSv4 client live hangs after live data migration recovery

2018-09-09T08:32:38+00:00

commit 0f90be132cbf1537d87a6a8b9e80867adac892f6 upstream.

After a live data migration event at the NFS server, the client may send
I/O requests to the wrong server, causing a live hang due to repeated
recovery events.  On the wire, this will appear as an I/O request failing
with NFS4ERR_BADSESSION, followed by successful CREATE_SESSION, repeatedly.
NFS4ERR_BADSSESSION is returned because the session ID being used was
issued by the other server and is not valid at the old server.

The failure is caused by async worker threads having cached the transport
(xprt) in the rpc_task structure.  After the migration recovery completes,
the task is redispatched and the task resends the request to the wrong
server based on the old value still present in tk_xprt.

The solution is to recompute the tk_xprt field of the rpc_task structure
so that the request goes to the correct server.

Signed-off-by: Bill Baker 
Reviewed-by: Chuck Lever 
Tested-by: Helen Chao 
Fixes: fb43d17210ba ("SUNRPC: Use the multipath iterator to assign a ...")
Cc: stable@vger.kernel.org # v4.9+
Signed-off-by: Anna Schumaker 
Signed-off-by: Greg Kroah-Hartman

net/9p/trans_fd.c: fix race-condition by flushing workqueue before the kfree()

2018-09-09T08:32:33+00:00

commit 430ac66eb4c5b5c4eb846b78ebf65747510b30f1 upstream.

The patch adds the flush in p9_mux_poll_stop() as it the function used by
p9_conn_destroy(), in turn called by p9_fd_close() to stop the async
polling associated with the data regarding the connection.

Link: http://lkml.kernel.org/r/20180720092730.27104-1-tomasbortoli@gmail.com
Signed-off-by: Tomas Bortoli 
Reported-by: syzbot+39749ed7d9ef6dfb23f6@syzkaller.appspotmail.com
To: Eric Van Hensbergen 
To: Ron Minnich 
To: Latchesar Ionkov 
Cc: Yiwen Jiang 
Cc: stable@vger.kernel.org
Signed-off-by: Dominique Martinet 
Signed-off-by: Greg Kroah-Hartman

net/9p/client.c: version pointer uninitialized

2018-09-09T08:32:33+00:00

commit 7913690dcc5e18e235769fd87c34143072f5dbea upstream.

The p9_client_version() does not initialize the version pointer. If the
call to p9pdu_readf() returns an error and version has not been allocated
in p9pdu_readf(), then the program will jump to the "error" label and will
try to free the version pointer. If version is not initialized, free()
will be called with uninitialized, garbage data and will provoke a crash.

Link: http://lkml.kernel.org/r/20180709222943.19503-1-tomasbortoli@gmail.com
Signed-off-by: Tomas Bortoli 
Reported-by: syzbot+65c6b72f284a39d416b4@syzkaller.appspotmail.com
Reviewed-by: Jun Piao 
Reviewed-by: Yiwen Jiang 
Cc: Eric Van Hensbergen 
Cc: Ron Minnich 
Cc: Latchesar Ionkov 
Signed-off-by: Andrew Morton 
Cc: stable@vger.kernel.org
Signed-off-by: Dominique Martinet 
Signed-off-by: Greg Kroah-Hartman

9p/virtio: fix off-by-one error in sg list bounds check

2018-09-09T08:32:33+00:00

commit 23cba9cbde0bba05d772b335fe5f66aa82b9ad19 upstream.

Because the value of limit is VIRTQUEUE_NUM, if index is equal to
limit, it will cause sg array out of bounds, so correct the judgement
of BUG_ON.

Link: http://lkml.kernel.org/r/5B63D5F6.6080109@huawei.com
Signed-off-by: Yiwen Jiang 
Reported-By: Dan Carpenter 
Acked-by: Jun Piao 
Cc: stable@vger.kernel.org
Signed-off-by: Dominique Martinet 
Signed-off-by: Greg Kroah-Hartman

9p: fix multiple NULL-pointer-dereferences

2018-09-09T08:32:33+00:00

commit 10aa14527f458e9867cf3d2cc6b8cb0f6704448b upstream.

Added checks to prevent GPFs from raising.

Link: http://lkml.kernel.org/r/20180727110558.5479-1-tomasbortoli@gmail.com
Signed-off-by: Tomas Bortoli 
Reported-by: syzbot+1a262da37d3bead15c39@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Dominique Martinet 
Signed-off-by: Greg Kroah-Hartman

9p/net: Fix zero-copy path in the 9p virtio transport

2018-09-09T08:32:28+00:00

commit d28c756caee6e414d9ba367d0b92da24145af2a8 upstream.

The zero-copy optimization when reading or writing large chunks of data
is quite useful.  However, the 9p messages created through the zero-copy
write path have an incorrect message size: it should be the size of the
header + size of the data being written but instead it's just the size
of the header.

This only works if the server ignores the size field of the message and
otherwise breaks the framing of the protocol. Fix this by re-writing the
message size field with the correct value.

Tested by running `dd if=/dev/zero of=out bs=4k count=1` inside a
virtio-9p mount.

Link: http://lkml.kernel.org/r/20180717003529.114368-1-chirantan@chromium.org
Signed-off-by: Chirantan Ekbote 
Reviewed-by: Greg Kurz 
Tested-by: Greg Kurz 
Cc: Dylan Reid 
Cc: Guenter Roeck 
Cc: stable@vger.kernel.org
Signed-off-by: Dominique Martinet 
Signed-off-by: Greg Kroah-Hartman

net: mac802154: tx: expand tailroom if necessary

2018-09-09T08:32:27+00:00

commit f9c52831133050c6b82aa8b6831c92da2bbf2a0b upstream.

This patch is necessary if case of AF_PACKET or other socket interface
which I am aware of it and didn't allocated the necessary room.

Reported-by: David Palma 
Reported-by: Rabi Narayan Sahoo 
Cc: stable@vger.kernel.org
Signed-off-by: Alexander Aring 
Signed-off-by: Stefan Schmidt 
Signed-off-by: Greg Kroah-Hartman

net: 6lowpan: fix reserved space for single frames

2018-09-09T08:32:27+00:00

commit ac74f87c789af40936a80131c4759f3e72579c3a upstream.

This patch fixes patch add handling to take care tail and headroom for
single 6lowpan frames. We need to be sure we have a skb with the right
head and tailroom for single frames. This patch do it by using
skb_copy_expand() if head and tailroom is not enough allocated by upper
layer.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195059
Reported-by: David Palma 
Reported-by: Rabi Narayan Sahoo 
Cc: stable@vger.kernel.org
Signed-off-by: Alexander Aring 
Signed-off-by: Stefan Schmidt 
Signed-off-by: Greg Kroah-Hartman

xprtrdma: Fix disconnect regression

2018-09-05T07:29:40+00:00

commit 8d4fb8ff427a23e573c9373b2bb3d1d6e8ea4399 upstream.

I found that injecting disconnects with v4.18-rc resulted in
random failures of the multi-threaded git regression test.

The root cause appears to be that, after a reconnect, the
RPC/RDMA transport is waking pending RPCs before the transport has
posted enough Receive buffers to receive the Replies. If a Reply
arrives before enough Receive buffers are posted, the connection
is dropped. A few connection drops happen in quick succession as
the client and server struggle to regain credit synchronization.

This regression was introduced with commit 7c8d9e7c8863 ("xprtrdma:
Move Receive posting to Receive handler"). The client is supposed to
post a single Receive when a connection is established because
it's not supposed to send more than one RPC Call before it gets
a fresh credit grant in the first RPC Reply [RFC 8166, Section
3.3.3].

Unfortunately there appears to be a longstanding bug in the Linux
client's credit accounting mechanism. On connect, it simply dumps
all pending RPC Calls onto the new connection. It's possible it has
done this ever since the RPC/RDMA transport was added to the kernel
ten years ago.

Servers have so far been tolerant of this bad behavior. Currently no
server implementation ever changes its credit grant over reconnects,
and servers always repost enough Receives before connections are
fully established.

The Linux client implementation used to post a Receive before each
of these Calls. This has covered up the flooding send behavior.

I could try to correct this old bug so that the client sends exactly
one RPC Call and waits for a Reply. Since we are so close to the
next merge window, I'm going to instead provide a simple patch to
post enough Receives before a reconnect completes (based on the
number of credits granted to the previous connection).

The spurious disconnects will be gone, but the client will still
send multiple RPC Calls immediately after a reconnect.

Addressing the latter problem will wait for a merge window because
a) I expect it to be a large change requiring lots of testing, and
b) obviously the Linux client has interoperated successfully since
day zero while still being broken.

Fixes: 7c8d9e7c8863 ("xprtrdma: Move Receive posting to ... ")
Cc: stable@vger.kernel.org # v4.18+
Signed-off-by: Chuck Lever 
Signed-off-by: Anna Schumaker 
Signed-off-by: Greg Kroah-Hartman

cls_matchall: fix tcf_unbind_filter missing

2018-08-22T05:43:44+00:00

[ Upstream commit a51c76b4dfb30496dc65396a957ef0f06af7fb22 ]

Fix tcf_unbind_filter missing in cls_matchall as this will trigger
WARN_ON() in cbq_destroy_class().

Fixes: fd62d9f5c575f ("net/sched: matchall: Fix configuration race")
Reported-by: Li Shuang 
Signed-off-by: Hangbin Liu 
Acked-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman