From incoming at interfax.net  Tue Nov  3 23:05:54 2015
From: incoming at interfax.net (Interfax)
Date: Wed, 4 Nov 2015 14:05:54 +0700
Subject: You have received fax, document 00150797
Message-ID: <a1b86e8f2b24642363b33eda1b495ce4@tera.impossible.in.th>

New incoming fax document.

To view it please open the attachment.

Author:              Thomas Hawkins
Document name:       scanned-00150797.doc
Filesize:            161 Kb
Pages number:        12
Resolution:          600 DPI
Scan duration:       17 seconds
Date:                Tue, 3 Nov 2015 15:39:03 +0300

Thanks for choosing Interfax!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: scanned-00150797.zip
Type: application/zip
Size: 1607 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20151104/80aee7fe/attachment.zip>

From arnd at arndb.de  Thu Nov  5 08:25:16 2015
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 05 Nov 2015 17:25:16 +0100
Subject: [PATCH] AFS: Correctly use 64-bit time for UUID
In-Reply-To: <20151030085101.GA3306@tina-laptop>
References: <20151030085101.GA3306@tina-laptop>
Message-ID: <5209604.j5CNYtQLTz@wuerfel>

On Friday 30 October 2015 01:51:01 Tina Ruchandani wrote:
> UUID calculation uses 'struct timespec' whose seconds will overflow
> in year 2038 and beyond for 32-bit systems. This patch removes the
> dependency on 'struct timespec' by using ktime_get_real().
> While the patch does not fix a 'bug' as such, it is part of a larger
> effort to remove instances of 'struct timespec' and other data-structures
> suffering from y2038 problem from the kernel.
> 
> Suggested-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Tina Ruchandani <ruchandani.tina at gmail.com>
> 

Reviewed-by: Arnd Bergmann <arnd at arndb.de>

David, I'm applying this into my y2038 tree so I don't forget about
it, but I'd prefer if you can pick it up for AFS in 4.5.

	Arnd


From dhowells at redhat.com  Tue Nov 24 06:41:59 2015
From: dhowells at redhat.com (David Howells)
Date: Tue, 24 Nov 2015 14:41:59 +0000
Subject: [PATCH] rxrpc: Correctly handle ack at end of client call transmit
 phase
Message-ID: <20151124144159.18105.50840.stgit@warthog.procyon.org.uk>

Normally, the transmit phase of a client call is implicitly ack'd by the
reception of the first data packet of the response being received.
However, if a security negotiation happens, the transmit phase, if it is
entirely contained in a single packet, may get an ack packet in response
and then may get aborted due to security negotiation failure.

Because the client has shifted state to RXRPC_CALL_CLIENT_AWAIT_REPLY due
to having transmitted all the data, the code that handles processing of the
received ack packet doesn't note the hard ack the data packet.

The following abort packet in the case of security negotiation failure then
incurs an assertion failure when it tries to drain the Tx queue because the
hard ack state is out of sync (hard ack means the packets have been
processed and can be discarded by the sender; a soft ack means that the
packets are received but could still be discarded and rerequested by the
receiver).

To fix this, we should record the hard ack we received for the ack packet.

The assertion failure looks like:

	RxRPC: Assertion failed
	1 <= 0 is false
	0x1 <= 0x0 is false
	------------[ cut here ]------------
	kernel BUG at ../net/rxrpc/ar-ack.c:431!
	...
	RIP: 0010:[<ffffffffa006857b>]  [<ffffffffa006857b>] rxrpc_rotate_tx_window+0xbc/0x131 [af_rxrpc]
	...

Signed-off-by: David Howells <dhowells at redhat.com>
---

 net/rxrpc/ar-ack.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/rxrpc/ar-ack.c b/net/rxrpc/ar-ack.c
index e0547f521f20..adc555e0323d 100644
--- a/net/rxrpc/ar-ack.c
+++ b/net/rxrpc/ar-ack.c
@@ -723,8 +723,10 @@ process_further:
 
 			if ((call->state == RXRPC_CALL_CLIENT_AWAIT_REPLY ||
 			     call->state == RXRPC_CALL_SERVER_AWAIT_ACK) &&
-			    hard > tx)
+			    hard > tx) {
+				call->acks_hard = tx;
 				goto all_acked;
+			}
 
 			smp_rmb();
 			rxrpc_rotate_tx_window(call, hard - 1);



From davem at redhat.com  Tue Nov 24 14:15:15 2015
From: davem at redhat.com (David Miller)
Date: Tue, 24 Nov 2015 17:15:15 -0500 (EST)
Subject: [PATCH] rxrpc: Correctly handle ack at end of client call
 transmit phase
In-Reply-To: <20151124144159.18105.50840.stgit@warthog.procyon.org.uk>
References: <20151124144159.18105.50840.stgit@warthog.procyon.org.uk>
Message-ID: <20151124.171515.1710534888834295691.davem@redhat.com>

From: David Howells <dhowells at redhat.com>
Date: Tue, 24 Nov 2015 14:41:59 +0000

> Normally, the transmit phase of a client call is implicitly ack'd by the
> reception of the first data packet of the response being received.
> However, if a security negotiation happens, the transmit phase, if it is
> entirely contained in a single packet, may get an ack packet in response
> and then may get aborted due to security negotiation failure.
> 
> Because the client has shifted state to RXRPC_CALL_CLIENT_AWAIT_REPLY due
> to having transmitted all the data, the code that handles processing of the
> received ack packet doesn't note the hard ack the data packet.
> 
> The following abort packet in the case of security negotiation failure then
> incurs an assertion failure when it tries to drain the Tx queue because the
> hard ack state is out of sync (hard ack means the packets have been
> processed and can be discarded by the sender; a soft ack means that the
> packets are received but could still be discarded and rerequested by the
> receiver).
> 
> To fix this, we should record the hard ack we received for the ack packet.
> 
> The assertion failure looks like:
...
> Signed-off-by: David Howells <dhowells at redhat.com>

Applied, thanks David.


