From dhowells at redhat.com  Tue May  2 09:35:25 2023
From: dhowells at redhat.com (David Howells)
Date: Tue,  2 May 2023 17:35:25 +0100
Subject: [PATCH 0/3] afs: Fix directory size handling
Message-ID: <20230502163528.1564398-1-dhowells@redhat.com>

Hi Linus,

Could you apply these three fixes to AFS directory handling?

 (1) Make sure that afs_read_dir() sees any increase in file size if the
     file unexpectedly changed on the server (e.g. due to another client
     making a change).

 (2) Make afs_getattr() always return the server's dir file size, not the
     locally edited one, so that pagecache eviction doesn't cause the dir
     file size to change unexpectedly.

 (3) Prevent afs_read_dir() from getting into an endless loop if the server
     indicates that the directory file size is larger than expected.

The patches can be found here:

	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=afs-fixes

Thanks,
David

---
%(shortlog)s
%(diffstat)s

David Howells (1):
  afs: Fix getattr to report server i_size on dirs, not local size

Marc Dionne (2):
  afs: Fix updating of i_size with dv jump from server
  afs: Avoid endless loop if file is larger than expected

 fs/afs/dir.c   |  4 ++++
 fs/afs/inode.c | 10 +++++++++-
 2 files changed, 13 insertions(+), 1 deletion(-)



From dhowells at redhat.com  Tue May  2 09:35:26 2023
From: dhowells at redhat.com (David Howells)
Date: Tue,  2 May 2023 17:35:26 +0100
Subject: [PATCH 1/3] afs: Fix updating of i_size with dv jump from server
In-Reply-To: <20230502163528.1564398-1-dhowells@redhat.com>
References: <20230502163528.1564398-1-dhowells@redhat.com>
Message-ID: <20230502163528.1564398-2-dhowells@redhat.com>

From: Marc Dionne <marc.dionne at auristor.com>

If the data version returned from the server is larger than expected,
the local data is invalidated, but we may still want to note the remote
file size.

Since we're setting change_size, we have to also set data_changed
for the i_size to get updated.

Fixes: 3f4aa9818163 ("afs: Fix EOF corruption")
Signed-off-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: linux-afs at lists.infradead.org
---
 fs/afs/inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index b1bdffd5e888..82edd3351734 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -230,6 +230,7 @@ static void afs_apply_status(struct afs_operation *op,
 			set_bit(AFS_VNODE_ZAP_DATA, &vnode->flags);
 		}
 		change_size = true;
+		data_changed = true;
 	} else if (vnode->status.type == AFS_FTYPE_DIR) {
 		/* Expected directory change is handled elsewhere so
 		 * that we can locally edit the directory and save on a



From dhowells at redhat.com  Tue May  2 09:35:28 2023
From: dhowells at redhat.com (David Howells)
Date: Tue,  2 May 2023 17:35:28 +0100
Subject: [PATCH 3/3] afs: Avoid endless loop if file is larger than expected
In-Reply-To: <20230502163528.1564398-1-dhowells@redhat.com>
References: <20230502163528.1564398-1-dhowells@redhat.com>
Message-ID: <20230502163528.1564398-4-dhowells@redhat.com>

From: Marc Dionne <marc.dionne at auristor.com>

afs_read_dir fetches an amount of data that's based on what the inode
size is thought to be.  If the file on the server is larger than what
was fetched, the code rechecks i_size and retries.  If the local i_size
was not properly updated, this can lead to an endless loop of fetching
i_size from the server and noticing each time that the size is larger on
the server.

If it is known that the remote size is larger than i_size, bump up the
fetch size to that size.

Fixes: f3ddee8dc4e2 ("afs: Fix directory handling")
Signed-off-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: linux-afs at lists.infradead.org
---
 fs/afs/dir.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/afs/dir.c b/fs/afs/dir.c
index f92b9e62d567..4dd97afa536c 100644
--- a/fs/afs/dir.c
+++ b/fs/afs/dir.c
@@ -275,6 +275,7 @@ static struct afs_read *afs_read_dir(struct afs_vnode *dvnode, struct key *key)
 	loff_t i_size;
 	int nr_pages, i;
 	int ret;
+	loff_t remote_size = 0;
 
 	_enter("");
 
@@ -289,6 +290,8 @@ static struct afs_read *afs_read_dir(struct afs_vnode *dvnode, struct key *key)
 
 expand:
 	i_size = i_size_read(&dvnode->netfs.inode);
+	if (i_size < remote_size)
+	    i_size = remote_size;
 	if (i_size < 2048) {
 		ret = afs_bad(dvnode, afs_file_error_dir_small);
 		goto error;
@@ -364,6 +367,7 @@ static struct afs_read *afs_read_dir(struct afs_vnode *dvnode, struct key *key)
 			 * buffer.
 			 */
 			up_write(&dvnode->validate_lock);
+			remote_size = req->file_size;
 			goto expand;
 		}
 



From dhowells at redhat.com  Tue May  2 09:35:27 2023
From: dhowells at redhat.com (David Howells)
Date: Tue,  2 May 2023 17:35:27 +0100
Subject: [PATCH 2/3] afs: Fix getattr to report server i_size on dirs, not local size
In-Reply-To: <20230502163528.1564398-1-dhowells@redhat.com>
References: <20230502163528.1564398-1-dhowells@redhat.com>
Message-ID: <20230502163528.1564398-3-dhowells@redhat.com>

Fix afs_getattr() to report the server's idea of the file size of a
directory rather than the local size.  The local size may differ as we edit
the local copy to avoid having to redownload it and we may end up with a
differently structured blob of a different size.

However, if the directory is discarded from the pagecache we then download
it again and the user may see the directory file size apparently change.

Fixes: 63a4681ff39c ("afs: Locally edit directory data for mkdir/create/unlink/...")
Signed-off-by: David Howells <dhowells at redhat.com>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: linux-afs at lists.infradead.org
---
 fs/afs/inode.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index 82edd3351734..866bab860a88 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -450,7 +450,7 @@ static void afs_get_inode_cache(struct afs_vnode *vnode)
 				    0 : FSCACHE_ADV_SINGLE_CHUNK,
 				    &key, sizeof(key),
 				    &aux, sizeof(aux),
-				    vnode->status.size));
+				    i_size_read(&vnode->netfs.inode)));
 #endif
 }
 
@@ -777,6 +777,13 @@ int afs_getattr(struct mnt_idmap *idmap, const struct path *path,
 		if (test_bit(AFS_VNODE_SILLY_DELETED, &vnode->flags) &&
 		    stat->nlink > 0)
 			stat->nlink -= 1;
+
+		/* Lie about the size of directories.  We maintain a locally
+		 * edited copy and may make different allocation decisions on
+		 * it, but we need to give userspace the server's size.
+		 */
+		if (S_ISDIR(inode->i_mode))
+			stat->size = vnode->netfs.remote_i_size;
 	} while (need_seqretry(&vnode->cb_lock, seq));
 
 	done_seqretry(&vnode->cb_lock, seq);



From torvalds at linux-foundation.org  Tue May  2 10:56:40 2023
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Tue, 2 May 2023 10:56:40 -0700
Subject: [PATCH 0/3] afs: Fix directory size handling
In-Reply-To: <20230502163528.1564398-1-dhowells@redhat.com>
References: <20230502163528.1564398-1-dhowells@redhat.com>
Message-ID: <CAHk-=wioTxLt1pkt6uwVfFNaZ98fONWaMfY5ybZfzYt6BaSM2g@mail.gmail.com>

On Tue, May 2, 2023 at 9:35?AM David Howells <dhowells at redhat.com> wrote:
>
> The patches can be found here:
>
>         https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=afs-fixes

Ok, I started pulling this, and then I realized that this is the first
time in this release window that I've gotten a non-signed pull
request.

(Not that it was a proper pull request format anyway - the above is
just a gitweb pointer, not a real git branch pointer, but it was close
enough)

So can you please just make this a proper signed tag, and maybe we'll
have the first release ever when every single pull is done with
signage?

I know you can do this properly, since  I have several pull requests
from you that were signed, including for AFS.

                 Linus


From dhowells at redhat.com  Tue May  2 11:22:00 2023
From: dhowells at redhat.com (David Howells)
Date: Tue, 02 May 2023 19:22:00 +0100
Subject: [GIT PULL] afs: Fix directory size handling
Message-ID: <1647979.1683051720@warthog.procyon.org.uk>

Hi Linus,

Could you apply these three fixes to AFS directory handling?

 (1) Make sure that afs_read_dir() sees any increase in file size if the
     file unexpectedly changed on the server (e.g. due to another client
     making a change).

 (2) Make afs_getattr() always return the server's dir file size, not the
     locally edited one, so that pagecache eviction doesn't cause the dir
     file size to change unexpectedly.

 (3) Prevent afs_read_dir() from getting into an endless loop if the server
     indicates that the directory file size is larger than expected.

Thanks,
David
---
The following changes since commit 865fdb08197e657c59e74a35fa32362b12397f58:

  Merge tag 'input-for-v6.4-rc0' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input (2023-05-01 17:18:56 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/afs-fixes-20230502

for you to fetch changes up to 9ea4eff4b6f4f36546d537a74da44fd3f30903ab:

  afs: Avoid endless loop if file is larger than expected (2023-05-02 17:23:50 +0100)

----------------------------------------------------------------
AFS fixes

----------------------------------------------------------------
David Howells (1):
      afs: Fix getattr to report server i_size on dirs, not local size

Marc Dionne (2):
      afs: Fix updating of i_size with dv jump from server
      afs: Avoid endless loop if file is larger than expected

 fs/afs/dir.c   |  4 ++++
 fs/afs/inode.c | 10 +++++++++-
 2 files changed, 13 insertions(+), 1 deletion(-)



From pr-tracker-bot at kernel.org  Tue May  2 11:27:24 2023
From: pr-tracker-bot at kernel.org (pr-tracker-bot at kernel.org)
Date: Tue, 02 May 2023 18:27:24 +0000
Subject: [GIT PULL] afs: Fix directory size handling
In-Reply-To: <1647979.1683051720@warthog.procyon.org.uk>
References: <1647979.1683051720@warthog.procyon.org.uk>
Message-ID: <168305204429.24192.13992141451694182484.pr-tracker-bot@kernel.org>

The pull request you sent on Tue, 02 May 2023 19:22:00 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/afs-fixes-20230502

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/21d2be646007a1c5461f4233749c368693aa6d9f

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


From dhowells at redhat.com  Wed May  3 03:16:26 2023
From: dhowells at redhat.com (David Howells)
Date: Wed, 03 May 2023 11:16:26 +0100
Subject: [PATCH] strace: Implement decoding of RXRPC_* control messages
Message-ID: <1877225.1683108986@warthog.procyon.org.uk>

    
* src/xlat/rxrpc_cmsg_types.in: New file
* src/msghdr.c (print_cmsg_rxrpc_user_call_id, print_cmsg_ullong):
  New functions.
* NEWS: Mention this change.

Signed-off-by: David Howells <dhowells at redhat.com>
---
 NEWS                         |    1 
 src/msghdr.c                 |   53 +++++++++++++++++++++++++++++++++++++++++++
 src/xlat/rxrpc_cmsg_types.in |   12 +++++++++
 3 files changed, 66 insertions(+)

diff --git a/NEWS b/NEWS
index 6cdeb64a5..5c237a6ce 100644
--- a/NEWS
+++ b/NEWS
@@ -14,6 +14,7 @@ Noteworthy changes in release ?.? (????-??-??)
   * Implemented decoding of IFLA_BRPORT_MCAST_N_GROUPS,
     IFLA_BRPORT_MCAST_MAX_GROUPS, IFLA_GSO_IPV4_MAX_SIZE,
     IFLA_GRO_IPV4_MAX_SIZE, and TCA_EXT_WARN_MSG netlink attributes.
+  * Implemented decoding of RXRPC_* control messages.
   * Updated lists of F_SEAL_*, IFLA_*, IORING_*, MFD_*, NFT_*, TCA_*,
     and V4L2_PIX_FMT_* constants.
   * Updated lists of ioctl commands from Linux 6.3.
diff --git a/src/msghdr.c b/src/msghdr.c
index cbcb8b9a4..9605e0f9c 100644
--- a/src/msghdr.c
+++ b/src/msghdr.c
@@ -22,6 +22,7 @@
 #include "xlat/msg_flags.h"
 #include "xlat/scmvals.h"
 #include "xlat/ip_cmsg_types.h"
+#include "xlat/rxrpc_cmsg_types.h"
 
 #ifndef current_wordsize
 struct cmsghdr32 {
@@ -167,6 +168,16 @@ print_cmsg_xint8_t(struct tcb *tcp, const void *cmsg_data,
 			     print_xint_array_member, NULL, 0, NULL, NULL);
 }
 
+static void
+print_cmsg_ullong(struct tcb *tcp, const void *cmsg_data,
+		  const unsigned int data_len)
+{
+	const unsigned long long *p = cmsg_data;
+
+	print_local_array_ex(tcp, p, data_len / sizeof(*p), sizeof(*p),
+			     print_uint_array_member, NULL, 0, NULL, NULL);
+}
+
 struct sock_ee {
 	uint32_t ee_errno;
 	uint8_t  ee_origin;
@@ -212,6 +223,25 @@ print_cmsg_ip_origdstaddr(struct tcb *tcp, const void *cmsg_data,
 	print_sockaddr(tcp, cmsg_data, addr_len);
 }
 
+static void
+print_cmsg_rxrpc_user_call_id(struct tcb *tcp, const void *cmsg_data,
+			      const unsigned int data_len)
+{
+	const unsigned int *p = cmsg_data;
+
+	/* Size is "unsigned long" but we might be stracing a 32-bit program
+	 * from a 64-bit strace or vice versa.
+	 */
+	if (data_len == 4)
+		print_local_array_ex(tcp, p, 1, 4,
+				     print_xint_array_member, NULL, 0, NULL, NULL);
+	else if (data_len == 8)
+		print_local_array_ex(tcp, p, 1, 8,
+				     print_xint_array_member, NULL, 0, NULL, NULL);
+	else
+		print_cmsg_uint(tcp, cmsg_data, data_len);
+}
+
 typedef void (* const cmsg_printer)(struct tcb *, const void *, unsigned int);
 
 static const struct {
@@ -237,6 +267,19 @@ static const struct {
 	[IP_ORIGDSTADDR] = { print_cmsg_ip_origdstaddr, sizeof(struct sockaddr_in) },
 	[IP_CHECKSUM] = { print_cmsg_uint, sizeof(unsigned int) },
 	[SCM_SECURITY] = { print_scm_security, 1 }
+}, cmsg_rxrpc_printers[] = {
+	[RXRPC_USER_CALL_ID]	= { print_cmsg_rxrpc_user_call_id, sizeof(unsigned int) },
+	[RXRPC_ABORT]		= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_ACK]		= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_NET_ERROR]	= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_BUSY]		= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_LOCAL_ERROR]	= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_NEW_CALL]	= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_EXCLUSIVE_CALL]	= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_UPGRADE_SERVICE]	= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_TX_LENGTH]	= { print_cmsg_ullong, sizeof(unsigned long long) },
+	[RXRPC_SET_CALL_TIMEOUT]= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_CHARGE_ACCEPT]	= { print_cmsg_uint, sizeof(unsigned int) },
 };
 
 static void
@@ -265,6 +308,16 @@ print_cmsg_type_data(struct tcb *tcp, const int cmsg_level, const int cmsg_type,
 			cmsg_ip_printers[utype].printer(tcp, cmsg_data, data_len);
 		}
 		break;
+	case SOL_RXRPC:
+		printxval(rxrpc_cmsg_types, cmsg_type, "RXRPC_???");
+		if (utype < ARRAY_SIZE(cmsg_rxrpc_printers)
+		    && cmsg_rxrpc_printers[utype].printer
+		    && data_len >= cmsg_rxrpc_printers[utype].min_len) {
+			tprint_struct_next();
+			tprints_field_name("cmsg_data");
+			cmsg_rxrpc_printers[utype].printer(tcp, cmsg_data, data_len);
+		}
+		break;
 	default:
 		PRINT_VAL_X(cmsg_type);
 	}
diff --git a/src/xlat/rxrpc_cmsg_types.in b/src/xlat/rxrpc_cmsg_types.in
new file mode 100644
index 000000000..7e045b5a6
--- /dev/null
+++ b/src/xlat/rxrpc_cmsg_types.in
@@ -0,0 +1,12 @@
+RXRPC_USER_CALL_ID	1
+RXRPC_ABORT		2
+RXRPC_ACK		3
+RXRPC_NET_ERROR		5
+RXRPC_BUSY		6
+RXRPC_LOCAL_ERROR	7
+RXRPC_NEW_CALL		8
+RXRPC_EXCLUSIVE_CALL	10
+RXRPC_UPGRADE_SERVICE	11
+RXRPC_TX_LENGTH		12
+RXRPC_SET_CALL_TIMEOUT	13
+RXRPC_CHARGE_ACCEPT	14



From hch at lst.de  Wed May  3 08:45:25 2023
From: hch at lst.de (Christoph Hellwig)
Date: Wed,  3 May 2023 17:45:25 +0200
Subject: [PATCH 1/2] filemap: fix the conditional folio_put in filemap_fault
Message-ID: <20230503154526.1223095-1-hch@lst.de>

folio can't be NULL here now that __filemap_get_folio returns an
ERR_PTR.  Remove the conditional folio_put after the out_retry
label and add a new label for the cases where we have a valid folio.

Fixes: 66dabbb65d67 ("mm: return an ERR_PTR from __filemap_get_folio")
Reported-by: syzbot+48011b86c8ea329af1b9 at syzkaller.appspotmail.com
Signed-off-by: Christoph Hellwig <hch at lst.de>
---
 mm/filemap.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/mm/filemap.c b/mm/filemap.c
index a34abfe8c65430..ae597f63a9bc54 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -3298,7 +3298,7 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
 	}
 
 	if (!lock_folio_maybe_drop_mmap(vmf, folio, &fpin))
-		goto out_retry;
+		goto out_retry_put_folio;
 
 	/* Did it get truncated? */
 	if (unlikely(folio->mapping != mapping)) {
@@ -3334,7 +3334,7 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
 	 */
 	if (fpin) {
 		folio_unlock(folio);
-		goto out_retry;
+		goto out_retry_put_folio;
 	}
 	if (mapping_locked)
 		filemap_invalidate_unlock_shared(mapping);
@@ -3363,7 +3363,7 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
 	fpin = maybe_unlock_mmap_for_io(vmf, fpin);
 	error = filemap_read_folio(file, mapping->a_ops->read_folio, folio);
 	if (fpin)
-		goto out_retry;
+		goto out_retry_put_folio;
 	folio_put(folio);
 
 	if (!error || error == AOP_TRUNCATED_PAGE)
@@ -3372,14 +3372,14 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
 
 	return VM_FAULT_SIGBUS;
 
+out_retry_put_folio:
+	folio_put(folio);
 out_retry:
 	/*
 	 * We dropped the mmap_lock, we need to return to the fault handler to
 	 * re-find the vma and come back and find our hopefully still populated
 	 * page.
 	 */
-	if (folio)
-		folio_put(folio);
 	if (mapping_locked)
 		filemap_invalidate_unlock_shared(mapping);
 	if (fpin)
-- 
2.39.2



From hch at lst.de  Wed May  3 08:45:26 2023
From: hch at lst.de (Christoph Hellwig)
Date: Wed,  3 May 2023 17:45:26 +0200
Subject: [PATCH 2/2] afs: fix the afs_dir_get_folio return value
In-Reply-To: <20230503154526.1223095-1-hch@lst.de>
References: <20230503154526.1223095-1-hch@lst.de>
Message-ID: <20230503154526.1223095-2-hch@lst.de>

Keep returning NULL on failure instead of letting an ERR_PTR escape to
callers that don't expect it.

Fixes: 66dabbb65d67 ("mm: return an ERR_PTR from __filemap_get_folio")
Reported-by: Jan Kara <jack at suse.cz>
Signed-off-by: Christoph Hellwig <hch at lst.de>
---
 fs/afs/dir_edit.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/afs/dir_edit.c b/fs/afs/dir_edit.c
index f0eddccbdd9541..e2fa577b66fe0a 100644
--- a/fs/afs/dir_edit.c
+++ b/fs/afs/dir_edit.c
@@ -115,11 +115,12 @@ static struct folio *afs_dir_get_folio(struct afs_vnode *vnode, pgoff_t index)
 	folio = __filemap_get_folio(mapping, index,
 				    FGP_LOCK | FGP_ACCESSED | FGP_CREAT,
 				    mapping->gfp_mask);
-	if (IS_ERR(folio))
+	if (IS_ERR(folio)) {
 		clear_bit(AFS_VNODE_DIR_VALID, &vnode->flags);
-	else if (folio && !folio_test_private(folio))
+		return NULL;
+	}
+	if (!folio_test_private(folio))
 		folio_attach_private(folio, (void *)1);
-
 	return folio;
 }
 
-- 
2.39.2



From willy at infradead.org  Wed May  3 08:48:20 2023
From: willy at infradead.org (Matthew Wilcox)
Date: Wed, 3 May 2023 16:48:20 +0100
Subject: [PATCH 1/2] filemap: fix the conditional folio_put in
 filemap_fault
In-Reply-To: <20230503154526.1223095-1-hch@lst.de>
References: <20230503154526.1223095-1-hch@lst.de>
Message-ID: <ZFKCRPRgoKWaWhQW@casper.infradead.org>

On Wed, May 03, 2023 at 05:45:25PM +0200, Christoph Hellwig wrote:
> @@ -3372,14 +3372,14 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
>  
>  	return VM_FAULT_SIGBUS;
>  
> +out_retry_put_folio:
> +	folio_put(folio);
>  out_retry:
>  	/*
>  	 * We dropped the mmap_lock, we need to return to the fault handler to
>  	 * re-find the vma and come back and find our hopefully still populated
>  	 * page.
>  	 */
> -	if (folio)
> -		folio_put(folio);

Why not simply:

-	if (folio)
+	if (!IS_ERR_OR_NULL(folio))


From jack at suse.cz  Wed May  3 08:54:12 2023
From: jack at suse.cz (Jan Kara)
Date: Wed, 3 May 2023 17:54:12 +0200
Subject: [PATCH 2/2] afs: fix the afs_dir_get_folio return value
In-Reply-To: <20230503154526.1223095-2-hch@lst.de>
References: <20230503154526.1223095-1-hch@lst.de>
 <20230503154526.1223095-2-hch@lst.de>
Message-ID: <20230503155412.a7t4fhtlnvxojdoq@quack3>

On Wed 03-05-23 17:45:26, Christoph Hellwig wrote:
> Keep returning NULL on failure instead of letting an ERR_PTR escape to
> callers that don't expect it.
> 
> Fixes: 66dabbb65d67 ("mm: return an ERR_PTR from __filemap_get_folio")
> Reported-by: Jan Kara <jack at suse.cz>
> Signed-off-by: Christoph Hellwig <hch at lst.de>

Looks good to me. Feel free to add:

Reviewed-by: Jan Kara <jack at suse.cz>

								Honza

> ---
>  fs/afs/dir_edit.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/afs/dir_edit.c b/fs/afs/dir_edit.c
> index f0eddccbdd9541..e2fa577b66fe0a 100644
> --- a/fs/afs/dir_edit.c
> +++ b/fs/afs/dir_edit.c
> @@ -115,11 +115,12 @@ static struct folio *afs_dir_get_folio(struct afs_vnode *vnode, pgoff_t index)
>  	folio = __filemap_get_folio(mapping, index,
>  				    FGP_LOCK | FGP_ACCESSED | FGP_CREAT,
>  				    mapping->gfp_mask);
> -	if (IS_ERR(folio))
> +	if (IS_ERR(folio)) {
>  		clear_bit(AFS_VNODE_DIR_VALID, &vnode->flags);
> -	else if (folio && !folio_test_private(folio))
> +		return NULL;
> +	}
> +	if (!folio_test_private(folio))
>  		folio_attach_private(folio, (void *)1);
> -
>  	return folio;
>  }
>  
> -- 
> 2.39.2
> 
-- 
Jan Kara <jack at suse.com>
SUSE Labs, CR


From jack at suse.cz  Wed May  3 08:57:06 2023
From: jack at suse.cz (Jan Kara)
Date: Wed, 3 May 2023 17:57:06 +0200
Subject: [PATCH 1/2] filemap: fix the conditional folio_put in
 filemap_fault
In-Reply-To: <20230503154526.1223095-1-hch@lst.de>
References: <20230503154526.1223095-1-hch@lst.de>
Message-ID: <20230503155706.3j3y3nlfh6aglhhm@quack3>

On Wed 03-05-23 17:45:25, Christoph Hellwig wrote:
> folio can't be NULL here now that __filemap_get_folio returns an
> ERR_PTR.  Remove the conditional folio_put after the out_retry
> label and add a new label for the cases where we have a valid folio.
> 
> Fixes: 66dabbb65d67 ("mm: return an ERR_PTR from __filemap_get_folio")
> Reported-by: syzbot+48011b86c8ea329af1b9 at syzkaller.appspotmail.com
> Signed-off-by: Christoph Hellwig <hch at lst.de>

Looks good to me. Feel free to add:

Reviewed-by: Jan Kara <jack at suse.cz>

								Honza

> ---
>  mm/filemap.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/mm/filemap.c b/mm/filemap.c
> index a34abfe8c65430..ae597f63a9bc54 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -3298,7 +3298,7 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
>  	}
>  
>  	if (!lock_folio_maybe_drop_mmap(vmf, folio, &fpin))
> -		goto out_retry;
> +		goto out_retry_put_folio;
>  
>  	/* Did it get truncated? */
>  	if (unlikely(folio->mapping != mapping)) {
> @@ -3334,7 +3334,7 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
>  	 */
>  	if (fpin) {
>  		folio_unlock(folio);
> -		goto out_retry;
> +		goto out_retry_put_folio;
>  	}
>  	if (mapping_locked)
>  		filemap_invalidate_unlock_shared(mapping);
> @@ -3363,7 +3363,7 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
>  	fpin = maybe_unlock_mmap_for_io(vmf, fpin);
>  	error = filemap_read_folio(file, mapping->a_ops->read_folio, folio);
>  	if (fpin)
> -		goto out_retry;
> +		goto out_retry_put_folio;
>  	folio_put(folio);
>  
>  	if (!error || error == AOP_TRUNCATED_PAGE)
> @@ -3372,14 +3372,14 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
>  
>  	return VM_FAULT_SIGBUS;
>  
> +out_retry_put_folio:
> +	folio_put(folio);
>  out_retry:
>  	/*
>  	 * We dropped the mmap_lock, we need to return to the fault handler to
>  	 * re-find the vma and come back and find our hopefully still populated
>  	 * page.
>  	 */
> -	if (folio)
> -		folio_put(folio);
>  	if (mapping_locked)
>  		filemap_invalidate_unlock_shared(mapping);
>  	if (fpin)
> -- 
> 2.39.2
> 
-- 
Jan Kara <jack at suse.com>
SUSE Labs, CR


From dhowells at redhat.com  Wed May  3 11:55:03 2023
From: dhowells at redhat.com (David Howells)
Date: Wed, 03 May 2023 19:55:03 +0100
Subject: [PATCH 2/2] afs: fix the afs_dir_get_folio return value
In-Reply-To: <20230503154526.1223095-2-hch@lst.de>
References: <20230503154526.1223095-2-hch@lst.de> <20230503154526.1223095-1-hch@lst.de>
Message-ID: <1916967.1683140103@warthog.procyon.org.uk>

Christoph Hellwig <hch at lst.de> wrote:

> Keep returning NULL on failure instead of letting an ERR_PTR escape to
> callers that don't expect it.
> 
> Fixes: 66dabbb65d67 ("mm: return an ERR_PTR from __filemap_get_folio")
> Reported-by: Jan Kara <jack at suse.cz>
> Signed-off-by: Christoph Hellwig <hch at lst.de>

Reviewed-by: David Howells <dhowells at redhat.com>
Tested-by: David Howells <dhowells at redhat.com>



From willy at infradead.org  Wed May  3 20:34:43 2023
From: willy at infradead.org (Matthew Wilcox)
Date: Thu, 4 May 2023 04:34:43 +0100
Subject: [PATCH 1/2] filemap: fix the conditional folio_put in
 filemap_fault
In-Reply-To: <20230503154936.GA31522@lst.de>
References: <20230503154526.1223095-1-hch@lst.de>
 <ZFKCRPRgoKWaWhQW@casper.infradead.org>
 <20230503154936.GA31522@lst.de>
Message-ID: <ZFMn0zGC58KtQw6N@casper.infradead.org>

On Wed, May 03, 2023 at 05:49:36PM +0200, Christoph Hellwig wrote:
> On Wed, May 03, 2023 at 04:48:20PM +0100, Matthew Wilcox wrote:
> > > -		folio_put(folio);
> > 
> > Why not simply:
> > 
> > -	if (folio)
> > +	if (!IS_ERR_OR_NULL(folio))
> 
> no need for the OR_NULL.

Right.  I didn't read the whole function.

> But I find the extra label way easier to
> reason about, and it's exactly the same amount of code.

If it were easy to reason about, it would have a less ugly name.


From leos.sladek at neston24.com  Thu May  4 00:40:13 2023
From: leos.sladek at neston24.com (=?UTF-8?Q? Leo=C5=A1_Sl=C3=A1dek ?=)
Date: Thu,  4 May 2023 07:40:13 GMT
Subject: =?UTF-8?Q?Fotovoltaick=C3=A9_rozvodnice?=
Message-ID: <20230504064500-0.1.6m.d08q.0.1d232bdqci@neston24.com>

Dobr? den,

obrac?m se na V?s jm?nem dlouholet?ho v?robce fotovoltaick?ch rozvodnic ur?en?ch pro
soukrom? i pr?myslov? pou?it?.

Dod?v?me fotovoltaick? rozvodnice na zak?zku a jsme schopni realizovat i ty nejn?ro?n?j??
po?adavky instala?n?ch firem, velkoobchod? a distributor?.

Vyu??v?me nejkvalitn?j?? komponenty a materi?ly, ??m? dosahujeme vy??? odolnost, stabilitu
provozu a ochranu proti vod?, vlku, prachu a n?raz?m.

V na?em sortimentu jsou tak? omezova?e p?ep?t? AC/DC, kter? zaji??uj? ochranu
fotovoltaick?ch nap?jec?ch instalac? p?ed negativn?mi efekty p?ep?t? a chr?n? za??zen? p?ed
efekty p?soben? p?ep?t? a bleskov?ch proud?.

Chcete si vyzkou?et na?e ?e?en??


S pozdravem
Leo? Sl?dek


From dhowells at redhat.com  Fri May  5 06:57:15 2023
From: dhowells at redhat.com (David Howells)
Date: Fri, 05 May 2023 14:57:15 +0100
Subject: [PATCH strace] Implement decoding of RXRPC_* control messages
Message-ID: <2044497.1683295035@warthog.procyon.org.uk>

    
* src/xlat/rxrpc_cmsg_types.in: New file
* src/msghdr.c (print_cmsg_rxrpc_user_call_id, print_cmsg_ullong):
  New functions.
* NEWS: Mention this change.

Signed-off-by: David Howells <dhowells at redhat.com>
---
 NEWS                         |    1 +
 src/msghdr.c                 |   63 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 src/xlat/rxrpc_cmsg_types.in |   12 ++++++++++++
 3 files changed, 76 insertions(+)

diff --git a/NEWS b/NEWS
index 6cdeb64a5..5c237a6ce 100644
--- a/NEWS
+++ b/NEWS
@@ -14,6 +14,7 @@ Noteworthy changes in release ?.? (????-??-??)
   * Implemented decoding of IFLA_BRPORT_MCAST_N_GROUPS,
     IFLA_BRPORT_MCAST_MAX_GROUPS, IFLA_GSO_IPV4_MAX_SIZE,
     IFLA_GRO_IPV4_MAX_SIZE, and TCA_EXT_WARN_MSG netlink attributes.
+  * Implemented decoding of RXRPC_* control messages.
   * Updated lists of F_SEAL_*, IFLA_*, IORING_*, MFD_*, NFT_*, TCA_*,
     and V4L2_PIX_FMT_* constants.
   * Updated lists of ioctl commands from Linux 6.3.
diff --git a/src/msghdr.c b/src/msghdr.c
index cbcb8b9a4..1227274fb 100644
--- a/src/msghdr.c
+++ b/src/msghdr.c
@@ -22,6 +22,7 @@
 #include "xlat/msg_flags.h"
 #include "xlat/scmvals.h"
 #include "xlat/ip_cmsg_types.h"
+#include "xlat/rxrpc_cmsg_types.h"
 
 #ifndef current_wordsize
 struct cmsghdr32 {
@@ -159,6 +160,16 @@ print_cmsg_uint(struct tcb *tcp, const void *cmsg_data,
 			     print_uint_array_member, NULL, 0, NULL, NULL);
 }
 
+static void
+print_cmsg_xint(struct tcb *tcp, const void *cmsg_data,
+		const unsigned int data_len)
+{
+	const unsigned int *p = cmsg_data;
+
+	print_local_array_ex(tcp, p, data_len / sizeof(*p), sizeof(*p),
+			     print_xint_array_member, NULL, 0, NULL, NULL);
+}
+
 static void
 print_cmsg_xint8_t(struct tcb *tcp, const void *cmsg_data,
 		   const unsigned int data_len)
@@ -167,6 +178,16 @@ print_cmsg_xint8_t(struct tcb *tcp, const void *cmsg_data,
 			     print_xint_array_member, NULL, 0, NULL, NULL);
 }
 
+static void
+print_cmsg_ullong(struct tcb *tcp, const void *cmsg_data,
+		  const unsigned int data_len)
+{
+	const unsigned long long *p = cmsg_data;
+
+	print_local_array_ex(tcp, p, data_len / sizeof(*p), sizeof(*p),
+			     print_uint_array_member, NULL, 0, NULL, NULL);
+}
+
 struct sock_ee {
 	uint32_t ee_errno;
 	uint8_t  ee_origin;
@@ -212,6 +233,25 @@ print_cmsg_ip_origdstaddr(struct tcb *tcp, const void *cmsg_data,
 	print_sockaddr(tcp, cmsg_data, addr_len);
 }
 
+static void
+print_cmsg_rxrpc_user_call_id(struct tcb *tcp, const void *cmsg_data,
+			      const unsigned int data_len)
+{
+	const unsigned int *p = cmsg_data;
+
+	/* Size is "unsigned long" but we might be stracing a 32-bit program
+	 * from a 64-bit strace or vice versa.
+	 */
+	if (data_len == 4)
+		print_local_array_ex(tcp, p, 1, 4,
+				     print_xint_array_member, NULL, 0, NULL, NULL);
+	else if (data_len == 8)
+		print_local_array_ex(tcp, p, 1, 8,
+				     print_xint_array_member, NULL, 0, NULL, NULL);
+	else
+		print_cmsg_xint(tcp, cmsg_data, data_len);
+}
+
 typedef void (* const cmsg_printer)(struct tcb *, const void *, unsigned int);
 
 static const struct {
@@ -237,6 +277,19 @@ static const struct {
 	[IP_ORIGDSTADDR] = { print_cmsg_ip_origdstaddr, sizeof(struct sockaddr_in) },
 	[IP_CHECKSUM] = { print_cmsg_uint, sizeof(unsigned int) },
 	[SCM_SECURITY] = { print_scm_security, 1 }
+}, cmsg_rxrpc_printers[] = {
+	[RXRPC_USER_CALL_ID]	= { print_cmsg_rxrpc_user_call_id, sizeof(unsigned int) },
+	[RXRPC_ABORT]		= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_ACK]		= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_NET_ERROR]	= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_BUSY]		= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_LOCAL_ERROR]	= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_NEW_CALL]	= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_EXCLUSIVE_CALL]	= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_UPGRADE_SERVICE]	= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_TX_LENGTH]	= { print_cmsg_ullong, sizeof(unsigned long long) },
+	[RXRPC_SET_CALL_TIMEOUT] = { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_CHARGE_ACCEPT]	= { print_cmsg_uint, sizeof(unsigned int) },
 };
 
 static void
@@ -265,6 +318,16 @@ print_cmsg_type_data(struct tcb *tcp, const int cmsg_level, const int cmsg_type,
 			cmsg_ip_printers[utype].printer(tcp, cmsg_data, data_len);
 		}
 		break;
+	case SOL_RXRPC:
+		printxval(rxrpc_cmsg_types, cmsg_type, "RXRPC_???");
+		if (utype < ARRAY_SIZE(cmsg_rxrpc_printers)
+		    && cmsg_rxrpc_printers[utype].printer
+		    && data_len >= cmsg_rxrpc_printers[utype].min_len) {
+			tprint_struct_next();
+			tprints_field_name("cmsg_data");
+			cmsg_rxrpc_printers[utype].printer(tcp, cmsg_data, data_len);
+		}
+		break;
 	default:
 		PRINT_VAL_X(cmsg_type);
 	}
diff --git a/src/xlat/rxrpc_cmsg_types.in b/src/xlat/rxrpc_cmsg_types.in
new file mode 100644
index 000000000..7e045b5a6
--- /dev/null
+++ b/src/xlat/rxrpc_cmsg_types.in
@@ -0,0 +1,12 @@
+RXRPC_USER_CALL_ID	1
+RXRPC_ABORT		2
+RXRPC_ACK		3
+RXRPC_NET_ERROR		5
+RXRPC_BUSY		6
+RXRPC_LOCAL_ERROR	7
+RXRPC_NEW_CALL		8
+RXRPC_EXCLUSIVE_CALL	10
+RXRPC_UPGRADE_SERVICE	11
+RXRPC_TX_LENGTH		12
+RXRPC_SET_CALL_TIMEOUT	13
+RXRPC_CHARGE_ACCEPT	14



From gregkh at linuxfoundation.org  Mon May  8 02:46:38 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon,  8 May 2023 11:46:38 +0200
Subject: [PATCH 6.1 556/611] afs: Fix updating of i_size with dv jump from server
In-Reply-To: <20230508094421.513073170@linuxfoundation.org>
References: <20230508094421.513073170@linuxfoundation.org>
Message-ID: <20230508094440.059674538@linuxfoundation.org>

From: Marc Dionne <marc.dionne at auristor.com>

[ Upstream commit d7f74e9a917503ee78f2b603a456d7227cf38919 ]

If the data version returned from the server is larger than expected,
the local data is invalidated, but we may still want to note the remote
file size.

Since we're setting change_size, we have to also set data_changed
for the i_size to get updated.

Fixes: 3f4aa9818163 ("afs: Fix EOF corruption")
Signed-off-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: linux-afs at lists.infradead.org
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 fs/afs/inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index 6d3a3dbe49286..52d040ffde35f 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -230,6 +230,7 @@ static void afs_apply_status(struct afs_operation *op,
 			set_bit(AFS_VNODE_ZAP_DATA, &vnode->flags);
 		}
 		change_size = true;
+		data_changed = true;
 	} else if (vnode->status.type == AFS_FTYPE_DIR) {
 		/* Expected directory change is handled elsewhere so
 		 * that we can locally edit the directory and save on a
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May  8 02:46:39 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon,  8 May 2023 11:46:39 +0200
Subject: [PATCH 6.1 557/611] afs: Fix getattr to report server i_size on dirs, not local size
In-Reply-To: <20230508094421.513073170@linuxfoundation.org>
References: <20230508094421.513073170@linuxfoundation.org>
Message-ID: <20230508094440.088196358@linuxfoundation.org>

From: David Howells <dhowells at redhat.com>

[ Upstream commit 45f66fa03ba9943cca5af88d691399332b8bde08 ]

Fix afs_getattr() to report the server's idea of the file size of a
directory rather than the local size.  The local size may differ as we edit
the local copy to avoid having to redownload it and we may end up with a
differently structured blob of a different size.

However, if the directory is discarded from the pagecache we then download
it again and the user may see the directory file size apparently change.

Fixes: 63a4681ff39c ("afs: Locally edit directory data for mkdir/create/unlink/...")
Signed-off-by: David Howells <dhowells at redhat.com>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: linux-afs at lists.infradead.org
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 fs/afs/inode.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index 52d040ffde35f..5921dd3687e39 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -450,7 +450,7 @@ static void afs_get_inode_cache(struct afs_vnode *vnode)
 				    0 : FSCACHE_ADV_SINGLE_CHUNK,
 				    &key, sizeof(key),
 				    &aux, sizeof(aux),
-				    vnode->status.size));
+				    i_size_read(&vnode->netfs.inode)));
 #endif
 }
 
@@ -766,6 +766,13 @@ int afs_getattr(struct user_namespace *mnt_userns, const struct path *path,
 		if (test_bit(AFS_VNODE_SILLY_DELETED, &vnode->flags) &&
 		    stat->nlink > 0)
 			stat->nlink -= 1;
+
+		/* Lie about the size of directories.  We maintain a locally
+		 * edited copy and may make different allocation decisions on
+		 * it, but we need to give userspace the server's size.
+		 */
+		if (S_ISDIR(inode->i_mode))
+			stat->size = vnode->netfs.remote_i_size;
 	} while (need_seqretry(&vnode->cb_lock, seq));
 
 	done_seqretry(&vnode->cb_lock, seq);
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May  8 02:46:40 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon,  8 May 2023 11:46:40 +0200
Subject: [PATCH 6.1 558/611] afs: Avoid endless loop if file is larger than expected
In-Reply-To: <20230508094421.513073170@linuxfoundation.org>
References: <20230508094421.513073170@linuxfoundation.org>
Message-ID: <20230508094440.120434882@linuxfoundation.org>

From: Marc Dionne <marc.dionne at auristor.com>

[ Upstream commit 9ea4eff4b6f4f36546d537a74da44fd3f30903ab ]

afs_read_dir fetches an amount of data that's based on what the inode
size is thought to be.  If the file on the server is larger than what
was fetched, the code rechecks i_size and retries.  If the local i_size
was not properly updated, this can lead to an endless loop of fetching
i_size from the server and noticing each time that the size is larger on
the server.

If it is known that the remote size is larger than i_size, bump up the
fetch size to that size.

Fixes: f3ddee8dc4e2 ("afs: Fix directory handling")
Signed-off-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: linux-afs at lists.infradead.org
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 fs/afs/dir.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/afs/dir.c b/fs/afs/dir.c
index 104df2964225c..f73b2f62afaae 100644
--- a/fs/afs/dir.c
+++ b/fs/afs/dir.c
@@ -274,6 +274,7 @@ static struct afs_read *afs_read_dir(struct afs_vnode *dvnode, struct key *key)
 	loff_t i_size;
 	int nr_pages, i;
 	int ret;
+	loff_t remote_size = 0;
 
 	_enter("");
 
@@ -288,6 +289,8 @@ static struct afs_read *afs_read_dir(struct afs_vnode *dvnode, struct key *key)
 
 expand:
 	i_size = i_size_read(&dvnode->netfs.inode);
+	if (i_size < remote_size)
+	    i_size = remote_size;
 	if (i_size < 2048) {
 		ret = afs_bad(dvnode, afs_file_error_dir_small);
 		goto error;
@@ -363,6 +366,7 @@ static struct afs_read *afs_read_dir(struct afs_vnode *dvnode, struct key *key)
 			 * buffer.
 			 */
 			up_write(&dvnode->validate_lock);
+			remote_size = req->file_size;
 			goto expand;
 		}
 
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May  8 02:48:24 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon,  8 May 2023 11:48:24 +0200
Subject: [PATCH 6.3 669/694] afs: Fix updating of i_size with dv jump from server
In-Reply-To: <20230508094432.603705160@linuxfoundation.org>
References: <20230508094432.603705160@linuxfoundation.org>
Message-ID: <20230508094457.836144619@linuxfoundation.org>

From: Marc Dionne <marc.dionne at auristor.com>

[ Upstream commit d7f74e9a917503ee78f2b603a456d7227cf38919 ]

If the data version returned from the server is larger than expected,
the local data is invalidated, but we may still want to note the remote
file size.

Since we're setting change_size, we have to also set data_changed
for the i_size to get updated.

Fixes: 3f4aa9818163 ("afs: Fix EOF corruption")
Signed-off-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: linux-afs at lists.infradead.org
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 fs/afs/inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index 0167e96e51986..790cca53c1453 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -230,6 +230,7 @@ static void afs_apply_status(struct afs_operation *op,
 			set_bit(AFS_VNODE_ZAP_DATA, &vnode->flags);
 		}
 		change_size = true;
+		data_changed = true;
 	} else if (vnode->status.type == AFS_FTYPE_DIR) {
 		/* Expected directory change is handled elsewhere so
 		 * that we can locally edit the directory and save on a
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May  8 02:48:25 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon,  8 May 2023 11:48:25 +0200
Subject: [PATCH 6.3 670/694] afs: Fix getattr to report server i_size on dirs, not local size
In-Reply-To: <20230508094432.603705160@linuxfoundation.org>
References: <20230508094432.603705160@linuxfoundation.org>
Message-ID: <20230508094457.879320762@linuxfoundation.org>

From: David Howells <dhowells at redhat.com>

[ Upstream commit 45f66fa03ba9943cca5af88d691399332b8bde08 ]

Fix afs_getattr() to report the server's idea of the file size of a
directory rather than the local size.  The local size may differ as we edit
the local copy to avoid having to redownload it and we may end up with a
differently structured blob of a different size.

However, if the directory is discarded from the pagecache we then download
it again and the user may see the directory file size apparently change.

Fixes: 63a4681ff39c ("afs: Locally edit directory data for mkdir/create/unlink/...")
Signed-off-by: David Howells <dhowells at redhat.com>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: linux-afs at lists.infradead.org
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 fs/afs/inode.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index 790cca53c1453..c5098f70b53af 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -450,7 +450,7 @@ static void afs_get_inode_cache(struct afs_vnode *vnode)
 				    0 : FSCACHE_ADV_SINGLE_CHUNK,
 				    &key, sizeof(key),
 				    &aux, sizeof(aux),
-				    vnode->status.size));
+				    i_size_read(&vnode->netfs.inode)));
 #endif
 }
 
@@ -766,6 +766,13 @@ int afs_getattr(struct mnt_idmap *idmap, const struct path *path,
 		if (test_bit(AFS_VNODE_SILLY_DELETED, &vnode->flags) &&
 		    stat->nlink > 0)
 			stat->nlink -= 1;
+
+		/* Lie about the size of directories.  We maintain a locally
+		 * edited copy and may make different allocation decisions on
+		 * it, but we need to give userspace the server's size.
+		 */
+		if (S_ISDIR(inode->i_mode))
+			stat->size = vnode->netfs.remote_i_size;
 	} while (need_seqretry(&vnode->cb_lock, seq));
 
 	done_seqretry(&vnode->cb_lock, seq);
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May  8 02:48:26 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon,  8 May 2023 11:48:26 +0200
Subject: [PATCH 6.3 671/694] afs: Avoid endless loop if file is larger than expected
In-Reply-To: <20230508094432.603705160@linuxfoundation.org>
References: <20230508094432.603705160@linuxfoundation.org>
Message-ID: <20230508094457.927978645@linuxfoundation.org>

From: Marc Dionne <marc.dionne at auristor.com>

[ Upstream commit 9ea4eff4b6f4f36546d537a74da44fd3f30903ab ]

afs_read_dir fetches an amount of data that's based on what the inode
size is thought to be.  If the file on the server is larger than what
was fetched, the code rechecks i_size and retries.  If the local i_size
was not properly updated, this can lead to an endless loop of fetching
i_size from the server and noticing each time that the size is larger on
the server.

If it is known that the remote size is larger than i_size, bump up the
fetch size to that size.

Fixes: f3ddee8dc4e2 ("afs: Fix directory handling")
Signed-off-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: linux-afs at lists.infradead.org
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 fs/afs/dir.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/afs/dir.c b/fs/afs/dir.c
index 82690d1dd49a0..a97499fd747b6 100644
--- a/fs/afs/dir.c
+++ b/fs/afs/dir.c
@@ -275,6 +275,7 @@ static struct afs_read *afs_read_dir(struct afs_vnode *dvnode, struct key *key)
 	loff_t i_size;
 	int nr_pages, i;
 	int ret;
+	loff_t remote_size = 0;
 
 	_enter("");
 
@@ -289,6 +290,8 @@ static struct afs_read *afs_read_dir(struct afs_vnode *dvnode, struct key *key)
 
 expand:
 	i_size = i_size_read(&dvnode->netfs.inode);
+	if (i_size < remote_size)
+	    i_size = remote_size;
 	if (i_size < 2048) {
 		ret = afs_bad(dvnode, afs_file_error_dir_small);
 		goto error;
@@ -364,6 +367,7 @@ static struct afs_read *afs_read_dir(struct afs_vnode *dvnode, struct key *key)
 			 * buffer.
 			 */
 			up_write(&dvnode->validate_lock);
+			remote_size = req->file_size;
 			goto expand;
 		}
 
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May  8 02:49:05 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon,  8 May 2023 11:49:05 +0200
Subject: [PATCH 5.15 344/371] afs: Fix updating of i_size with dv jump from server
In-Reply-To: <20230508094811.912279944@linuxfoundation.org>
References: <20230508094811.912279944@linuxfoundation.org>
Message-ID: <20230508094825.799944115@linuxfoundation.org>

From: Marc Dionne <marc.dionne at auristor.com>

[ Upstream commit d7f74e9a917503ee78f2b603a456d7227cf38919 ]

If the data version returned from the server is larger than expected,
the local data is invalidated, but we may still want to note the remote
file size.

Since we're setting change_size, we have to also set data_changed
for the i_size to get updated.

Fixes: 3f4aa9818163 ("afs: Fix EOF corruption")
Signed-off-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: linux-afs at lists.infradead.org
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 fs/afs/inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index 785bacb972da5..91b1f8cabd58f 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -219,6 +219,7 @@ static void afs_apply_status(struct afs_operation *op,
 			set_bit(AFS_VNODE_ZAP_DATA, &vnode->flags);
 		}
 		change_size = true;
+		data_changed = true;
 	} else if (vnode->status.type == AFS_FTYPE_DIR) {
 		/* Expected directory change is handled elsewhere so
 		 * that we can locally edit the directory and save on a
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May  8 02:47:14 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon,  8 May 2023 11:47:14 +0200
Subject: [PATCH 6.2 608/663] afs: Fix updating of i_size with dv jump from server
In-Reply-To: <20230508094428.384831245@linuxfoundation.org>
References: <20230508094428.384831245@linuxfoundation.org>
Message-ID: <20230508094449.368633304@linuxfoundation.org>

From: Marc Dionne <marc.dionne at auristor.com>

[ Upstream commit d7f74e9a917503ee78f2b603a456d7227cf38919 ]

If the data version returned from the server is larger than expected,
the local data is invalidated, but we may still want to note the remote
file size.

Since we're setting change_size, we have to also set data_changed
for the i_size to get updated.

Fixes: 3f4aa9818163 ("afs: Fix EOF corruption")
Signed-off-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: linux-afs at lists.infradead.org
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 fs/afs/inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index 6d3a3dbe49286..52d040ffde35f 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -230,6 +230,7 @@ static void afs_apply_status(struct afs_operation *op,
 			set_bit(AFS_VNODE_ZAP_DATA, &vnode->flags);
 		}
 		change_size = true;
+		data_changed = true;
 	} else if (vnode->status.type == AFS_FTYPE_DIR) {
 		/* Expected directory change is handled elsewhere so
 		 * that we can locally edit the directory and save on a
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May  8 02:47:15 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon,  8 May 2023 11:47:15 +0200
Subject: [PATCH 6.2 609/663] afs: Fix getattr to report server i_size on dirs, not local size
In-Reply-To: <20230508094428.384831245@linuxfoundation.org>
References: <20230508094428.384831245@linuxfoundation.org>
Message-ID: <20230508094449.409584684@linuxfoundation.org>

From: David Howells <dhowells at redhat.com>

[ Upstream commit 45f66fa03ba9943cca5af88d691399332b8bde08 ]

Fix afs_getattr() to report the server's idea of the file size of a
directory rather than the local size.  The local size may differ as we edit
the local copy to avoid having to redownload it and we may end up with a
differently structured blob of a different size.

However, if the directory is discarded from the pagecache we then download
it again and the user may see the directory file size apparently change.

Fixes: 63a4681ff39c ("afs: Locally edit directory data for mkdir/create/unlink/...")
Signed-off-by: David Howells <dhowells at redhat.com>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: linux-afs at lists.infradead.org
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 fs/afs/inode.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index 52d040ffde35f..5921dd3687e39 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -450,7 +450,7 @@ static void afs_get_inode_cache(struct afs_vnode *vnode)
 				    0 : FSCACHE_ADV_SINGLE_CHUNK,
 				    &key, sizeof(key),
 				    &aux, sizeof(aux),
-				    vnode->status.size));
+				    i_size_read(&vnode->netfs.inode)));
 #endif
 }
 
@@ -766,6 +766,13 @@ int afs_getattr(struct user_namespace *mnt_userns, const struct path *path,
 		if (test_bit(AFS_VNODE_SILLY_DELETED, &vnode->flags) &&
 		    stat->nlink > 0)
 			stat->nlink -= 1;
+
+		/* Lie about the size of directories.  We maintain a locally
+		 * edited copy and may make different allocation decisions on
+		 * it, but we need to give userspace the server's size.
+		 */
+		if (S_ISDIR(inode->i_mode))
+			stat->size = vnode->netfs.remote_i_size;
 	} while (need_seqretry(&vnode->cb_lock, seq));
 
 	done_seqretry(&vnode->cb_lock, seq);
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May  8 02:47:16 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon,  8 May 2023 11:47:16 +0200
Subject: [PATCH 6.2 610/663] afs: Avoid endless loop if file is larger than expected
In-Reply-To: <20230508094428.384831245@linuxfoundation.org>
References: <20230508094428.384831245@linuxfoundation.org>
Message-ID: <20230508094449.457046865@linuxfoundation.org>

From: Marc Dionne <marc.dionne at auristor.com>

[ Upstream commit 9ea4eff4b6f4f36546d537a74da44fd3f30903ab ]

afs_read_dir fetches an amount of data that's based on what the inode
size is thought to be.  If the file on the server is larger than what
was fetched, the code rechecks i_size and retries.  If the local i_size
was not properly updated, this can lead to an endless loop of fetching
i_size from the server and noticing each time that the size is larger on
the server.

If it is known that the remote size is larger than i_size, bump up the
fetch size to that size.

Fixes: f3ddee8dc4e2 ("afs: Fix directory handling")
Signed-off-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: linux-afs at lists.infradead.org
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 fs/afs/dir.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/afs/dir.c b/fs/afs/dir.c
index b7c1f8c84b38a..be8f8da5b6b02 100644
--- a/fs/afs/dir.c
+++ b/fs/afs/dir.c
@@ -275,6 +275,7 @@ static struct afs_read *afs_read_dir(struct afs_vnode *dvnode, struct key *key)
 	loff_t i_size;
 	int nr_pages, i;
 	int ret;
+	loff_t remote_size = 0;
 
 	_enter("");
 
@@ -289,6 +290,8 @@ static struct afs_read *afs_read_dir(struct afs_vnode *dvnode, struct key *key)
 
 expand:
 	i_size = i_size_read(&dvnode->netfs.inode);
+	if (i_size < remote_size)
+	    i_size = remote_size;
 	if (i_size < 2048) {
 		ret = afs_bad(dvnode, afs_file_error_dir_small);
 		goto error;
@@ -364,6 +367,7 @@ static struct afs_read *afs_read_dir(struct afs_vnode *dvnode, struct key *key)
 			 * buffer.
 			 */
 			up_write(&dvnode->validate_lock);
+			remote_size = req->file_size;
 			goto expand;
 		}
 
-- 
2.39.2





From krystian.wieczorek at feshiecree.pl  Tue May  9 00:35:45 2023
From: krystian.wieczorek at feshiecree.pl (Krystian Wieczorek)
Date: Tue,  9 May 2023 07:35:45 GMT
Subject: W sprawie samochodu
Message-ID: <20230509074504-0.1.2g.f9vs.0.gcnnop9ein@feshiecree.pl>

Dzie? dobry,

chcieliby?my zapewni? Pa?stwu kompleksowe rozwi?zania, je?li chodzi o system monitoringu GPS.

Precyzyjne monitorowanie pojazd?w na mapach cyfrowych, ?ledzenie ich parametr?w eksploatacyjnych w czasie rzeczywistym oraz kontrola paliwa to kluczowe funkcjonalno?ci naszego systemu. 

Organizowanie pracy pracownik?w jest dzi?ki temu prostsze i bardziej efektywne, a oszcz?dno?ci i optymalizacja w zakresie ponoszonych koszt?w, maj? dla ka?dego przedsi?biorcy ogromne znaczenie.

Dopasujemy nasz? ofert? do Pa?stwa oczekiwa? i potrzeb organizacji. Czy mogliby?my porozmawia? o naszej propozycji?


Pozdrawiam
Krystian Wieczorek


From ldv at strace.io  Tue May  9 01:00:42 2023
From: ldv at strace.io (Dmitry V. Levin)
Date: Tue, 9 May 2023 11:00:42 +0300
Subject: [PATCH strace] Implement decoding of RXRPC_* control messages
In-Reply-To: <2044497.1683295035@warthog.procyon.org.uk>
References: <2044497.1683295035@warthog.procyon.org.uk>
Message-ID: <20230509080042.GA22326@altlinux.org>

Hi,

On Fri, May 05, 2023 at 02:57:15PM +0100, David Howells wrote:
[...]
> @@ -212,6 +233,25 @@ print_cmsg_ip_origdstaddr(struct tcb *tcp, const void *cmsg_data,
>  	print_sockaddr(tcp, cmsg_data, addr_len);
>  }
>  
> +static void
> +print_cmsg_rxrpc_user_call_id(struct tcb *tcp, const void *cmsg_data,
> +			      const unsigned int data_len)
> +{
> +	const unsigned int *p = cmsg_data;
> +
> +	/* Size is "unsigned long" but we might be stracing a 32-bit program
> +	 * from a 64-bit strace or vice versa.
> +	 */
> +	if (data_len == 4)
> +		print_local_array_ex(tcp, p, 1, 4,
> +				     print_xint_array_member, NULL, 0, NULL, NULL);
> +	else if (data_len == 8)
> +		print_local_array_ex(tcp, p, 1, 8,
> +				     print_xint_array_member, NULL, 0, NULL, NULL);
> +	else
> +		print_cmsg_xint(tcp, cmsg_data, data_len);
> +}
> +

I suppose a switch statement would be more concise in this case.

> diff --git a/src/xlat/rxrpc_cmsg_types.in b/src/xlat/rxrpc_cmsg_types.in
> new file mode 100644
> index 000000000..7e045b5a6
> --- /dev/null
> +++ b/src/xlat/rxrpc_cmsg_types.in
> @@ -0,0 +1,12 @@
> +RXRPC_USER_CALL_ID	1
> +RXRPC_ABORT		2
> +RXRPC_ACK		3
> +RXRPC_NET_ERROR		5
> +RXRPC_BUSY		6
> +RXRPC_LOCAL_ERROR	7
> +RXRPC_NEW_CALL		8
> +RXRPC_EXCLUSIVE_CALL	10
> +RXRPC_UPGRADE_SERVICE	11
> +RXRPC_TX_LENGTH		12
> +RXRPC_SET_CALL_TIMEOUT	13
> +RXRPC_CHARGE_ACCEPT	14

Looks like this table would benefit from #value_indexed.

By the way, would it make sense to list RXRPC_ACCEPT here as well, even
though it was removed from the kernel by commit v4.9-rc1~127^2~247^2?

And the last but not least, do you have any ideas how this new decoder
could be tested?


-- 
ldv


From hch at lst.de  Wed May  3 08:49:36 2023
From: hch at lst.de (Christoph Hellwig)
Date: Wed, 3 May 2023 17:49:36 +0200
Subject: [PATCH 1/2] filemap: fix the conditional folio_put in
 filemap_fault
In-Reply-To: <ZFKCRPRgoKWaWhQW@casper.infradead.org>
References: <20230503154526.1223095-1-hch@lst.de> <ZFKCRPRgoKWaWhQW@casper.infradead.org>
Message-ID: <20230503154936.GA31522@lst.de>

On Wed, May 03, 2023 at 04:48:20PM +0100, Matthew Wilcox wrote:
> > -		folio_put(folio);
> 
> Why not simply:
> 
> -	if (folio)
> +	if (!IS_ERR_OR_NULL(folio))

no need for the OR_NULL.  But I find the extra label way easier to
reason about, and it's exactly the same amount of code.


From gregkh at linuxfoundation.org  Mon May  8 02:44:16 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon,  8 May 2023 11:44:16 +0200
Subject: [PATCH 6.2 430/663] rxrpc: Fix error when reading rxrpc tokens
In-Reply-To: <20230508094428.384831245@linuxfoundation.org>
References: <20230508094428.384831245@linuxfoundation.org>
Message-ID: <20230508094442.012078721@linuxfoundation.org>

From: Marc Dionne <marc.dionne at auristor.com>

[ Upstream commit fadfc57cc8047080a123b16f288b7138524fb1e2 ]

When converting from ASSERTCMP to WARN_ON, the tested condition must
be inverted, which was missed for this case.

This would cause an EIO error when trying to read an rxrpc token, for
instance when trying to display tokens with AuriStor's "tokens" command.

Fixes: 84924aac08a4 ("rxrpc: Fix checker warning")
Signed-off-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: netdev at vger.kernel.org
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 net/rxrpc/key.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rxrpc/key.c b/net/rxrpc/key.c
index 8d53aded09c42..33e8302a79e33 100644
--- a/net/rxrpc/key.c
+++ b/net/rxrpc/key.c
@@ -680,7 +680,7 @@ static long rxrpc_read(const struct key *key,
 			return -ENOPKG;
 		}
 
-		if (WARN_ON((unsigned long)xdr - (unsigned long)oldxdr ==
+		if (WARN_ON((unsigned long)xdr - (unsigned long)oldxdr !=
 			    toksize))
 			return -EIO;
 	}
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May  8 02:45:13 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon,  8 May 2023 11:45:13 +0200
Subject: [PATCH 6.3 478/694] rxrpc: Fix error when reading rxrpc tokens
In-Reply-To: <20230508094432.603705160@linuxfoundation.org>
References: <20230508094432.603705160@linuxfoundation.org>
Message-ID: <20230508094449.355890639@linuxfoundation.org>

From: Marc Dionne <marc.dionne at auristor.com>

[ Upstream commit fadfc57cc8047080a123b16f288b7138524fb1e2 ]

When converting from ASSERTCMP to WARN_ON, the tested condition must
be inverted, which was missed for this case.

This would cause an EIO error when trying to read an rxrpc token, for
instance when trying to display tokens with AuriStor's "tokens" command.

Fixes: 84924aac08a4 ("rxrpc: Fix checker warning")
Signed-off-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: netdev at vger.kernel.org
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 net/rxrpc/key.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rxrpc/key.c b/net/rxrpc/key.c
index 8d53aded09c42..33e8302a79e33 100644
--- a/net/rxrpc/key.c
+++ b/net/rxrpc/key.c
@@ -680,7 +680,7 @@ static long rxrpc_read(const struct key *key,
 			return -ENOPKG;
 		}
 
-		if (WARN_ON((unsigned long)xdr - (unsigned long)oldxdr ==
+		if (WARN_ON((unsigned long)xdr - (unsigned long)oldxdr !=
 			    toksize))
 			return -EIO;
 	}
-- 
2.39.2





From tj at kernel.org  Mon May  8 18:50:29 2023
From: tj at kernel.org (Tejun Heo)
Date: Mon,  8 May 2023 15:50:29 -1000
Subject: [PATCH 10/13] rxrpc: Use alloc_ordered_workqueue() to create ordered workqueues
In-Reply-To: <20230509015032.3768622-1-tj@kernel.org>
References: <20230509015032.3768622-1-tj@kernel.org>
Message-ID: <20230509015032.3768622-11-tj@kernel.org>

BACKGROUND
==========

When multiple work items are queued to a workqueue, their execution order
doesn't match the queueing order. They may get executed in any order and
simultaneously. When fully serialized execution - one by one in the queueing
order - is needed, an ordered workqueue should be used which can be created
with alloc_ordered_workqueue().

However, alloc_ordered_workqueue() was a later addition. Before it, an
ordered workqueue could be obtained by creating an UNBOUND workqueue with
@max_active==1. This originally was an implementation side-effect which was
broken by 4c16bd327c74 ("workqueue: restore WQ_UNBOUND/max_active==1 to be
ordered"). Because there were users that depended on the ordered execution,
5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered")
made workqueue allocation path to implicitly promote UNBOUND workqueues w/
@max_active==1 to ordered workqueues.

While this has worked okay, overloading the UNBOUND allocation interface
this way creates other issues. It's difficult to tell whether a given
workqueue actually needs to be ordered and users that legitimately want a
min concurrency level wq unexpectedly gets an ordered one instead. With
planned UNBOUND workqueue updates to improve execution locality and more
prevalence of chiplet designs which can benefit from such improvements, this
isn't a state we wanna be in forever.

This patch series audits all callsites that create an UNBOUND workqueue w/
@max_active==1 and converts them to alloc_ordered_workqueue() as necessary.

WHAT TO LOOK FOR
================

The conversions are from

  alloc_workqueue(WQ_UNBOUND | flags, 1, args..)

to

  alloc_ordered_workqueue(flags, args...)

which don't cause any functional changes. If you know that fully ordered
execution is not ncessary, please let me know. I'll drop the conversion and
instead add a comment noting the fact to reduce confusion while conversion
is in progress.

If you aren't fully sure, it's completely fine to let the conversion
through. The behavior will stay exactly the same and we can always
reconsider later.

As there are follow-up workqueue core changes, I'd really appreciate if the
patch can be routed through the workqueue tree w/ your acks. Thanks.

Signed-off-by: Tejun Heo <tj at kernel.org>
Cc: David Howells <dhowells at redhat.com>
Cc: Marc Dionne <marc.dionne at auristor.com>
Cc: "David S. Miller" <davem at davemloft.net>
Cc: Eric Dumazet <edumazet at google.com>
Cc: Jakub Kicinski <kuba at kernel.org>
Cc: Paolo Abeni <pabeni at redhat.com>
Cc: linux-afs at lists.infradead.org
Cc: netdev at vger.kernel.org
---
 net/rxrpc/af_rxrpc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index 31f738d65f1c..7eb24c25c731 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -988,7 +988,7 @@ static int __init af_rxrpc_init(void)
 		goto error_call_jar;
 	}
 
-	rxrpc_workqueue = alloc_workqueue("krxrpcd", WQ_HIGHPRI | WQ_MEM_RECLAIM | WQ_UNBOUND, 1);
+	rxrpc_workqueue = alloc_ordered_workqueue("krxrpcd", WQ_HIGHPRI | WQ_MEM_RECLAIM);
 	if (!rxrpc_workqueue) {
 		pr_notice("Failed to allocate work queue\n");
 		goto error_work_queue;
-- 
2.40.1



From gregkh at linuxfoundation.org  Mon May 15 09:28:49 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 May 2023 18:28:49 +0200
Subject: [PATCH 5.10 278/381] afs: Fix updating of i_size with dv jump from server
In-Reply-To: <20230515161736.775969473@linuxfoundation.org>
References: <20230515161736.775969473@linuxfoundation.org>
Message-ID: <20230515161749.334568422@linuxfoundation.org>

From: Marc Dionne <marc.dionne at auristor.com>

[ Upstream commit d7f74e9a917503ee78f2b603a456d7227cf38919 ]

If the data version returned from the server is larger than expected,
the local data is invalidated, but we may still want to note the remote
file size.

Since we're setting change_size, we have to also set data_changed
for the i_size to get updated.

Fixes: 3f4aa9818163 ("afs: Fix EOF corruption")
Signed-off-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: linux-afs at lists.infradead.org
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 fs/afs/inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index 826fae22a8cc9..fdca4262f806a 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -218,6 +218,7 @@ static void afs_apply_status(struct afs_operation *op,
 			set_bit(AFS_VNODE_ZAP_DATA, &vnode->flags);
 		}
 		change_size = true;
+		data_changed = true;
 	} else if (vnode->status.type == AFS_FTYPE_DIR) {
 		/* Expected directory change is handled elsewhere so
 		 * that we can locally edit the directory and save on a
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May 15 09:29:29 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 May 2023 18:29:29 +0200
Subject: [PATCH 5.4 191/282] afs: Fix updating of i_size with dv jump from server
In-Reply-To: <20230515161722.146344674@linuxfoundation.org>
References: <20230515161722.146344674@linuxfoundation.org>
Message-ID: <20230515161727.990533831@linuxfoundation.org>

From: Marc Dionne <marc.dionne at auristor.com>

[ Upstream commit d7f74e9a917503ee78f2b603a456d7227cf38919 ]

If the data version returned from the server is larger than expected,
the local data is invalidated, but we may still want to note the remote
file size.

Since we're setting change_size, we have to also set data_changed
for the i_size to get updated.

Fixes: 3f4aa9818163 ("afs: Fix EOF corruption")
Signed-off-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: linux-afs at lists.infradead.org
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 fs/afs/inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index 622363af4c1bf..fd681eec49aa2 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -227,6 +227,7 @@ static void afs_apply_status(struct afs_fs_cursor *fc,
 			set_bit(AFS_VNODE_ZAP_DATA, &vnode->flags);
 		}
 		change_size = true;
+		data_changed = true;
 	} else if (vnode->status.type == AFS_FTYPE_DIR) {
 		/* Expected directory change is handled elsewhere so
 		 * that we can locally edit the directory and save on a
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May 15 09:26:31 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 May 2023 18:26:31 +0200
Subject: [PATCH 4.19 154/191] rxrpc: Fix hard call timeout units
In-Reply-To: <20230515161707.203549282@linuxfoundation.org>
References: <20230515161707.203549282@linuxfoundation.org>
Message-ID: <20230515161713.016576684@linuxfoundation.org>

From: David Howells <dhowells at redhat.com>

[ Upstream commit 0d098d83c5d9e107b2df7f5e11f81492f56d2fe7 ]

The hard call timeout is specified in the RXRPC_SET_CALL_TIMEOUT cmsg in
seconds, so fix the point at which sendmsg() applies it to the call to
convert to jiffies from seconds, not milliseconds.

Fixes: a158bdd3247b ("rxrpc: Fix timeout of a call that hasn't yet been granted a channel")
Signed-off-by: David Howells <dhowells at redhat.com>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: netdev at vger.kernel.org
cc: linux-kernel at vger.kernel.org
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 net/rxrpc/sendmsg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index a7a09eb04d93b..eaa032c498c96 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -709,7 +709,7 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
 		/* Fall through */
 	case 1:
 		if (p.call.timeouts.hard > 0) {
-			j = msecs_to_jiffies(p.call.timeouts.hard);
+			j = p.call.timeouts.hard * HZ;
 			now = jiffies;
 			j += now;
 			WRITE_ONCE(call->expect_term_by, j);
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May 15 09:23:54 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 May 2023 18:23:54 +0200
Subject: [PATCH 6.3 022/246] rxrpc: Fix potential data race in rxrpc_wait_to_be_connected()
In-Reply-To: <20230515161722.610123835@linuxfoundation.org>
References: <20230515161722.610123835@linuxfoundation.org>
Message-ID: <20230515161723.275161336@linuxfoundation.org>

From: David Howells <dhowells at redhat.com>

[ Upstream commit 2b5fdc0f5caa505afe34d608e2eefadadf2ee67a ]

Inside the loop in rxrpc_wait_to_be_connected() it checks call->error to
see if it should exit the loop without first checking the call state.  This
is probably safe as if call->error is set, the call is dead anyway, but we
should probably wait for the call state to have been set to completion
first, lest it cause surprise on the way out.

Fix this by only accessing call->error if the call is complete.  We don't
actually need to access the error inside the loop as we'll do that after.

This caused the following report:

    BUG: KCSAN: data-race in rxrpc_send_data / rxrpc_set_call_completion

    write to 0xffff888159cf3c50 of 4 bytes by task 25673 on cpu 1:
     rxrpc_set_call_completion+0x71/0x1c0 net/rxrpc/call_state.c:22
     rxrpc_send_data_packet+0xba9/0x1650 net/rxrpc/output.c:479
     rxrpc_transmit_one+0x1e/0x130 net/rxrpc/output.c:714
     rxrpc_decant_prepared_tx net/rxrpc/call_event.c:326 [inline]
     rxrpc_transmit_some_data+0x496/0x600 net/rxrpc/call_event.c:350
     rxrpc_input_call_event+0x564/0x1220 net/rxrpc/call_event.c:464
     rxrpc_io_thread+0x307/0x1d80 net/rxrpc/io_thread.c:461
     kthread+0x1ac/0x1e0 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308

    read to 0xffff888159cf3c50 of 4 bytes by task 25672 on cpu 0:
     rxrpc_send_data+0x29e/0x1950 net/rxrpc/sendmsg.c:296
     rxrpc_do_sendmsg+0xb7a/0xc20 net/rxrpc/sendmsg.c:726
     rxrpc_sendmsg+0x413/0x520 net/rxrpc/af_rxrpc.c:565
     sock_sendmsg_nosec net/socket.c:724 [inline]
     sock_sendmsg net/socket.c:747 [inline]
     ____sys_sendmsg+0x375/0x4c0 net/socket.c:2501
     ___sys_sendmsg net/socket.c:2555 [inline]
     __sys_sendmmsg+0x263/0x500 net/socket.c:2641
     __do_sys_sendmmsg net/socket.c:2670 [inline]
     __se_sys_sendmmsg net/socket.c:2667 [inline]
     __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2667
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd

    value changed: 0x00000000 -> 0xffffffea

Fixes: 9d35d880e0e4 ("rxrpc: Move client call connection to the I/O thread")
Reported-by: syzbot+ebc945fdb4acd72cba78 at syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/000000000000e7c6d205fa10a3cd at google.com/
Signed-off-by: David Howells <dhowells at redhat.com>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: Dmitry Vyukov <dvyukov at google.com>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: linux-fsdevel at vger.kernel.org
cc: netdev at vger.kernel.org
Link: https://lore.kernel.org/r/508133.1682427395 at warthog.procyon.org.uk
Signed-off-by: Paolo Abeni <pabeni at redhat.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 net/rxrpc/sendmsg.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index da49fcf1c4567..6caa47d352ed6 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -50,15 +50,11 @@ static int rxrpc_wait_to_be_connected(struct rxrpc_call *call, long *timeo)
 	_enter("%d", call->debug_id);
 
 	if (rxrpc_call_state(call) != RXRPC_CALL_CLIENT_AWAIT_CONN)
-		return call->error;
+		goto no_wait;
 
 	add_wait_queue_exclusive(&call->waitq, &myself);
 
 	for (;;) {
-		ret = call->error;
-		if (ret < 0)
-			break;
-
 		switch (call->interruptibility) {
 		case RXRPC_INTERRUPTIBLE:
 		case RXRPC_PREINTERRUPTIBLE:
@@ -69,10 +65,9 @@ static int rxrpc_wait_to_be_connected(struct rxrpc_call *call, long *timeo)
 			set_current_state(TASK_UNINTERRUPTIBLE);
 			break;
 		}
-		if (rxrpc_call_state(call) != RXRPC_CALL_CLIENT_AWAIT_CONN) {
-			ret = call->error;
+
+		if (rxrpc_call_state(call) != RXRPC_CALL_CLIENT_AWAIT_CONN)
 			break;
-		}
 		if ((call->interruptibility == RXRPC_INTERRUPTIBLE ||
 		     call->interruptibility == RXRPC_PREINTERRUPTIBLE) &&
 		    signal_pending(current)) {
@@ -85,6 +80,7 @@ static int rxrpc_wait_to_be_connected(struct rxrpc_call *call, long *timeo)
 	remove_wait_queue(&call->waitq, &myself);
 	__set_current_state(TASK_RUNNING);
 
+no_wait:
 	if (ret == 0 && rxrpc_call_is_complete(call))
 		ret = call->error;
 
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May 15 09:24:23 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 May 2023 18:24:23 +0200
Subject: [PATCH 6.3 051/246] rxrpc: Fix hard call timeout units
In-Reply-To: <20230515161722.610123835@linuxfoundation.org>
References: <20230515161722.610123835@linuxfoundation.org>
Message-ID: <20230515161724.113631921@linuxfoundation.org>

From: David Howells <dhowells at redhat.com>

[ Upstream commit 0d098d83c5d9e107b2df7f5e11f81492f56d2fe7 ]

The hard call timeout is specified in the RXRPC_SET_CALL_TIMEOUT cmsg in
seconds, so fix the point at which sendmsg() applies it to the call to
convert to jiffies from seconds, not milliseconds.

Fixes: a158bdd3247b ("rxrpc: Fix timeout of a call that hasn't yet been granted a channel")
Signed-off-by: David Howells <dhowells at redhat.com>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: netdev at vger.kernel.org
cc: linux-kernel at vger.kernel.org
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 net/rxrpc/sendmsg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index 6caa47d352ed6..7498a77b5d397 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -699,7 +699,7 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
 		fallthrough;
 	case 1:
 		if (p.call.timeouts.hard > 0) {
-			j = msecs_to_jiffies(p.call.timeouts.hard);
+			j = p.call.timeouts.hard * HZ;
 			now = jiffies;
 			j += now;
 			WRITE_ONCE(call->expect_term_by, j);
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May 15 09:24:24 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 May 2023 18:24:24 +0200
Subject: [PATCH 6.3 052/246] rxrpc: Make it so that a waiting process can be aborted
In-Reply-To: <20230515161722.610123835@linuxfoundation.org>
References: <20230515161722.610123835@linuxfoundation.org>
Message-ID: <20230515161724.142586697@linuxfoundation.org>

From: David Howells <dhowells at redhat.com>

[ Upstream commit 0eb362d254814ce04848730bf32e75b8ee1a4d6c ]

When sendmsg() creates an rxrpc call, it queues it to wait for a connection
and channel to be assigned and then waits before it can start shovelling
data as the encrypted DATA packet content includes a summary of the
connection parameters.

However, sendmsg() may get interrupted before a connection gets assigned
and further sendmsg() calls will fail with EBUSY until an assignment is
made.

Fix this so that the call can at least be aborted without failing on
EBUSY.  We have to be careful here as sendmsg() mustn't be allowed to start
the call timer if the call doesn't yet have a connection assigned as an
oops may follow shortly thereafter.

Fixes: 540b1c48c37a ("rxrpc: Fix deadlock between call creation and sendmsg/recvmsg")
Reported-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: netdev at vger.kernel.org
cc: linux-kernel at vger.kernel.org
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 net/rxrpc/sendmsg.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index 7498a77b5d397..c1b074c17b33e 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -656,10 +656,13 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
 			goto out_put_unlock;
 	} else {
 		switch (rxrpc_call_state(call)) {
-		case RXRPC_CALL_UNINITIALISED:
 		case RXRPC_CALL_CLIENT_AWAIT_CONN:
-		case RXRPC_CALL_SERVER_PREALLOC:
 		case RXRPC_CALL_SERVER_SECURING:
+			if (p.command == RXRPC_CMD_SEND_ABORT)
+				break;
+			fallthrough;
+		case RXRPC_CALL_UNINITIALISED:
+		case RXRPC_CALL_SERVER_PREALLOC:
 			rxrpc_put_call(call, rxrpc_call_put_sendmsg);
 			ret = -EBUSY;
 			goto error_release_sock;
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May 15 09:24:25 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 May 2023 18:24:25 +0200
Subject: [PATCH 6.3 053/246] rxrpc: Fix timeout of a call that hasnt yet been granted a channel
In-Reply-To: <20230515161722.610123835@linuxfoundation.org>
References: <20230515161722.610123835@linuxfoundation.org>
Message-ID: <20230515161724.172164116@linuxfoundation.org>

From: David Howells <dhowells at redhat.com>

[ Upstream commit db099c625b13a74d462521a46d98a8ce5b53af5d ]

afs_make_call() calls rxrpc_kernel_begin_call() to begin a call (which may
get stalled in the background waiting for a connection to become
available); it then calls rxrpc_kernel_set_max_life() to set the timeouts -
but that starts the call timer so the call timer might then expire before
we get a connection assigned - leading to the following oops if the call
stalled:

	BUG: kernel NULL pointer dereference, address: 0000000000000000
	...
	CPU: 1 PID: 5111 Comm: krxrpcio/0 Not tainted 6.3.0-rc7-build3+ #701
	RIP: 0010:rxrpc_alloc_txbuf+0xc0/0x157
	...
	Call Trace:
	 <TASK>
	 rxrpc_send_ACK+0x50/0x13b
	 rxrpc_input_call_event+0x16a/0x67d
	 rxrpc_io_thread+0x1b6/0x45f
	 ? _raw_spin_unlock_irqrestore+0x1f/0x35
	 ? rxrpc_input_packet+0x519/0x519
	 kthread+0xe7/0xef
	 ? kthread_complete_and_exit+0x1b/0x1b
	 ret_from_fork+0x22/0x30

Fix this by noting the timeouts in struct rxrpc_call when the call is
created.  The timer will be started when the first packet is transmitted.

It shouldn't be possible to trigger this directly from userspace through
AF_RXRPC as sendmsg() will return EBUSY if the call is in the
waiting-for-conn state if it dropped out of the wait due to a signal.

Fixes: 9d35d880e0e4 ("rxrpc: Move client call connection to the I/O thread")
Reported-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: netdev at vger.kernel.org
cc: linux-kernel at vger.kernel.org
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 fs/afs/afs.h            |  4 ++--
 fs/afs/internal.h       |  2 +-
 fs/afs/rxrpc.c          |  8 +++-----
 include/net/af_rxrpc.h  | 21 +++++++++++----------
 net/rxrpc/af_rxrpc.c    |  3 +++
 net/rxrpc/ar-internal.h |  1 +
 net/rxrpc/call_object.c |  9 ++++++++-
 net/rxrpc/sendmsg.c     |  1 +
 8 files changed, 30 insertions(+), 19 deletions(-)

diff --git a/fs/afs/afs.h b/fs/afs/afs.h
index 432cb4b239614..81815724db6c9 100644
--- a/fs/afs/afs.h
+++ b/fs/afs/afs.h
@@ -19,8 +19,8 @@
 #define AFSPATHMAX		1024	/* Maximum length of a pathname plus NUL */
 #define AFSOPAQUEMAX		1024	/* Maximum length of an opaque field */
 
-#define AFS_VL_MAX_LIFESPAN	(120 * HZ)
-#define AFS_PROBE_MAX_LIFESPAN	(30 * HZ)
+#define AFS_VL_MAX_LIFESPAN	120
+#define AFS_PROBE_MAX_LIFESPAN	30
 
 typedef u64			afs_volid_t;
 typedef u64			afs_vnodeid_t;
diff --git a/fs/afs/internal.h b/fs/afs/internal.h
index ad8523d0d0386..68ae91d21b578 100644
--- a/fs/afs/internal.h
+++ b/fs/afs/internal.h
@@ -128,7 +128,7 @@ struct afs_call {
 	spinlock_t		state_lock;
 	int			error;		/* error code */
 	u32			abort_code;	/* Remote abort ID or 0 */
-	unsigned int		max_lifespan;	/* Maximum lifespan to set if not 0 */
+	unsigned int		max_lifespan;	/* Maximum lifespan in secs to set if not 0 */
 	unsigned		request_size;	/* size of request data */
 	unsigned		reply_max;	/* maximum size of reply */
 	unsigned		count2;		/* count used in unmarshalling */
diff --git a/fs/afs/rxrpc.c b/fs/afs/rxrpc.c
index 7817e2b860e5e..6862e3dde364b 100644
--- a/fs/afs/rxrpc.c
+++ b/fs/afs/rxrpc.c
@@ -334,7 +334,9 @@ void afs_make_call(struct afs_addr_cursor *ac, struct afs_call *call, gfp_t gfp)
 	/* create a call */
 	rxcall = rxrpc_kernel_begin_call(call->net->socket, srx, call->key,
 					 (unsigned long)call,
-					 tx_total_len, gfp,
+					 tx_total_len,
+					 call->max_lifespan,
+					 gfp,
 					 (call->async ?
 					  afs_wake_up_async_call :
 					  afs_wake_up_call_waiter),
@@ -349,10 +351,6 @@ void afs_make_call(struct afs_addr_cursor *ac, struct afs_call *call, gfp_t gfp)
 	}
 
 	call->rxcall = rxcall;
-
-	if (call->max_lifespan)
-		rxrpc_kernel_set_max_life(call->net->socket, rxcall,
-					  call->max_lifespan);
 	call->issue_time = ktime_get_real();
 
 	/* send the request */
diff --git a/include/net/af_rxrpc.h b/include/net/af_rxrpc.h
index ba717eac0229a..73644bd42a3f9 100644
--- a/include/net/af_rxrpc.h
+++ b/include/net/af_rxrpc.h
@@ -40,16 +40,17 @@ typedef void (*rxrpc_user_attach_call_t)(struct rxrpc_call *, unsigned long);
 void rxrpc_kernel_new_call_notification(struct socket *,
 					rxrpc_notify_new_call_t,
 					rxrpc_discard_new_call_t);
-struct rxrpc_call *rxrpc_kernel_begin_call(struct socket *,
-					   struct sockaddr_rxrpc *,
-					   struct key *,
-					   unsigned long,
-					   s64,
-					   gfp_t,
-					   rxrpc_notify_rx_t,
-					   bool,
-					   enum rxrpc_interruptibility,
-					   unsigned int);
+struct rxrpc_call *rxrpc_kernel_begin_call(struct socket *sock,
+					   struct sockaddr_rxrpc *srx,
+					   struct key *key,
+					   unsigned long user_call_ID,
+					   s64 tx_total_len,
+					   u32 hard_timeout,
+					   gfp_t gfp,
+					   rxrpc_notify_rx_t notify_rx,
+					   bool upgrade,
+					   enum rxrpc_interruptibility interruptibility,
+					   unsigned int debug_id);
 int rxrpc_kernel_send_data(struct socket *, struct rxrpc_call *,
 			   struct msghdr *, size_t,
 			   rxrpc_notify_end_tx_t);
diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index 102f5cbff91a3..a6f0d29f35ef9 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -265,6 +265,7 @@ static int rxrpc_listen(struct socket *sock, int backlog)
  * @key: The security context to use (defaults to socket setting)
  * @user_call_ID: The ID to use
  * @tx_total_len: Total length of data to transmit during the call (or -1)
+ * @hard_timeout: The maximum lifespan of the call in sec
  * @gfp: The allocation constraints
  * @notify_rx: Where to send notifications instead of socket queue
  * @upgrade: Request service upgrade for call
@@ -283,6 +284,7 @@ struct rxrpc_call *rxrpc_kernel_begin_call(struct socket *sock,
 					   struct key *key,
 					   unsigned long user_call_ID,
 					   s64 tx_total_len,
+					   u32 hard_timeout,
 					   gfp_t gfp,
 					   rxrpc_notify_rx_t notify_rx,
 					   bool upgrade,
@@ -313,6 +315,7 @@ struct rxrpc_call *rxrpc_kernel_begin_call(struct socket *sock,
 	p.tx_total_len		= tx_total_len;
 	p.interruptibility	= interruptibility;
 	p.kernel		= true;
+	p.timeouts.hard		= hard_timeout;
 
 	memset(&cp, 0, sizeof(cp));
 	cp.local		= rx->local;
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 67b0a894162d7..5d44dc08f66d0 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -616,6 +616,7 @@ struct rxrpc_call {
 	unsigned long		expect_term_by;	/* When we expect call termination by */
 	u32			next_rx_timo;	/* Timeout for next Rx packet (jif) */
 	u32			next_req_timo;	/* Timeout for next Rx request packet (jif) */
+	u32			hard_timo;	/* Maximum lifetime or 0 (jif) */
 	struct timer_list	timer;		/* Combined event timer */
 	struct work_struct	destroyer;	/* In-process-context destroyer */
 	rxrpc_notify_rx_t	notify_rx;	/* kernel service Rx notification function */
diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
index e9f1f49d18c2a..fecbc73054bc2 100644
--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -226,6 +226,13 @@ static struct rxrpc_call *rxrpc_alloc_client_call(struct rxrpc_sock *rx,
 	if (cp->exclusive)
 		__set_bit(RXRPC_CALL_EXCLUSIVE, &call->flags);
 
+	if (p->timeouts.normal)
+		call->next_rx_timo = min(msecs_to_jiffies(p->timeouts.normal), 1UL);
+	if (p->timeouts.idle)
+		call->next_req_timo = min(msecs_to_jiffies(p->timeouts.idle), 1UL);
+	if (p->timeouts.hard)
+		call->hard_timo = p->timeouts.hard * HZ;
+
 	ret = rxrpc_init_client_call_security(call);
 	if (ret < 0) {
 		rxrpc_prefail_call(call, RXRPC_CALL_LOCAL_ERROR, ret);
@@ -257,7 +264,7 @@ void rxrpc_start_call_timer(struct rxrpc_call *call)
 	call->keepalive_at = j;
 	call->expect_rx_by = j;
 	call->expect_req_by = j;
-	call->expect_term_by = j;
+	call->expect_term_by = j + call->hard_timo;
 	call->timer.expires = now;
 }
 
diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index c1b074c17b33e..8e0b94714e849 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -651,6 +651,7 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
 		if (IS_ERR(call))
 			return PTR_ERR(call);
 		/* ... and we have the call lock. */
+		p.call.nr_timeouts = 0;
 		ret = 0;
 		if (rxrpc_call_is_complete(call))
 			goto out_put_unlock;
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May 15 09:25:24 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 May 2023 18:25:24 +0200
Subject: [PATCH 6.1 061/239] rxrpc: Fix hard call timeout units
In-Reply-To: <20230515161721.545370111@linuxfoundation.org>
References: <20230515161721.545370111@linuxfoundation.org>
Message-ID: <20230515161723.530352001@linuxfoundation.org>

From: David Howells <dhowells at redhat.com>

[ Upstream commit 0d098d83c5d9e107b2df7f5e11f81492f56d2fe7 ]

The hard call timeout is specified in the RXRPC_SET_CALL_TIMEOUT cmsg in
seconds, so fix the point at which sendmsg() applies it to the call to
convert to jiffies from seconds, not milliseconds.

Fixes: a158bdd3247b ("rxrpc: Fix timeout of a call that hasn't yet been granted a channel")
Signed-off-by: David Howells <dhowells at redhat.com>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: netdev at vger.kernel.org
cc: linux-kernel at vger.kernel.org
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 net/rxrpc/sendmsg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index d4e4e94f4f987..71e40f91dd398 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -736,7 +736,7 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
 		fallthrough;
 	case 1:
 		if (p.call.timeouts.hard > 0) {
-			j = msecs_to_jiffies(p.call.timeouts.hard);
+			j = p.call.timeouts.hard * HZ;
 			now = jiffies;
 			j += now;
 			WRITE_ONCE(call->expect_term_by, j);
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May 15 09:25:57 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 May 2023 18:25:57 +0200
Subject: [PATCH 6.2 031/242] rxrpc: Fix potential data race in rxrpc_wait_to_be_connected()
In-Reply-To: <20230515161721.802179972@linuxfoundation.org>
References: <20230515161721.802179972@linuxfoundation.org>
Message-ID: <20230515161722.857279092@linuxfoundation.org>

From: David Howells <dhowells at redhat.com>

[ Upstream commit 2b5fdc0f5caa505afe34d608e2eefadadf2ee67a ]

Inside the loop in rxrpc_wait_to_be_connected() it checks call->error to
see if it should exit the loop without first checking the call state.  This
is probably safe as if call->error is set, the call is dead anyway, but we
should probably wait for the call state to have been set to completion
first, lest it cause surprise on the way out.

Fix this by only accessing call->error if the call is complete.  We don't
actually need to access the error inside the loop as we'll do that after.

This caused the following report:

    BUG: KCSAN: data-race in rxrpc_send_data / rxrpc_set_call_completion

    write to 0xffff888159cf3c50 of 4 bytes by task 25673 on cpu 1:
     rxrpc_set_call_completion+0x71/0x1c0 net/rxrpc/call_state.c:22
     rxrpc_send_data_packet+0xba9/0x1650 net/rxrpc/output.c:479
     rxrpc_transmit_one+0x1e/0x130 net/rxrpc/output.c:714
     rxrpc_decant_prepared_tx net/rxrpc/call_event.c:326 [inline]
     rxrpc_transmit_some_data+0x496/0x600 net/rxrpc/call_event.c:350
     rxrpc_input_call_event+0x564/0x1220 net/rxrpc/call_event.c:464
     rxrpc_io_thread+0x307/0x1d80 net/rxrpc/io_thread.c:461
     kthread+0x1ac/0x1e0 kernel/kthread.c:376
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308

    read to 0xffff888159cf3c50 of 4 bytes by task 25672 on cpu 0:
     rxrpc_send_data+0x29e/0x1950 net/rxrpc/sendmsg.c:296
     rxrpc_do_sendmsg+0xb7a/0xc20 net/rxrpc/sendmsg.c:726
     rxrpc_sendmsg+0x413/0x520 net/rxrpc/af_rxrpc.c:565
     sock_sendmsg_nosec net/socket.c:724 [inline]
     sock_sendmsg net/socket.c:747 [inline]
     ____sys_sendmsg+0x375/0x4c0 net/socket.c:2501
     ___sys_sendmsg net/socket.c:2555 [inline]
     __sys_sendmmsg+0x263/0x500 net/socket.c:2641
     __do_sys_sendmmsg net/socket.c:2670 [inline]
     __se_sys_sendmmsg net/socket.c:2667 [inline]
     __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2667
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd

    value changed: 0x00000000 -> 0xffffffea

Fixes: 9d35d880e0e4 ("rxrpc: Move client call connection to the I/O thread")
Reported-by: syzbot+ebc945fdb4acd72cba78 at syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/000000000000e7c6d205fa10a3cd at google.com/
Signed-off-by: David Howells <dhowells at redhat.com>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: Dmitry Vyukov <dvyukov at google.com>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: linux-fsdevel at vger.kernel.org
cc: netdev at vger.kernel.org
Link: https://lore.kernel.org/r/508133.1682427395 at warthog.procyon.org.uk
Signed-off-by: Paolo Abeni <pabeni at redhat.com>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 net/rxrpc/sendmsg.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index da49fcf1c4567..6caa47d352ed6 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -50,15 +50,11 @@ static int rxrpc_wait_to_be_connected(struct rxrpc_call *call, long *timeo)
 	_enter("%d", call->debug_id);
 
 	if (rxrpc_call_state(call) != RXRPC_CALL_CLIENT_AWAIT_CONN)
-		return call->error;
+		goto no_wait;
 
 	add_wait_queue_exclusive(&call->waitq, &myself);
 
 	for (;;) {
-		ret = call->error;
-		if (ret < 0)
-			break;
-
 		switch (call->interruptibility) {
 		case RXRPC_INTERRUPTIBLE:
 		case RXRPC_PREINTERRUPTIBLE:
@@ -69,10 +65,9 @@ static int rxrpc_wait_to_be_connected(struct rxrpc_call *call, long *timeo)
 			set_current_state(TASK_UNINTERRUPTIBLE);
 			break;
 		}
-		if (rxrpc_call_state(call) != RXRPC_CALL_CLIENT_AWAIT_CONN) {
-			ret = call->error;
+
+		if (rxrpc_call_state(call) != RXRPC_CALL_CLIENT_AWAIT_CONN)
 			break;
-		}
 		if ((call->interruptibility == RXRPC_INTERRUPTIBLE ||
 		     call->interruptibility == RXRPC_PREINTERRUPTIBLE) &&
 		    signal_pending(current)) {
@@ -85,6 +80,7 @@ static int rxrpc_wait_to_be_connected(struct rxrpc_call *call, long *timeo)
 	remove_wait_queue(&call->waitq, &myself);
 	__set_current_state(TASK_RUNNING);
 
+no_wait:
 	if (ret == 0 && rxrpc_call_is_complete(call))
 		ret = call->error;
 
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May 15 09:26:25 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 May 2023 18:26:25 +0200
Subject: [PATCH 6.2 059/242] rxrpc: Fix hard call timeout units
In-Reply-To: <20230515161721.802179972@linuxfoundation.org>
References: <20230515161721.802179972@linuxfoundation.org>
Message-ID: <20230515161723.676271897@linuxfoundation.org>

From: David Howells <dhowells at redhat.com>

[ Upstream commit 0d098d83c5d9e107b2df7f5e11f81492f56d2fe7 ]

The hard call timeout is specified in the RXRPC_SET_CALL_TIMEOUT cmsg in
seconds, so fix the point at which sendmsg() applies it to the call to
convert to jiffies from seconds, not milliseconds.

Fixes: a158bdd3247b ("rxrpc: Fix timeout of a call that hasn't yet been granted a channel")
Signed-off-by: David Howells <dhowells at redhat.com>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: netdev at vger.kernel.org
cc: linux-kernel at vger.kernel.org
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 net/rxrpc/sendmsg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index 6caa47d352ed6..7498a77b5d397 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -699,7 +699,7 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
 		fallthrough;
 	case 1:
 		if (p.call.timeouts.hard > 0) {
-			j = msecs_to_jiffies(p.call.timeouts.hard);
+			j = p.call.timeouts.hard * HZ;
 			now = jiffies;
 			j += now;
 			WRITE_ONCE(call->expect_term_by, j);
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May 15 09:26:26 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 May 2023 18:26:26 +0200
Subject: [PATCH 6.2 060/242] rxrpc: Make it so that a waiting process can be aborted
In-Reply-To: <20230515161721.802179972@linuxfoundation.org>
References: <20230515161721.802179972@linuxfoundation.org>
Message-ID: <20230515161723.705585300@linuxfoundation.org>

From: David Howells <dhowells at redhat.com>

[ Upstream commit 0eb362d254814ce04848730bf32e75b8ee1a4d6c ]

When sendmsg() creates an rxrpc call, it queues it to wait for a connection
and channel to be assigned and then waits before it can start shovelling
data as the encrypted DATA packet content includes a summary of the
connection parameters.

However, sendmsg() may get interrupted before a connection gets assigned
and further sendmsg() calls will fail with EBUSY until an assignment is
made.

Fix this so that the call can at least be aborted without failing on
EBUSY.  We have to be careful here as sendmsg() mustn't be allowed to start
the call timer if the call doesn't yet have a connection assigned as an
oops may follow shortly thereafter.

Fixes: 540b1c48c37a ("rxrpc: Fix deadlock between call creation and sendmsg/recvmsg")
Reported-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: netdev at vger.kernel.org
cc: linux-kernel at vger.kernel.org
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 net/rxrpc/sendmsg.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index 7498a77b5d397..c1b074c17b33e 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -656,10 +656,13 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
 			goto out_put_unlock;
 	} else {
 		switch (rxrpc_call_state(call)) {
-		case RXRPC_CALL_UNINITIALISED:
 		case RXRPC_CALL_CLIENT_AWAIT_CONN:
-		case RXRPC_CALL_SERVER_PREALLOC:
 		case RXRPC_CALL_SERVER_SECURING:
+			if (p.command == RXRPC_CMD_SEND_ABORT)
+				break;
+			fallthrough;
+		case RXRPC_CALL_UNINITIALISED:
+		case RXRPC_CALL_SERVER_PREALLOC:
 			rxrpc_put_call(call, rxrpc_call_put_sendmsg);
 			ret = -EBUSY;
 			goto error_release_sock;
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May 15 09:26:27 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 May 2023 18:26:27 +0200
Subject: [PATCH 6.2 061/242] rxrpc: Fix timeout of a call that hasnt yet been granted a channel
In-Reply-To: <20230515161721.802179972@linuxfoundation.org>
References: <20230515161721.802179972@linuxfoundation.org>
Message-ID: <20230515161723.735198580@linuxfoundation.org>

From: David Howells <dhowells at redhat.com>

[ Upstream commit db099c625b13a74d462521a46d98a8ce5b53af5d ]

afs_make_call() calls rxrpc_kernel_begin_call() to begin a call (which may
get stalled in the background waiting for a connection to become
available); it then calls rxrpc_kernel_set_max_life() to set the timeouts -
but that starts the call timer so the call timer might then expire before
we get a connection assigned - leading to the following oops if the call
stalled:

	BUG: kernel NULL pointer dereference, address: 0000000000000000
	...
	CPU: 1 PID: 5111 Comm: krxrpcio/0 Not tainted 6.3.0-rc7-build3+ #701
	RIP: 0010:rxrpc_alloc_txbuf+0xc0/0x157
	...
	Call Trace:
	 <TASK>
	 rxrpc_send_ACK+0x50/0x13b
	 rxrpc_input_call_event+0x16a/0x67d
	 rxrpc_io_thread+0x1b6/0x45f
	 ? _raw_spin_unlock_irqrestore+0x1f/0x35
	 ? rxrpc_input_packet+0x519/0x519
	 kthread+0xe7/0xef
	 ? kthread_complete_and_exit+0x1b/0x1b
	 ret_from_fork+0x22/0x30

Fix this by noting the timeouts in struct rxrpc_call when the call is
created.  The timer will be started when the first packet is transmitted.

It shouldn't be possible to trigger this directly from userspace through
AF_RXRPC as sendmsg() will return EBUSY if the call is in the
waiting-for-conn state if it dropped out of the wait due to a signal.

Fixes: 9d35d880e0e4 ("rxrpc: Move client call connection to the I/O thread")
Reported-by: Marc Dionne <marc.dionne at auristor.com>
Signed-off-by: David Howells <dhowells at redhat.com>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: netdev at vger.kernel.org
cc: linux-kernel at vger.kernel.org
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 fs/afs/afs.h            |  4 ++--
 fs/afs/internal.h       |  2 +-
 fs/afs/rxrpc.c          |  8 +++-----
 include/net/af_rxrpc.h  | 21 +++++++++++----------
 net/rxrpc/af_rxrpc.c    |  3 +++
 net/rxrpc/ar-internal.h |  1 +
 net/rxrpc/call_object.c |  9 ++++++++-
 net/rxrpc/sendmsg.c     |  1 +
 8 files changed, 30 insertions(+), 19 deletions(-)

diff --git a/fs/afs/afs.h b/fs/afs/afs.h
index 432cb4b239614..81815724db6c9 100644
--- a/fs/afs/afs.h
+++ b/fs/afs/afs.h
@@ -19,8 +19,8 @@
 #define AFSPATHMAX		1024	/* Maximum length of a pathname plus NUL */
 #define AFSOPAQUEMAX		1024	/* Maximum length of an opaque field */
 
-#define AFS_VL_MAX_LIFESPAN	(120 * HZ)
-#define AFS_PROBE_MAX_LIFESPAN	(30 * HZ)
+#define AFS_VL_MAX_LIFESPAN	120
+#define AFS_PROBE_MAX_LIFESPAN	30
 
 typedef u64			afs_volid_t;
 typedef u64			afs_vnodeid_t;
diff --git a/fs/afs/internal.h b/fs/afs/internal.h
index fd8567b98e2bb..cd23a3c5b6ace 100644
--- a/fs/afs/internal.h
+++ b/fs/afs/internal.h
@@ -127,7 +127,7 @@ struct afs_call {
 	spinlock_t		state_lock;
 	int			error;		/* error code */
 	u32			abort_code;	/* Remote abort ID or 0 */
-	unsigned int		max_lifespan;	/* Maximum lifespan to set if not 0 */
+	unsigned int		max_lifespan;	/* Maximum lifespan in secs to set if not 0 */
 	unsigned		request_size;	/* size of request data */
 	unsigned		reply_max;	/* maximum size of reply */
 	unsigned		count2;		/* count used in unmarshalling */
diff --git a/fs/afs/rxrpc.c b/fs/afs/rxrpc.c
index 7817e2b860e5e..6862e3dde364b 100644
--- a/fs/afs/rxrpc.c
+++ b/fs/afs/rxrpc.c
@@ -334,7 +334,9 @@ void afs_make_call(struct afs_addr_cursor *ac, struct afs_call *call, gfp_t gfp)
 	/* create a call */
 	rxcall = rxrpc_kernel_begin_call(call->net->socket, srx, call->key,
 					 (unsigned long)call,
-					 tx_total_len, gfp,
+					 tx_total_len,
+					 call->max_lifespan,
+					 gfp,
 					 (call->async ?
 					  afs_wake_up_async_call :
 					  afs_wake_up_call_waiter),
@@ -349,10 +351,6 @@ void afs_make_call(struct afs_addr_cursor *ac, struct afs_call *call, gfp_t gfp)
 	}
 
 	call->rxcall = rxcall;
-
-	if (call->max_lifespan)
-		rxrpc_kernel_set_max_life(call->net->socket, rxcall,
-					  call->max_lifespan);
 	call->issue_time = ktime_get_real();
 
 	/* send the request */
diff --git a/include/net/af_rxrpc.h b/include/net/af_rxrpc.h
index ba717eac0229a..73644bd42a3f9 100644
--- a/include/net/af_rxrpc.h
+++ b/include/net/af_rxrpc.h
@@ -40,16 +40,17 @@ typedef void (*rxrpc_user_attach_call_t)(struct rxrpc_call *, unsigned long);
 void rxrpc_kernel_new_call_notification(struct socket *,
 					rxrpc_notify_new_call_t,
 					rxrpc_discard_new_call_t);
-struct rxrpc_call *rxrpc_kernel_begin_call(struct socket *,
-					   struct sockaddr_rxrpc *,
-					   struct key *,
-					   unsigned long,
-					   s64,
-					   gfp_t,
-					   rxrpc_notify_rx_t,
-					   bool,
-					   enum rxrpc_interruptibility,
-					   unsigned int);
+struct rxrpc_call *rxrpc_kernel_begin_call(struct socket *sock,
+					   struct sockaddr_rxrpc *srx,
+					   struct key *key,
+					   unsigned long user_call_ID,
+					   s64 tx_total_len,
+					   u32 hard_timeout,
+					   gfp_t gfp,
+					   rxrpc_notify_rx_t notify_rx,
+					   bool upgrade,
+					   enum rxrpc_interruptibility interruptibility,
+					   unsigned int debug_id);
 int rxrpc_kernel_send_data(struct socket *, struct rxrpc_call *,
 			   struct msghdr *, size_t,
 			   rxrpc_notify_end_tx_t);
diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index ebbd4a1c3f86e..de5bebc99a4b5 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -265,6 +265,7 @@ static int rxrpc_listen(struct socket *sock, int backlog)
  * @key: The security context to use (defaults to socket setting)
  * @user_call_ID: The ID to use
  * @tx_total_len: Total length of data to transmit during the call (or -1)
+ * @hard_timeout: The maximum lifespan of the call in sec
  * @gfp: The allocation constraints
  * @notify_rx: Where to send notifications instead of socket queue
  * @upgrade: Request service upgrade for call
@@ -283,6 +284,7 @@ struct rxrpc_call *rxrpc_kernel_begin_call(struct socket *sock,
 					   struct key *key,
 					   unsigned long user_call_ID,
 					   s64 tx_total_len,
+					   u32 hard_timeout,
 					   gfp_t gfp,
 					   rxrpc_notify_rx_t notify_rx,
 					   bool upgrade,
@@ -313,6 +315,7 @@ struct rxrpc_call *rxrpc_kernel_begin_call(struct socket *sock,
 	p.tx_total_len		= tx_total_len;
 	p.interruptibility	= interruptibility;
 	p.kernel		= true;
+	p.timeouts.hard		= hard_timeout;
 
 	memset(&cp, 0, sizeof(cp));
 	cp.local		= rx->local;
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 433060cade038..ed0ef2dbd592b 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -614,6 +614,7 @@ struct rxrpc_call {
 	unsigned long		expect_term_by;	/* When we expect call termination by */
 	u32			next_rx_timo;	/* Timeout for next Rx packet (jif) */
 	u32			next_req_timo;	/* Timeout for next Rx request packet (jif) */
+	u32			hard_timo;	/* Maximum lifetime or 0 (jif) */
 	struct timer_list	timer;		/* Combined event timer */
 	struct work_struct	destroyer;	/* In-process-context destroyer */
 	rxrpc_notify_rx_t	notify_rx;	/* kernel service Rx notification function */
diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
index 7ce562f6dc8d5..80ed67f4f3a7d 100644
--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -225,6 +225,13 @@ static struct rxrpc_call *rxrpc_alloc_client_call(struct rxrpc_sock *rx,
 	if (cp->exclusive)
 		__set_bit(RXRPC_CALL_EXCLUSIVE, &call->flags);
 
+	if (p->timeouts.normal)
+		call->next_rx_timo = min(msecs_to_jiffies(p->timeouts.normal), 1UL);
+	if (p->timeouts.idle)
+		call->next_req_timo = min(msecs_to_jiffies(p->timeouts.idle), 1UL);
+	if (p->timeouts.hard)
+		call->hard_timo = p->timeouts.hard * HZ;
+
 	ret = rxrpc_init_client_call_security(call);
 	if (ret < 0) {
 		rxrpc_prefail_call(call, RXRPC_CALL_LOCAL_ERROR, ret);
@@ -256,7 +263,7 @@ void rxrpc_start_call_timer(struct rxrpc_call *call)
 	call->keepalive_at = j;
 	call->expect_rx_by = j;
 	call->expect_req_by = j;
-	call->expect_term_by = j;
+	call->expect_term_by = j + call->hard_timo;
 	call->timer.expires = now;
 }
 
diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index c1b074c17b33e..8e0b94714e849 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -651,6 +651,7 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
 		if (IS_ERR(call))
 			return PTR_ERR(call);
 		/* ... and we have the call lock. */
+		p.call.nr_timeouts = 0;
 		ret = 0;
 		if (rxrpc_call_is_complete(call))
 			goto out_put_unlock;
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May 15 09:28:30 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 May 2023 18:28:30 +0200
Subject: [PATCH 5.15 033/134] rxrpc: Fix hard call timeout units
In-Reply-To: <20230515161702.887638251@linuxfoundation.org>
References: <20230515161702.887638251@linuxfoundation.org>
Message-ID: <20230515161704.200160555@linuxfoundation.org>

From: David Howells <dhowells at redhat.com>

[ Upstream commit 0d098d83c5d9e107b2df7f5e11f81492f56d2fe7 ]

The hard call timeout is specified in the RXRPC_SET_CALL_TIMEOUT cmsg in
seconds, so fix the point at which sendmsg() applies it to the call to
convert to jiffies from seconds, not milliseconds.

Fixes: a158bdd3247b ("rxrpc: Fix timeout of a call that hasn't yet been granted a channel")
Signed-off-by: David Howells <dhowells at redhat.com>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: netdev at vger.kernel.org
cc: linux-kernel at vger.kernel.org
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 net/rxrpc/sendmsg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index d4e4e94f4f987..71e40f91dd398 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -736,7 +736,7 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
 		fallthrough;
 	case 1:
 		if (p.call.timeouts.hard > 0) {
-			j = msecs_to_jiffies(p.call.timeouts.hard);
+			j = p.call.timeouts.hard * HZ;
 			now = jiffies;
 			j += now;
 			WRITE_ONCE(call->expect_term_by, j);
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May 15 09:29:28 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 May 2023 18:29:28 +0200
Subject: [PATCH 5.10 317/381] rxrpc: Fix hard call timeout units
In-Reply-To: <20230515161736.775969473@linuxfoundation.org>
References: <20230515161736.775969473@linuxfoundation.org>
Message-ID: <20230515161751.128690115@linuxfoundation.org>

From: David Howells <dhowells at redhat.com>

[ Upstream commit 0d098d83c5d9e107b2df7f5e11f81492f56d2fe7 ]

The hard call timeout is specified in the RXRPC_SET_CALL_TIMEOUT cmsg in
seconds, so fix the point at which sendmsg() applies it to the call to
convert to jiffies from seconds, not milliseconds.

Fixes: a158bdd3247b ("rxrpc: Fix timeout of a call that hasn't yet been granted a channel")
Signed-off-by: David Howells <dhowells at redhat.com>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: netdev at vger.kernel.org
cc: linux-kernel at vger.kernel.org
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 net/rxrpc/sendmsg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index a670553159abe..1882fea719035 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -753,7 +753,7 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
 		fallthrough;
 	case 1:
 		if (p.call.timeouts.hard > 0) {
-			j = msecs_to_jiffies(p.call.timeouts.hard);
+			j = p.call.timeouts.hard * HZ;
 			now = jiffies;
 			j += now;
 			WRITE_ONCE(call->expect_term_by, j);
-- 
2.39.2





From gregkh at linuxfoundation.org  Mon May 15 09:30:05 2023
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 May 2023 18:30:05 +0200
Subject: [PATCH 5.4 227/282] rxrpc: Fix hard call timeout units
In-Reply-To: <20230515161722.146344674@linuxfoundation.org>
References: <20230515161722.146344674@linuxfoundation.org>
Message-ID: <20230515161729.036198734@linuxfoundation.org>

From: David Howells <dhowells at redhat.com>

[ Upstream commit 0d098d83c5d9e107b2df7f5e11f81492f56d2fe7 ]

The hard call timeout is specified in the RXRPC_SET_CALL_TIMEOUT cmsg in
seconds, so fix the point at which sendmsg() applies it to the call to
convert to jiffies from seconds, not milliseconds.

Fixes: a158bdd3247b ("rxrpc: Fix timeout of a call that hasn't yet been granted a channel")
Signed-off-by: David Howells <dhowells at redhat.com>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: netdev at vger.kernel.org
cc: linux-kernel at vger.kernel.org
Signed-off-by: David S. Miller <davem at davemloft.net>
Signed-off-by: Sasha Levin <sashal at kernel.org>
---
 net/rxrpc/sendmsg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index 1cb90d32d553d..3439d14168e81 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -738,7 +738,7 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
 		/* Fall through */
 	case 1:
 		if (p.call.timeouts.hard > 0) {
-			j = msecs_to_jiffies(p.call.timeouts.hard);
+			j = p.call.timeouts.hard * HZ;
 			now = jiffies;
 			j += now;
 			WRITE_ONCE(call->expect_term_by, j);
-- 
2.39.2





From dwysocha at redhat.com  Tue May 16 12:29:09 2023
From: dwysocha at redhat.com (David Wysochanski)
Date: Tue, 16 May 2023 15:29:09 -0400
Subject: [Linux-cachefs] [PATCH v6 0/2] mm, netfs, fscache: Stop read
 optimisation when folio removed from pagecache
In-Reply-To: <20230216150701.3654894-1-dhowells@redhat.com>
References: <20230216150701.3654894-1-dhowells@redhat.com>
Message-ID: <CALF+zO=w2Gyz6JtzEoFgTVjH67-_CuTaK7e+2yoHEwXZ8bPx_A@mail.gmail.com>

On Thu, Feb 16, 2023 at 10:07?AM David Howells <dhowells at redhat.com> wrote:
>
> Hi Willy,
>
> Is this okay by you?  You said you wanted to look at the remaining uses of
> page_has_private(), of which there are then three after these patches, not
> counting folio_has_private():
>
>         arch/s390/kernel/uv.c:          if (page_has_private(page))
>         mm/khugepaged.c:                    1 + page_mapcount(page) + page_has_private(page)) {
>         mm/migrate_device.c:            extra += 1 + page_has_private(page);
>
> --
> I've split the folio_has_private()/filemap_release_folio() call pair
> merging into its own patch, separate from the actual bugfix and pulled out
> the folio_needs_release() function into mm/internal.h and made
> filemap_release_folio() use it.  I've also got rid of the bit clearances
> from the network filesystem evict_inode functions as they doesn't seem to
> be necessary.
>
> Note that the last vestiges of try_to_release_page() got swept away, so I
> rebased and dealt with that.  One comment remained, which is removed by the
> first patch.
>
> David
>
> Changes:
> ========
> ver #6)
>  - Drop the third patch which removes a duplicate check in vmscan().
>
> ver #5)
>  - Rebased on linus/master.  try_to_release_page() has now been entirely
>    replaced by filemap_release_folio(), barring one comment.
>  - Cleaned up some pairs in ext4.
>
> ver #4)
>  - Split has_private/release call pairs into own patch.
>  - Moved folio_needs_release() to mm/internal.h and removed open-coded
>    version from filemap_release_folio().
>  - Don't need to clear AS_RELEASE_ALWAYS in ->evict_inode().
>  - Added experimental patch to reduce shrink_folio_list().
>
> ver #3)
>  - Fixed mapping_clear_release_always() to use clear_bit() not set_bit().
>  - Moved a '&&' to the correct line.
>
> ver #2)
>  - Rewrote entirely according to Willy's suggestion[1].
>
> Link: https://lore.kernel.org/r/Yk9V/03wgdYi65Lb at casper.infradead.org/ [1]
> Link: https://lore.kernel.org/r/164928630577.457102.8519251179327601178.stgit at warthog.procyon.org.uk/ # v1
> Link: https://lore.kernel.org/r/166844174069.1124521.10890506360974169994.stgit at warthog.procyon.org.uk/ # v2
> Link: https://lore.kernel.org/r/166869495238.3720468.4878151409085146764.stgit at warthog.procyon.org.uk/ # v3
> Link: https://lore.kernel.org/r/1459152.1669208550 at warthog.procyon.org.uk/ # v3 also
> Link: https://lore.kernel.org/r/166924370539.1772793.13730698360771821317.stgit at warthog.procyon.org.uk/ # v4
> Link: https://lore.kernel.org/r/167172131368.2334525.8569808925687731937.stgit at warthog.procyon.org.uk/ # v5
> ---
> %(shortlog)s
> %(diffstat)s
>
> David Howells (2):
>   mm: Merge folio_has_private()/filemap_release_folio() call pairs
>   mm, netfs, fscache: Stop read optimisation when folio removed from
>     pagecache
>
>  fs/9p/cache.c           |  2 ++
>  fs/afs/internal.h       |  2 ++
>  fs/cachefiles/namei.c   |  2 ++
>  fs/ceph/cache.c         |  2 ++
>  fs/cifs/fscache.c       |  2 ++
>  fs/ext4/move_extent.c   | 12 ++++--------
>  fs/splice.c             |  3 +--
>  include/linux/pagemap.h | 16 ++++++++++++++++
>  mm/filemap.c            |  2 ++
>  mm/huge_memory.c        |  3 +--
>  mm/internal.h           | 11 +++++++++++
>  mm/khugepaged.c         |  3 +--
>  mm/memory-failure.c     |  8 +++-----
>  mm/migrate.c            |  3 +--
>  mm/truncate.c           |  6 ++----
>  mm/vmscan.c             |  8 ++++----
>  16 files changed, 56 insertions(+), 29 deletions(-)
>
> --
> Linux-cachefs mailing list
> Linux-cachefs at redhat.com
> https://listman.redhat.com/mailman/listinfo/linux-cachefs
>

Willy, and David,

Can this series move forward?
This just got mentioned again [1] after Chris tested the NFS netfs
patches that were merged in 6.4-rc1

[1] https://lore.kernel.org/linux-nfs/CAAmbk-f_U8CPcTQM866L572uUHdK4p5iWKnUQs4r8fkW=6RW9g at mail.gmail.com/



From patchwork-bot+netdevbpf at kernel.org  Tue May 16 20:38:02 2023
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Wed, 17 May 2023 03:38:02 +0000
Subject: [PATCH 6.3 022/246] rxrpc: Fix potential data race in
 rxrpc_wait_to_be_connected()
In-Reply-To: <20230515161723.275161336@linuxfoundation.org>
References: <20230515161723.275161336@linuxfoundation.org>
Message-ID: <168429468203.3680.17732082530948499467.git-patchwork-notify@kernel.org>

Hello:

This series was applied to bpf/bpf-next.git (master)
by Arnaldo Carvalho de Melo <acme at redhat.com>:

On Mon, 15 May 2023 18:23:54 +0200 you wrote:
> From: David Howells <dhowells at redhat.com>
> 
> [ Upstream commit 2b5fdc0f5caa505afe34d608e2eefadadf2ee67a ]
> 
> Inside the loop in rxrpc_wait_to_be_connected() it checks call->error to
> see if it should exit the loop without first checking the call state.  This
> is probably safe as if call->error is set, the call is dead anyway, but we
> should probably wait for the call state to have been set to completion
> first, lest it cause surprise on the way out.
> 
> [...]

Here is the summary with links:
  - [6.3,022/246] rxrpc: Fix potential data race in rxrpc_wait_to_be_connected()
    (no matching commit)
  - [6.3,051/246] rxrpc: Fix hard call timeout units
    (no matching commit)
  - [6.3,052/246] rxrpc: Make it so that a waiting process can be aborted
    (no matching commit)
  - [6.3,053/246] rxrpc: Fix timeout of a call that hasnt yet been granted a channel
    (no matching commit)
  - [6.3,100/246] perf lock contention: Fix compiler builtin detection
    https://git.kernel.org/bpf/bpf-next/c/17535a33a9c1

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From dhowells at redhat.com  Fri May 19 00:40:27 2023
From: dhowells at redhat.com (David Howells)
Date: Fri, 19 May 2023 08:40:27 +0100
Subject: [PATCH v20 12/32] afs: Provide a splice-read stub
In-Reply-To: <20230519074047.1739879-1-dhowells@redhat.com>
References: <20230519074047.1739879-1-dhowells@redhat.com>
Message-ID: <20230519074047.1739879-13-dhowells@redhat.com>

Provide a splice_read stub for AFS to call afs_validate() before going into
generic_file_splice_read() so that i_size can be brought as up to date as
possible.

Signed-off-by: David Howells <dhowells at redhat.com>
cc: Christoph Hellwig <hch at lst.de>
cc: Al Viro <viro at zeniv.linux.org.uk>
cc: Jens Axboe <axboe at kernel.dk>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: linux-afs at lists.infradead.org
cc: linux-fsdevel at vger.kernel.org
cc: linux-block at vger.kernel.org
cc: linux-mm at kvack.org
---
 fs/afs/file.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/fs/afs/file.c b/fs/afs/file.c
index 719b31374879..d8a6b09dadf7 100644
--- a/fs/afs/file.c
+++ b/fs/afs/file.c
@@ -25,6 +25,9 @@ static void afs_invalidate_folio(struct folio *folio, size_t offset,
 static bool afs_release_folio(struct folio *folio, gfp_t gfp_flags);
 
 static ssize_t afs_file_read_iter(struct kiocb *iocb, struct iov_iter *iter);
+static ssize_t afs_file_splice_read(struct file *in, loff_t *ppos,
+				    struct pipe_inode_info *pipe,
+				    size_t len, unsigned int flags);
 static void afs_vm_open(struct vm_area_struct *area);
 static void afs_vm_close(struct vm_area_struct *area);
 static vm_fault_t afs_vm_map_pages(struct vm_fault *vmf, pgoff_t start_pgoff, pgoff_t end_pgoff);
@@ -36,7 +39,7 @@ const struct file_operations afs_file_operations = {
 	.read_iter	= afs_file_read_iter,
 	.write_iter	= afs_file_write,
 	.mmap		= afs_file_mmap,
-	.splice_read	= generic_file_splice_read,
+	.splice_read	= afs_file_splice_read,
 	.splice_write	= iter_file_splice_write,
 	.fsync		= afs_fsync,
 	.lock		= afs_lock,
@@ -587,3 +590,18 @@ static ssize_t afs_file_read_iter(struct kiocb *iocb, struct iov_iter *iter)
 
 	return generic_file_read_iter(iocb, iter);
 }
+
+static ssize_t afs_file_splice_read(struct file *in, loff_t *ppos,
+				    struct pipe_inode_info *pipe,
+				    size_t len, unsigned int flags)
+{
+	struct afs_vnode *vnode = AFS_FS_I(file_inode(in));
+	struct afs_file *af = in->private_data;
+	int ret;
+
+	ret = afs_validate(vnode, af->key);
+	if (ret < 0)
+		return ret;
+
+	return generic_file_splice_read(in, ppos, pipe, len, flags);
+}



From dhowells at redhat.com  Fri May 19 17:00:34 2023
From: dhowells at redhat.com (David Howells)
Date: Sat, 20 May 2023 01:00:34 +0100
Subject: [PATCH v21 15/30] afs: Provide a splice-read stub
In-Reply-To: <20230520000049.2226926-1-dhowells@redhat.com>
References: <20230520000049.2226926-1-dhowells@redhat.com>
Message-ID: <20230520000049.2226926-16-dhowells@redhat.com>

Provide a splice_read stub for AFS to call afs_validate() before going into
generic_file_splice_read() so that we're likely to have a callback promise
from the server.

Signed-off-by: David Howells <dhowells at redhat.com>
cc: Christoph Hellwig <hch at lst.de>
cc: Al Viro <viro at zeniv.linux.org.uk>
cc: Jens Axboe <axboe at kernel.dk>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: linux-afs at lists.infradead.org
cc: linux-fsdevel at vger.kernel.org
cc: linux-block at vger.kernel.org
cc: linux-mm at kvack.org
---
 fs/afs/file.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/fs/afs/file.c b/fs/afs/file.c
index 719b31374879..d8a6b09dadf7 100644
--- a/fs/afs/file.c
+++ b/fs/afs/file.c
@@ -25,6 +25,9 @@ static void afs_invalidate_folio(struct folio *folio, size_t offset,
 static bool afs_release_folio(struct folio *folio, gfp_t gfp_flags);
 
 static ssize_t afs_file_read_iter(struct kiocb *iocb, struct iov_iter *iter);
+static ssize_t afs_file_splice_read(struct file *in, loff_t *ppos,
+				    struct pipe_inode_info *pipe,
+				    size_t len, unsigned int flags);
 static void afs_vm_open(struct vm_area_struct *area);
 static void afs_vm_close(struct vm_area_struct *area);
 static vm_fault_t afs_vm_map_pages(struct vm_fault *vmf, pgoff_t start_pgoff, pgoff_t end_pgoff);
@@ -36,7 +39,7 @@ const struct file_operations afs_file_operations = {
 	.read_iter	= afs_file_read_iter,
 	.write_iter	= afs_file_write,
 	.mmap		= afs_file_mmap,
-	.splice_read	= generic_file_splice_read,
+	.splice_read	= afs_file_splice_read,
 	.splice_write	= iter_file_splice_write,
 	.fsync		= afs_fsync,
 	.lock		= afs_lock,
@@ -587,3 +590,18 @@ static ssize_t afs_file_read_iter(struct kiocb *iocb, struct iov_iter *iter)
 
 	return generic_file_read_iter(iocb, iter);
 }
+
+static ssize_t afs_file_splice_read(struct file *in, loff_t *ppos,
+				    struct pipe_inode_info *pipe,
+				    size_t len, unsigned int flags)
+{
+	struct afs_vnode *vnode = AFS_FS_I(file_inode(in));
+	struct afs_file *af = in->private_data;
+	int ret;
+
+	ret = afs_validate(vnode, af->key);
+	if (ret < 0)
+		return ret;
+
+	return generic_file_splice_read(in, ppos, pipe, len, flags);
+}



From dhowells at redhat.com  Mon May 22 06:50:02 2023
From: dhowells at redhat.com (David Howells)
Date: Mon, 22 May 2023 14:50:02 +0100
Subject: [PATCH v22 15/31] afs: Provide a splice-read wrapper
In-Reply-To: <20230522135018.2742245-1-dhowells@redhat.com>
References: <20230522135018.2742245-1-dhowells@redhat.com>
Message-ID: <20230522135018.2742245-16-dhowells@redhat.com>

Provide a splice_read wrapper for AFS to call afs_validate() before going
into generic_file_splice_read() so that we're likely to have a callback
promise from the server.

Signed-off-by: David Howells <dhowells at redhat.com>
cc: Christoph Hellwig <hch at lst.de>
cc: Al Viro <viro at zeniv.linux.org.uk>
cc: Jens Axboe <axboe at kernel.dk>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: linux-afs at lists.infradead.org
cc: linux-fsdevel at vger.kernel.org
cc: linux-block at vger.kernel.org
cc: linux-mm at kvack.org
---
 fs/afs/file.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/fs/afs/file.c b/fs/afs/file.c
index 719b31374879..d8a6b09dadf7 100644
--- a/fs/afs/file.c
+++ b/fs/afs/file.c
@@ -25,6 +25,9 @@ static void afs_invalidate_folio(struct folio *folio, size_t offset,
 static bool afs_release_folio(struct folio *folio, gfp_t gfp_flags);
 
 static ssize_t afs_file_read_iter(struct kiocb *iocb, struct iov_iter *iter);
+static ssize_t afs_file_splice_read(struct file *in, loff_t *ppos,
+				    struct pipe_inode_info *pipe,
+				    size_t len, unsigned int flags);
 static void afs_vm_open(struct vm_area_struct *area);
 static void afs_vm_close(struct vm_area_struct *area);
 static vm_fault_t afs_vm_map_pages(struct vm_fault *vmf, pgoff_t start_pgoff, pgoff_t end_pgoff);
@@ -36,7 +39,7 @@ const struct file_operations afs_file_operations = {
 	.read_iter	= afs_file_read_iter,
 	.write_iter	= afs_file_write,
 	.mmap		= afs_file_mmap,
-	.splice_read	= generic_file_splice_read,
+	.splice_read	= afs_file_splice_read,
 	.splice_write	= iter_file_splice_write,
 	.fsync		= afs_fsync,
 	.lock		= afs_lock,
@@ -587,3 +590,18 @@ static ssize_t afs_file_read_iter(struct kiocb *iocb, struct iov_iter *iter)
 
 	return generic_file_read_iter(iocb, iter);
 }
+
+static ssize_t afs_file_splice_read(struct file *in, loff_t *ppos,
+				    struct pipe_inode_info *pipe,
+				    size_t len, unsigned int flags)
+{
+	struct afs_vnode *vnode = AFS_FS_I(file_inode(in));
+	struct afs_file *af = in->private_data;
+	int ret;
+
+	ret = afs_validate(vnode, af->key);
+	if (ret < 0)
+		return ret;
+
+	return generic_file_splice_read(in, ppos, pipe, len, flags);
+}



From Kenny.Ho at amd.com  Tue May 23 15:39:44 2023
From: Kenny.Ho at amd.com (Kenny Ho)
Date: Tue, 23 May 2023 18:39:44 -0400
Subject: [PATCH] Remove hardcoded static string length
Message-ID: <20230523223944.691076-1-Kenny.Ho@amd.com>

UTS_RELEASE length can exceed the hardcoded length.  This is causing
compile error when WERROR is turned on.

Signed-off-by: Kenny Ho <Kenny.Ho at amd.com>
---
 net/rxrpc/local_event.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rxrpc/local_event.c b/net/rxrpc/local_event.c
index 19e929c7c38b..61d53ee10784 100644
--- a/net/rxrpc/local_event.c
+++ b/net/rxrpc/local_event.c
@@ -16,7 +16,7 @@
 #include <generated/utsrelease.h>
 #include "ar-internal.h"
 
-static const char rxrpc_version_string[65] = "linux-" UTS_RELEASE " AF_RXRPC";
+static const char rxrpc_version_string[] = "linux-" UTS_RELEASE " AF_RXRPC";
 
 /*
  * Reply to a version request
-- 
2.25.1



From andrew at lunn.ch  Tue May 23 17:49:26 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 24 May 2023 02:49:26 +0200
Subject: [PATCH] Remove hardcoded static string length
In-Reply-To: <20230523223944.691076-1-Kenny.Ho@amd.com>
References: <20230523223944.691076-1-Kenny.Ho@amd.com>
Message-ID: <01936d68-85d3-4d20-9beb-27ff9f62d826@lunn.ch>

On Tue, May 23, 2023 at 06:39:44PM -0400, Kenny Ho wrote:
> UTS_RELEASE length can exceed the hardcoded length.  This is causing
> compile error when WERROR is turned on.
> 
> Signed-off-by: Kenny Ho <Kenny.Ho at amd.com>
> ---
>  net/rxrpc/local_event.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/rxrpc/local_event.c b/net/rxrpc/local_event.c
> index 19e929c7c38b..61d53ee10784 100644
> --- a/net/rxrpc/local_event.c
> +++ b/net/rxrpc/local_event.c
> @@ -16,7 +16,7 @@
>  #include <generated/utsrelease.h>
>  #include "ar-internal.h"
>  
> -static const char rxrpc_version_string[65] = "linux-" UTS_RELEASE " AF_RXRPC";
> +static const char rxrpc_version_string[] = "linux-" UTS_RELEASE " AF_RXRPC";

This is not an area of the network stack i know about, so please
excuse what might be a dumb question.

How is the protocol defined here? Is there an RFC or some other sort
of standard?

A message is being built and sent over a socket. The size of that
message was fixed, at 65 + sizeof(whdr). Now the message is variable
length. Does the protocol specification actually allow this?

	Andrew


From Tracy.DiMarcoWhite at gs.com  Tue May 23 22:00:19 2023
From: Tracy.DiMarcoWhite at gs.com (Di Marco White, Tracy J)
Date: Wed, 24 May 2023 05:00:19 +0000
Subject: 2023 AFS Technologies Workshop - virtual
Message-ID: <DM6PR19MB3579869D6A119D1C3218DE4591419@DM6PR19MB3579.namprd19.prod.outlook.com>

Hi all,

I'd like to invite anyone interested in AFS to consider registering for the 2023 AFS Technologies Workshop on June 12th, 13th, & 14th. The workshop is again this year being hosted on Zoom, and registration is open at https://events.zoom.us/e/view/vqOro4A_RfGeHNSVWD4Yvw with the list of talks and timings listed there as well. I will work to also have the schedule on the workshop website as soon as I can. The main talks will run from 9:30am until 3pm Eastern time, with themed community discussion or social time for an hour before the start each day, and an hour after the talks end each day..

If you have any questions, please let us know.

Tracy Di Marco White
On behaf of the 2023 Workshop organizers


________________________________

Your Personal Data: We may collect and process information about you that may be subject to data protection laws. For more information about how we use and disclose your personal data, how we protect your information, our legal basis to use your information, your rights and who you can contact, please refer to: www.gs.com/privacy-notices<http://www.gs.com/privacy-notices>


From marc.dionne at auristor.com  Wed May 24 08:43:18 2023
From: marc.dionne at auristor.com (Marc Dionne)
Date: Wed, 24 May 2023 12:43:18 -0300
Subject: [PATCH] Remove hardcoded static string length
In-Reply-To: <01936d68-85d3-4d20-9beb-27ff9f62d826@lunn.ch>
References: <20230523223944.691076-1-Kenny.Ho@amd.com> <01936d68-85d3-4d20-9beb-27ff9f62d826@lunn.ch>
Message-ID: <CAB9dFdt4-cBFhEqsTXk9suE+Bw-xcpM0n3Q6rFmBaa+8A5uMWQ@mail.gmail.com>

On Tue, May 23, 2023 at 9:50?PM Andrew Lunn <andrew at lunn.ch> wrote:
>
> On Tue, May 23, 2023 at 06:39:44PM -0400, Kenny Ho wrote:
> > UTS_RELEASE length can exceed the hardcoded length.  This is causing
> > compile error when WERROR is turned on.
> >
> > Signed-off-by: Kenny Ho <Kenny.Ho at amd.com>
> > ---
> >  net/rxrpc/local_event.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/rxrpc/local_event.c b/net/rxrpc/local_event.c
> > index 19e929c7c38b..61d53ee10784 100644
> > --- a/net/rxrpc/local_event.c
> > +++ b/net/rxrpc/local_event.c
> > @@ -16,7 +16,7 @@
> >  #include <generated/utsrelease.h>
> >  #include "ar-internal.h"
> >
> > -static const char rxrpc_version_string[65] = "linux-" UTS_RELEASE " AF_RXRPC";
> > +static const char rxrpc_version_string[] = "linux-" UTS_RELEASE " AF_RXRPC";
>
> This is not an area of the network stack i know about, so please
> excuse what might be a dumb question.
>
> How is the protocol defined here? Is there an RFC or some other sort
> of standard?
>
> A message is being built and sent over a socket. The size of that
> message was fixed, at 65 + sizeof(whdr). Now the message is variable
> length. Does the protocol specification actually allow this?
>
>         Andrew

I don't think there is an RFC describing RX, but the closest thing to
a spec (https://web.mit.edu/kolya/afs/rx/rx-spec) states:

"If a server receives a packet with a type value of 13, and the
client-initiated flag set, it should respond with a 65-byte payload
containing a string that identifies the version of AFS software it is
running."

So while it may not actually cause any issues (the few things that
look at the data just truncate past 65), it's probably best to keep
the response at a fixed 65 bytes.

Marc


From andrew at lunn.ch  Wed May 24 09:01:42 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 24 May 2023 18:01:42 +0200
Subject: [PATCH] Remove hardcoded static string length
In-Reply-To: <CAB9dFdt4-cBFhEqsTXk9suE+Bw-xcpM0n3Q6rFmBaa+8A5uMWQ@mail.gmail.com>
References: <20230523223944.691076-1-Kenny.Ho@amd.com>
 <01936d68-85d3-4d20-9beb-27ff9f62d826@lunn.ch>
 <CAB9dFdt4-cBFhEqsTXk9suE+Bw-xcpM0n3Q6rFmBaa+8A5uMWQ@mail.gmail.com>
Message-ID: <c0fda91b-1e98-420f-a18a-16bbed25e98d@lunn.ch>

> I don't think there is an RFC describing RX, but the closest thing to
> a spec (https://web.mit.edu/kolya/afs/rx/rx-spec) states:
> 
> "If a server receives a packet with a type value of 13, and the
> client-initiated flag set, it should respond with a 65-byte payload
> containing a string that identifies the version of AFS software it is
> running."
> 
> So while it may not actually cause any issues (the few things that
> look at the data just truncate past 65), it's probably best to keep
> the response at a fixed 65 bytes.

Thanks for the link and the quote.

So the compiler warning/error needs to be fixed a different want.

    Andrew

---
pw-bot: cr


From dwysocha at redhat.com  Wed May 24 09:38:21 2023
From: dwysocha at redhat.com (David Wysochanski)
Date: Wed, 24 May 2023 12:38:21 -0400
Subject: [Linux-cachefs] [PATCH v6 0/2] mm, netfs, fscache: Stop read
 optimisation when folio removed from pagecache
In-Reply-To: <CALF+zO=w2Gyz6JtzEoFgTVjH67-_CuTaK7e+2yoHEwXZ8bPx_A@mail.gmail.com>
References: <20230216150701.3654894-1-dhowells@redhat.com> <CALF+zO=w2Gyz6JtzEoFgTVjH67-_CuTaK7e+2yoHEwXZ8bPx_A@mail.gmail.com>
Message-ID: <CALF+zO=Y8dMsJ79RYp1e7n9B5_0=segpqW9_tetBqPhFiQcZxA@mail.gmail.com>

On Tue, May 16, 2023 at 3:29?PM David Wysochanski <dwysocha at redhat.com> wrote:
>
> On Thu, Feb 16, 2023 at 10:07?AM David Howells <dhowells at redhat.com> wrote:
> >
> > Hi Willy,
> >
> > Is this okay by you?  You said you wanted to look at the remaining uses of
> > page_has_private(), of which there are then three after these patches, not
> > counting folio_has_private():
> >
> >         arch/s390/kernel/uv.c:          if (page_has_private(page))
> >         mm/khugepaged.c:                    1 + page_mapcount(page) + page_has_private(page)) {
> >         mm/migrate_device.c:            extra += 1 + page_has_private(page);
> >
> > --
> > I've split the folio_has_private()/filemap_release_folio() call pair
> > merging into its own patch, separate from the actual bugfix and pulled out
> > the folio_needs_release() function into mm/internal.h and made
> > filemap_release_folio() use it.  I've also got rid of the bit clearances
> > from the network filesystem evict_inode functions as they doesn't seem to
> > be necessary.
> >
> > Note that the last vestiges of try_to_release_page() got swept away, so I
> > rebased and dealt with that.  One comment remained, which is removed by the
> > first patch.
> >
> > David
> >
> > Changes:
> > ========
> > ver #6)
> >  - Drop the third patch which removes a duplicate check in vmscan().
> >
> > ver #5)
> >  - Rebased on linus/master.  try_to_release_page() has now been entirely
> >    replaced by filemap_release_folio(), barring one comment.
> >  - Cleaned up some pairs in ext4.
> >
> > ver #4)
> >  - Split has_private/release call pairs into own patch.
> >  - Moved folio_needs_release() to mm/internal.h and removed open-coded
> >    version from filemap_release_folio().
> >  - Don't need to clear AS_RELEASE_ALWAYS in ->evict_inode().
> >  - Added experimental patch to reduce shrink_folio_list().
> >
> > ver #3)
> >  - Fixed mapping_clear_release_always() to use clear_bit() not set_bit().
> >  - Moved a '&&' to the correct line.
> >
> > ver #2)
> >  - Rewrote entirely according to Willy's suggestion[1].
> >
> > Link: https://lore.kernel.org/r/Yk9V/03wgdYi65Lb at casper.infradead.org/ [1]
> > Link: https://lore.kernel.org/r/164928630577.457102.8519251179327601178.stgit at warthog.procyon.org.uk/ # v1
> > Link: https://lore.kernel.org/r/166844174069.1124521.10890506360974169994.stgit at warthog.procyon.org.uk/ # v2
> > Link: https://lore.kernel.org/r/166869495238.3720468.4878151409085146764.stgit at warthog.procyon.org.uk/ # v3
> > Link: https://lore.kernel.org/r/1459152.1669208550 at warthog.procyon.org.uk/ # v3 also
> > Link: https://lore.kernel.org/r/166924370539.1772793.13730698360771821317.stgit at warthog.procyon.org.uk/ # v4
> > Link: https://lore.kernel.org/r/167172131368.2334525.8569808925687731937.stgit at warthog.procyon.org.uk/ # v5
> > ---
> > %(shortlog)s
> > %(diffstat)s
> >
> > David Howells (2):
> >   mm: Merge folio_has_private()/filemap_release_folio() call pairs
> >   mm, netfs, fscache: Stop read optimisation when folio removed from
> >     pagecache
> >
> >  fs/9p/cache.c           |  2 ++
> >  fs/afs/internal.h       |  2 ++
> >  fs/cachefiles/namei.c   |  2 ++
> >  fs/ceph/cache.c         |  2 ++
> >  fs/cifs/fscache.c       |  2 ++
> >  fs/ext4/move_extent.c   | 12 ++++--------
> >  fs/splice.c             |  3 +--
> >  include/linux/pagemap.h | 16 ++++++++++++++++
> >  mm/filemap.c            |  2 ++
> >  mm/huge_memory.c        |  3 +--
> >  mm/internal.h           | 11 +++++++++++
> >  mm/khugepaged.c         |  3 +--
> >  mm/memory-failure.c     |  8 +++-----
> >  mm/migrate.c            |  3 +--
> >  mm/truncate.c           |  6 ++----
> >  mm/vmscan.c             |  8 ++++----
> >  16 files changed, 56 insertions(+), 29 deletions(-)
> >
> > --
> > Linux-cachefs mailing list
> > Linux-cachefs at redhat.com
> > https://listman.redhat.com/mailman/listinfo/linux-cachefs
> >
>
> Willy, and David,
>
> Can this series move forward?
> This just got mentioned again [1] after Chris tested the NFS netfs
> patches that were merged in 6.4-rc1
>
> [1] https://lore.kernel.org/linux-nfs/CAAmbk-f_U8CPcTQM866L572uUHdK4p5iWKnUQs4r8fkW=6RW9g at mail.gmail.com/

Sorry about the timing on the original email as I forgot it lined up
with LSF/MM.

FYI, I tested with 6.4-rc1 plus these two patches, then I added the NFS
hunk needed (see below).  All my tests pass now[1], and it makes sense
from all the ftraces I've seen on test runs that fail (cachefiles_prep_read
trace event would show "DOWN no-data" even after data was written
previously).

This small NFS hunk needs added to patch #2 in this series:

diff --git a/fs/nfs/fscache.c b/fs/nfs/fscache.c
index 8c35d88a84b1..d4a20748b14f 100644
--- a/fs/nfs/fscache.c
+++ b/fs/nfs/fscache.c
@@ -180,6 +180,10 @@ void nfs_fscache_init_inode(struct inode *inode)
                                               &auxdata,      /* aux_data */
                                               sizeof(auxdata),
                                               i_size_read(inode));
+
+       if (netfs_inode(inode)->cache)
+               mapping_set_release_always(inode->i_mapping);
+
 }

 /*

[1] https://lore.kernel.org/linux-nfs/CALF+zOn_qX4tcT2ucq4jD3G-1ERqZkL6Cw7hx75OnQF0ivqSeA at mail.gmail.com/



From y2kenny at gmail.com  Wed May 24 10:02:36 2023
From: y2kenny at gmail.com (Kenny Ho)
Date: Wed, 24 May 2023 13:02:36 -0400
Subject: [PATCH] Remove hardcoded static string length
In-Reply-To: <c0fda91b-1e98-420f-a18a-16bbed25e98d@lunn.ch>
References: <20230523223944.691076-1-Kenny.Ho@amd.com> <01936d68-85d3-4d20-9beb-27ff9f62d826@lunn.ch>
 <CAB9dFdt4-cBFhEqsTXk9suE+Bw-xcpM0n3Q6rFmBaa+8A5uMWQ@mail.gmail.com> <c0fda91b-1e98-420f-a18a-16bbed25e98d@lunn.ch>
Message-ID: <CAOWid-erNGD24Ouf4fAJJBqm69QVoHOpNt0E-G+Wt=nq1W4oBQ@mail.gmail.com>

On Wed, May 24, 2023 at 12:02?PM Andrew Lunn <andrew at lunn.ch> wrote:
> So the compiler warning/error needs to be fixed a different want.

Understood.  Would caping the length at iov_len with a ternary be sufficient?

Regards,
Kenny


From andrew at lunn.ch  Wed May 24 10:43:11 2023
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 24 May 2023 19:43:11 +0200
Subject: [PATCH] Remove hardcoded static string length
In-Reply-To: <CAOWid-erNGD24Ouf4fAJJBqm69QVoHOpNt0E-G+Wt=nq1W4oBQ@mail.gmail.com>
References: <20230523223944.691076-1-Kenny.Ho@amd.com>
 <01936d68-85d3-4d20-9beb-27ff9f62d826@lunn.ch>
 <CAB9dFdt4-cBFhEqsTXk9suE+Bw-xcpM0n3Q6rFmBaa+8A5uMWQ@mail.gmail.com>
 <c0fda91b-1e98-420f-a18a-16bbed25e98d@lunn.ch>
 <CAOWid-erNGD24Ouf4fAJJBqm69QVoHOpNt0E-G+Wt=nq1W4oBQ@mail.gmail.com>
Message-ID: <5b1355b8-17f7-49c8-b7b5-3d9ecdb146ce@lunn.ch>

On Wed, May 24, 2023 at 01:02:36PM -0400, Kenny Ho wrote:
> On Wed, May 24, 2023 at 12:02?PM Andrew Lunn <andrew at lunn.ch> wrote:
> > So the compiler warning/error needs to be fixed a different want.
> 
> Understood.  Would caping the length at iov_len with a ternary be sufficient?

The quoted text said 'string'. It is not clear if that means c-string,
with a trailing \0. If you just cap iov_len you could end up with a
string which is not terminated.

The other end of the socket should not blow up, because that would be
an obvious DOS or buffer overwrite attack vector. So you need to
decide, do you want to expose such issues and see if anything does
actually blow up, or do you want to do a bit more work and correctly
terminate the string when capped?

	Andrew


From y2kenny at gmail.com  Wed May 24 11:01:17 2023
From: y2kenny at gmail.com (Kenny Ho)
Date: Wed, 24 May 2023 14:01:17 -0400
Subject: [PATCH] Remove hardcoded static string length
In-Reply-To: <5b1355b8-17f7-49c8-b7b5-3d9ecdb146ce@lunn.ch>
References: <20230523223944.691076-1-Kenny.Ho@amd.com> <01936d68-85d3-4d20-9beb-27ff9f62d826@lunn.ch>
 <CAB9dFdt4-cBFhEqsTXk9suE+Bw-xcpM0n3Q6rFmBaa+8A5uMWQ@mail.gmail.com>
 <c0fda91b-1e98-420f-a18a-16bbed25e98d@lunn.ch> <CAOWid-erNGD24Ouf4fAJJBqm69QVoHOpNt0E-G+Wt=nq1W4oBQ@mail.gmail.com>
 <5b1355b8-17f7-49c8-b7b5-3d9ecdb146ce@lunn.ch>
Message-ID: <CAOWid-dYtkcKuNxoOyf3yqSJ7OtcNjaqJLVX1QhRUhYSOO6vHA@mail.gmail.com>

On Wed, May 24, 2023 at 1:43?PM Andrew Lunn <andrew at lunn.ch> wrote:
>
> The other end of the socket should not blow up, because that would be
> an obvious DOS or buffer overwrite attack vector. So you need to
> decide, do you want to expose such issues and see if anything does
> actually blow up, or do you want to do a bit more work and correctly
> terminate the string when capped?

Right... I guess it's not clear to me that existing implementations
null-terminate correctly when UTS_RELEASE causes the string to exceed
the 65 byte size of rxrpc_version_string.  We can of course do better,
but I hesitate to do strncpy because I am not familiar with this code
base enough to tell if this function is part of some hot path where
strncpy matters.

Regards,
Kenny


From David.Laight at ACULAB.COM  Thu May 25 02:14:53 2023
From: David.Laight at ACULAB.COM (David Laight)
Date: Thu, 25 May 2023 09:14:53 +0000
Subject: [PATCH] Remove hardcoded static string length
In-Reply-To: <CAOWid-dYtkcKuNxoOyf3yqSJ7OtcNjaqJLVX1QhRUhYSOO6vHA@mail.gmail.com>
References: <20230523223944.691076-1-Kenny.Ho@amd.com>
 <01936d68-85d3-4d20-9beb-27ff9f62d826@lunn.ch>
 <CAB9dFdt4-cBFhEqsTXk9suE+Bw-xcpM0n3Q6rFmBaa+8A5uMWQ@mail.gmail.com>
 <c0fda91b-1e98-420f-a18a-16bbed25e98d@lunn.ch>
 <CAOWid-erNGD24Ouf4fAJJBqm69QVoHOpNt0E-G+Wt=nq1W4oBQ@mail.gmail.com>
 <5b1355b8-17f7-49c8-b7b5-3d9ecdb146ce@lunn.ch>
 <CAOWid-dYtkcKuNxoOyf3yqSJ7OtcNjaqJLVX1QhRUhYSOO6vHA@mail.gmail.com>
Message-ID: <30d65ea9170d4f60bd76ed516541cb46@AcuMS.aculab.com>

From: Kenny Ho
> Sent: 24 May 2023 19:01
> 
> On Wed, May 24, 2023 at 1:43?PM Andrew Lunn <andrew at lunn.ch> wrote:
> >
> > The other end of the socket should not blow up, because that would be
> > an obvious DOS or buffer overwrite attack vector. So you need to
> > decide, do you want to expose such issues and see if anything does
> > actually blow up, or do you want to do a bit more work and correctly
> > terminate the string when capped?
> 
> Right... I guess it's not clear to me that existing implementations
> null-terminate correctly when UTS_RELEASE causes the string to exceed
> the 65 byte size of rxrpc_version_string.  We can of course do better,
> but I hesitate to do strncpy because I am not familiar with this code
> base enough to tell if this function is part of some hot path where
> strncpy matters.

The whole thing looks like it is expecting a max of 64 characters
and a terminating '\0'.
Since UTE_RELEASE goes in between two fixed strings truncating
the whole thing to 64/65 chars/bytes doesn't seem ideal.

I does rather beg the question as what is in UTS_RELEASE when
it exceeds (IIRC) about 48 characters?

If UTS_RELEASE is getting that long, it might easily exceed
the 64 characters returned by uname().

I suspect that you need to truncate UTS_RELEASE to limit
the string to 64 characters - so something like:
	static char id[65];
	if (!id[0])
		snprintf(id, sizeof id, "xxx-%.48s-yyy", UTS_RELEASE);

Using an on-stack buffer almost certainly wouldn't matter.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

From y2kenny at gmail.com  Thu May 25 07:27:53 2023
From: y2kenny at gmail.com (Kenny Ho)
Date: Thu, 25 May 2023 10:27:53 -0400
Subject: [PATCH] Remove hardcoded static string length
In-Reply-To: <30d65ea9170d4f60bd76ed516541cb46@AcuMS.aculab.com>
References: <20230523223944.691076-1-Kenny.Ho@amd.com> <01936d68-85d3-4d20-9beb-27ff9f62d826@lunn.ch>
 <CAB9dFdt4-cBFhEqsTXk9suE+Bw-xcpM0n3Q6rFmBaa+8A5uMWQ@mail.gmail.com>
 <c0fda91b-1e98-420f-a18a-16bbed25e98d@lunn.ch> <CAOWid-erNGD24Ouf4fAJJBqm69QVoHOpNt0E-G+Wt=nq1W4oBQ@mail.gmail.com>
 <5b1355b8-17f7-49c8-b7b5-3d9ecdb146ce@lunn.ch> <CAOWid-dYtkcKuNxoOyf3yqSJ7OtcNjaqJLVX1QhRUhYSOO6vHA@mail.gmail.com>
 <30d65ea9170d4f60bd76ed516541cb46@AcuMS.aculab.com>
Message-ID: <CAOWid-eEbeeU9mOpwgOatt5rHQhRt+xPrsQ1fsMemVZDdeN=MQ@mail.gmail.com>

On Thu, May 25, 2023 at 5:14?AM David Laight <David.Laight at aculab.com> wrote:
>
> I does rather beg the question as what is in UTS_RELEASE when
> it exceeds (IIRC) about 48 characters?

Thanks for the question as it made me dig deeper.  UTS_RELEASE is
actually capped at 64:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Makefile?#n1317
"""
uts_len := 64
define filechk_utsrelease.h
if [ `echo -n "$(KERNELRELEASE)" | wc -c ` -gt $(uts_len) ]; then \
 echo '"$(KERNELRELEASE)" exceeds $(uts_len) characters' >&2;    \
 exit 1;                                                         \
...
"""

So UTS_RELEASE on its own would fit perfectly by coincidence (and it
is also why UTS_RELEASE with the pre and postfix exceeds the limit.)
That makes me wonder if the content / format of the version matter and
looks like it sort of does by looking at when the string was
introduced:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net/rxrpc/local_object.c?id=44ba06987c0b10faa998b9324850e8a6564c714d

"The standard formulation seems to be: <project> <version> built
<yyyy>-<mm>-<dd>"

That commit also confirms the size and null termination requirement.

I will create a separate patch with your suggestion.

Regards,
Kenny


From David.Laight at ACULAB.COM  Thu May 25 08:04:33 2023
From: David.Laight at ACULAB.COM (David Laight)
Date: Thu, 25 May 2023 15:04:33 +0000
Subject: [PATCH] Remove hardcoded static string length
In-Reply-To: <CAOWid-eEbeeU9mOpwgOatt5rHQhRt+xPrsQ1fsMemVZDdeN=MQ@mail.gmail.com>
References: <20230523223944.691076-1-Kenny.Ho@amd.com>
 <01936d68-85d3-4d20-9beb-27ff9f62d826@lunn.ch>
 <CAB9dFdt4-cBFhEqsTXk9suE+Bw-xcpM0n3Q6rFmBaa+8A5uMWQ@mail.gmail.com>
 <c0fda91b-1e98-420f-a18a-16bbed25e98d@lunn.ch>
 <CAOWid-erNGD24Ouf4fAJJBqm69QVoHOpNt0E-G+Wt=nq1W4oBQ@mail.gmail.com>
 <5b1355b8-17f7-49c8-b7b5-3d9ecdb146ce@lunn.ch>
 <CAOWid-dYtkcKuNxoOyf3yqSJ7OtcNjaqJLVX1QhRUhYSOO6vHA@mail.gmail.com>
 <30d65ea9170d4f60bd76ed516541cb46@AcuMS.aculab.com>
 <CAOWid-eEbeeU9mOpwgOatt5rHQhRt+xPrsQ1fsMemVZDdeN=MQ@mail.gmail.com>
Message-ID: <81d01562a59a4fb49cd4681ebcf2e74a@AcuMS.aculab.com>

From: Kenny Ho
> Sent: 25 May 2023 15:28
> To: David Laight <David.Laight at ACULAB.COM>
> Cc: Andrew Lunn <andrew at lunn.ch>; Marc Dionne <marc.dionne at auristor.com>; Kenny Ho <Kenny.Ho at amd.com>;
> David Howells <dhowells at redhat.com>; David S. Miller <davem at davemloft.net>; Eric Dumazet
> <edumazet at google.com>; Jakub Kicinski <kuba at kernel.org>; Paolo Abeni <pabeni at redhat.com>; linux-
> afs at lists.infradead.org; netdev at vger.kernel.org; linux-kernel at vger.kernel.org
> Subject: Re: [PATCH] Remove hardcoded static string length
> 
> On Thu, May 25, 2023 at 5:14?AM David Laight <David.Laight at aculab.com> wrote:
> >
> > I does rather beg the question as what is in UTS_RELEASE when
> > it exceeds (IIRC) about 48 characters?
> 
> Thanks for the question as it made me dig deeper.  UTS_RELEASE is
> actually capped at 64:
...

But isn't UTS_RELEASE usually much shorter?
I think it is what 'uname -r' prints, the longest I've seen recently
is "3.10.0-1127.19.1.el7.x86_64" - well under the limit.

...
> 
> "The standard formulation seems to be: <project> <version> built
> <yyyy>-<mm>-<dd>"

Which I don't recall the string actually matching?
Also the people who like reproducible builds don't like __DATE__.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

From y2kenny at gmail.com  Thu May 25 08:37:54 2023
From: y2kenny at gmail.com (Kenny Ho)
Date: Thu, 25 May 2023 11:37:54 -0400
Subject: [PATCH] Remove hardcoded static string length
In-Reply-To: <81d01562a59a4fb49cd4681ebcf2e74a@AcuMS.aculab.com>
References: <20230523223944.691076-1-Kenny.Ho@amd.com> <01936d68-85d3-4d20-9beb-27ff9f62d826@lunn.ch>
 <CAB9dFdt4-cBFhEqsTXk9suE+Bw-xcpM0n3Q6rFmBaa+8A5uMWQ@mail.gmail.com>
 <c0fda91b-1e98-420f-a18a-16bbed25e98d@lunn.ch> <CAOWid-erNGD24Ouf4fAJJBqm69QVoHOpNt0E-G+Wt=nq1W4oBQ@mail.gmail.com>
 <5b1355b8-17f7-49c8-b7b5-3d9ecdb146ce@lunn.ch> <CAOWid-dYtkcKuNxoOyf3yqSJ7OtcNjaqJLVX1QhRUhYSOO6vHA@mail.gmail.com>
 <30d65ea9170d4f60bd76ed516541cb46@AcuMS.aculab.com> <CAOWid-eEbeeU9mOpwgOatt5rHQhRt+xPrsQ1fsMemVZDdeN=MQ@mail.gmail.com>
 <81d01562a59a4fb49cd4681ebcf2e74a@AcuMS.aculab.com>
Message-ID: <CAOWid-d=OFn7JS5JvsK9qc7X6HeZgOm5OAd1_g2=_GZgpKRZnA@mail.gmail.com>

On Thu, May 25, 2023 at 11:04?AM David Laight <David.Laight at aculab.com> wrote:
> But isn't UTS_RELEASE usually much shorter?
> I think it is what 'uname -r' prints, the longest I've seen recently
> is "3.10.0-1127.19.1.el7.x86_64" - well under the limit.

Usually yes, but I believe LOCALVERSION can be appended to
KERNELRELEASE / UTS_RELEASE which can makes it much longer.

> > "The standard formulation seems to be: <project> <version> built
> > <yyyy>-<mm>-<dd>"
>
> Which I don't recall the string actually matching?
> Also the people who like reproducible builds don't like __DATE__.

That's correct, it was not matching even when it was introduced.  I am
simply taking that as people caring about the content and not simply
making rxrpc_version_string == UTS_RELEASE.  The current format is:

"linux-" UTS_RELEASE " AF_RXRPC"

Kenny


From Kenny.Ho at amd.com  Thu May 25 14:13:46 2023
From: Kenny.Ho at amd.com (Kenny Ho)
Date: Thu, 25 May 2023 17:13:46 -0400
Subject: [PATCH] Truncate UTS_RELEASE for rxrpc version
Message-ID: <20230525211346.718562-1-Kenny.Ho@amd.com>

UTS_RELEASE has maximum length of 64 which can cause rxrpc_version to
exceed the 65 byte message limit.

Per https://web.mit.edu/kolya/afs/rx/rx-spec
"If a server receives a packet with a type value of 13, and the
client-initiated flag set, it should respond with a 65-byte payload
containing a string that identifies the version of AFS software it is
running."

Current implementation causes compile error when WERROR is turned on and
when UTS_RELEASE exceed the length of 49 (making the version string more
than 64 characters.)

Signed-off-by: Kenny Ho <Kenny.Ho at amd.com>
---
 net/rxrpc/local_event.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/net/rxrpc/local_event.c b/net/rxrpc/local_event.c
index 19e929c7c38b..90af6fbb9266 100644
--- a/net/rxrpc/local_event.c
+++ b/net/rxrpc/local_event.c
@@ -16,8 +16,6 @@
 #include <generated/utsrelease.h>
 #include "ar-internal.h"
 
-static const char rxrpc_version_string[65] = "linux-" UTS_RELEASE " AF_RXRPC";
-
 /*
  * Reply to a version request
  */
@@ -30,6 +28,7 @@ static void rxrpc_send_version_request(struct rxrpc_local *local,
 	struct sockaddr_rxrpc srx;
 	struct msghdr msg;
 	struct kvec iov[2];
+	static char rxrpc_version_string[65];
 	size_t len;
 	int ret;
 
@@ -38,6 +37,12 @@ static void rxrpc_send_version_request(struct rxrpc_local *local,
 	if (rxrpc_extract_addr_from_skb(&srx, skb) < 0)
 		return;
 
+	if (!rxrpc_version_string[0])
+		snprintf(rxrpc_version_string,
+				sizeof(rxrpc_version_string),
+				"linux-%.49s AF_RXRPC",
+				UTS_RELEASE);
+
 	msg.msg_name	= &srx.transport;
 	msg.msg_namelen	= srx.transport_len;
 	msg.msg_control	= NULL;
-- 
2.25.1



From dhowells at redhat.com  Thu May 25 15:09:14 2023
From: dhowells at redhat.com (David Howells)
Date: Thu, 25 May 2023 23:09:14 +0100
Subject: [PATCH] Truncate UTS_RELEASE for rxrpc version
In-Reply-To: <20230525211346.718562-1-Kenny.Ho@amd.com>
References: <20230525211346.718562-1-Kenny.Ho@amd.com>
Message-ID: <223250.1685052554@warthog.procyon.org.uk>

Kenny Ho <Kenny.Ho at amd.com> wrote:

> @@ -30,6 +28,7 @@ static void rxrpc_send_version_request(struct rxrpc_local *local,
>  	struct sockaddr_rxrpc srx;
>  	struct msghdr msg;
>  	struct kvec iov[2];
> +	static char rxrpc_version_string[65];
>  	size_t len;
>  	int ret;
>  

That's not thread-safe.  If you have multiple endpoints each one of them could
be overwriting the string at the same time.  We can't guarantee that one
wouldn't corrupt the other.

There's also no need to reprint it every time; just once during module init
will do.  How about the attached patch instead?

David
---
rxrpc: Truncate UTS_RELEASE for rxrpc version

UTS_RELEASE has a maximum length of 64 which can cause rxrpc_version to
exceed the 65 byte message limit.

Per the rx spec[1]: "If a server receives a packet with a type value of 13,
and the client-initiated flag set, it should respond with a 65-byte payload
containing a string that identifies the version of AFS software it is
running."

The current implementation causes a compile error when WERROR is turned on
and/or UTS_RELEASE exceeds the length of 49 (making the version string more
than 64 characters).

Fix this by generating the string during module initialisation and limiting
the UTS_RELEASE segment of the string does not exceed 49 chars.  We need to
make sure that the 64 bytes includes "linux-" at the front and " AF_RXRPC" at
the back as this may be used in pattern matching.

Fixes: 44ba06987c0b ("RxRPC: Handle VERSION Rx protocol packets")
Reported-by: Kenny Ho <Kenny.Ho at amd.com>
Link: https://lore.kernel.org/r/20230523223944.691076-1-Kenny.Ho at amd.com/
Signed-off-by: David Howells <dhowells at redhat.com>
Link: https://web.mit.edu/kolya/afs/rx/rx-spec [1]
cc: Marc Dionne <marc.dionne at auristor.com>
cc: Andrew Lunn <andrew at lunn.ch>
cc: David Laight <David.Laight at ACULAB.COM>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: netdev at vger.kernel.org
---
 net/rxrpc/af_rxrpc.c    |    1 +
 net/rxrpc/ar-internal.h |    1 +
 net/rxrpc/local_event.c |   11 ++++++++++-
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index 31f738d65f1c..da0b3b5157d5 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -980,6 +980,7 @@ static int __init af_rxrpc_init(void)
 	BUILD_BUG_ON(sizeof(struct rxrpc_skb_priv) > sizeof_field(struct sk_buff, cb));
 
 	ret = -ENOMEM;
+	rxrpc_gen_version_string();
 	rxrpc_call_jar = kmem_cache_create(
 		"rxrpc_call_jar", sizeof(struct rxrpc_call), 0,
 		SLAB_HWCACHE_ALIGN, NULL);
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 5d44dc08f66d..e8e14c6f904d 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -1068,6 +1068,7 @@ int rxrpc_get_server_data_key(struct rxrpc_connection *, const void *, time64_t,
 /*
  * local_event.c
  */
+void rxrpc_gen_version_string(void);
 void rxrpc_send_version_request(struct rxrpc_local *local,
 				struct rxrpc_host_header *hdr,
 				struct sk_buff *skb);
diff --git a/net/rxrpc/local_event.c b/net/rxrpc/local_event.c
index 5e69ea6b233d..993c69f97488 100644
--- a/net/rxrpc/local_event.c
+++ b/net/rxrpc/local_event.c
@@ -16,7 +16,16 @@
 #include <generated/utsrelease.h>
 #include "ar-internal.h"
 
-static const char rxrpc_version_string[65] = "linux-" UTS_RELEASE " AF_RXRPC";
+static char rxrpc_version_string[65]; // "linux-" UTS_RELEASE " AF_RXRPC";
+
+/*
+ * Generate the VERSION packet string.
+ */
+void rxrpc_gen_version_string(void)
+{
+	snprintf(rxrpc_version_string, sizeof(rxrpc_version_string),
+		 "linux-%.49s AF_RXRPC", UTS_RELEASE);
+}
 
 /*
  * Reply to a version request



From tj at kernel.org  Thu May 25 15:14:40 2023
From: tj at kernel.org (Tejun Heo)
Date: Thu, 25 May 2023 12:14:40 -1000
Subject: [PATCH 10/13] rxrpc: Use alloc_ordered_workqueue() to create
 ordered workqueues
In-Reply-To: <20230509015032.3768622-11-tj@kernel.org>
References: <20230509015032.3768622-1-tj@kernel.org>
 <20230509015032.3768622-11-tj@kernel.org>
Message-ID: <ZG_d0OzPmnQCAE-1@slm.duckdns.org>

On Mon, May 08, 2023 at 03:50:29PM -1000, Tejun Heo wrote:
...
> Signed-off-by: Tejun Heo <tj at kernel.org>
> Cc: David Howells <dhowells at redhat.com>
> Cc: Marc Dionne <marc.dionne at auristor.com>
> Cc: "David S. Miller" <davem at davemloft.net>
> Cc: Eric Dumazet <edumazet at google.com>
> Cc: Jakub Kicinski <kuba at kernel.org>
> Cc: Paolo Abeni <pabeni at redhat.com>
> Cc: linux-afs at lists.infradead.org
> Cc: netdev at vger.kernel.org

Hey, I'm going to apply this to wq/for-6.5-cleanup-ordered. As it's an
identity conversion, it shouldn't break anything. Please holler if you have
any concerns.

Thanks.

-- 
tejun


From y2kenny at gmail.com  Thu May 25 15:28:41 2023
From: y2kenny at gmail.com (Kenny Ho)
Date: Thu, 25 May 2023 18:28:41 -0400
Subject: [PATCH] Truncate UTS_RELEASE for rxrpc version
In-Reply-To: <223250.1685052554@warthog.procyon.org.uk>
References: <20230525211346.718562-1-Kenny.Ho@amd.com> <223250.1685052554@warthog.procyon.org.uk>
Message-ID: <CAOWid-c2_atz6oQspoQq4MQQ=DQWfJ=-JgbV2QFY8PveC+Sb8Q@mail.gmail.com>

On Thu, May 25, 2023 at 6:09?PM David Howells <dhowells at redhat.com> wrote:
> There's also no need to reprint it every time; just once during module init
> will do.  How about the attached patch instead?

This makes sense and looks fine to me.  I don't know the proper
etiquette here, but
Acked-by: Kenny Ho <Kenny.Ho at amd.com>

Kenny


From dhowells at redhat.com  Thu May 25 15:52:12 2023
From: dhowells at redhat.com (David Howells)
Date: Thu, 25 May 2023 23:52:12 +0100
Subject: [PATCH] Truncate UTS_RELEASE for rxrpc version
In-Reply-To: <CAOWid-c2_atz6oQspoQq4MQQ=DQWfJ=-JgbV2QFY8PveC+Sb8Q@mail.gmail.com>
References: <CAOWid-c2_atz6oQspoQq4MQQ=DQWfJ=-JgbV2QFY8PveC+Sb8Q@mail.gmail.com> <20230525211346.718562-1-Kenny.Ho@amd.com> <223250.1685052554@warthog.procyon.org.uk>
Message-ID: <225785.1685055132@warthog.procyon.org.uk>

Kenny Ho <y2kenny at gmail.com> wrote:

> This makes sense and looks fine to me.  I don't know the proper
> etiquette here, but
> Acked-by: Kenny Ho <Kenny.Ho at amd.com>

If I'm not going to pick the patch up, I tend to use Acked-by when reviewing a
patch that touches code I'm a listed maintainer for and Reviewed-by when it's
code that I'm not a maintainer for...  but the descriptions in:

	Documentation/process/submitting-patches.rst

seem to leave a lot of overlap.

David



From simon.horman at corigine.com  Fri May 26 02:38:16 2023
From: simon.horman at corigine.com (Simon Horman)
Date: Fri, 26 May 2023 11:38:16 +0200
Subject: [PATCH] Truncate UTS_RELEASE for rxrpc version
In-Reply-To: <223250.1685052554@warthog.procyon.org.uk>
References: <20230525211346.718562-1-Kenny.Ho@amd.com>
 <223250.1685052554@warthog.procyon.org.uk>
Message-ID: <ZHB+COAmd3CzVGaJ@corigine.com>

On Thu, May 25, 2023 at 11:09:14PM +0100, David Howells wrote:
> Kenny Ho <Kenny.Ho at amd.com> wrote:
> 
> > @@ -30,6 +28,7 @@ static void rxrpc_send_version_request(struct rxrpc_local *local,
> >  	struct sockaddr_rxrpc srx;
> >  	struct msghdr msg;
> >  	struct kvec iov[2];
> > +	static char rxrpc_version_string[65];
> >  	size_t len;
> >  	int ret;
> >  
> 
> That's not thread-safe.  If you have multiple endpoints each one of them could
> be overwriting the string at the same time.  We can't guarantee that one
> wouldn't corrupt the other.
> 
> There's also no need to reprint it every time; just once during module init
> will do.  How about the attached patch instead?
> 
> David

Thanks David ad Kenny,

can we arrange for a formal posting of the patch below?
I suspect it will languish otherwise.

> ---
> rxrpc: Truncate UTS_RELEASE for rxrpc version
> 
> UTS_RELEASE has a maximum length of 64 which can cause rxrpc_version to
> exceed the 65 byte message limit.
> 
> Per the rx spec[1]: "If a server receives a packet with a type value of 13,
> and the client-initiated flag set, it should respond with a 65-byte payload
> containing a string that identifies the version of AFS software it is
> running."
> 
> The current implementation causes a compile error when WERROR is turned on
> and/or UTS_RELEASE exceeds the length of 49 (making the version string more
> than 64 characters).
> 
> Fix this by generating the string during module initialisation and limiting
> the UTS_RELEASE segment of the string does not exceed 49 chars.  We need to
> make sure that the 64 bytes includes "linux-" at the front and " AF_RXRPC" at
> the back as this may be used in pattern matching.
> 
> Fixes: 44ba06987c0b ("RxRPC: Handle VERSION Rx protocol packets")
> Reported-by: Kenny Ho <Kenny.Ho at amd.com>
> Link: https://lore.kernel.org/r/20230523223944.691076-1-Kenny.Ho at amd.com/
> Signed-off-by: David Howells <dhowells at redhat.com>
> Link: https://web.mit.edu/kolya/afs/rx/rx-spec [1]
> cc: Marc Dionne <marc.dionne at auristor.com>
> cc: Andrew Lunn <andrew at lunn.ch>
> cc: David Laight <David.Laight at ACULAB.COM>
> cc: "David S. Miller" <davem at davemloft.net>
> cc: Eric Dumazet <edumazet at google.com>
> cc: Jakub Kicinski <kuba at kernel.org>
> cc: Paolo Abeni <pabeni at redhat.com>
> cc: linux-afs at lists.infradead.org
> cc: netdev at vger.kernel.org
> ---
>  net/rxrpc/af_rxrpc.c    |    1 +
>  net/rxrpc/ar-internal.h |    1 +
>  net/rxrpc/local_event.c |   11 ++++++++++-
>  3 files changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
> index 31f738d65f1c..da0b3b5157d5 100644
> --- a/net/rxrpc/af_rxrpc.c
> +++ b/net/rxrpc/af_rxrpc.c
> @@ -980,6 +980,7 @@ static int __init af_rxrpc_init(void)
>  	BUILD_BUG_ON(sizeof(struct rxrpc_skb_priv) > sizeof_field(struct sk_buff, cb));
>  
>  	ret = -ENOMEM;
> +	rxrpc_gen_version_string();
>  	rxrpc_call_jar = kmem_cache_create(
>  		"rxrpc_call_jar", sizeof(struct rxrpc_call), 0,
>  		SLAB_HWCACHE_ALIGN, NULL);
> diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
> index 5d44dc08f66d..e8e14c6f904d 100644
> --- a/net/rxrpc/ar-internal.h
> +++ b/net/rxrpc/ar-internal.h
> @@ -1068,6 +1068,7 @@ int rxrpc_get_server_data_key(struct rxrpc_connection *, const void *, time64_t,
>  /*
>   * local_event.c
>   */
> +void rxrpc_gen_version_string(void);
>  void rxrpc_send_version_request(struct rxrpc_local *local,
>  				struct rxrpc_host_header *hdr,
>  				struct sk_buff *skb);
> diff --git a/net/rxrpc/local_event.c b/net/rxrpc/local_event.c
> index 5e69ea6b233d..993c69f97488 100644
> --- a/net/rxrpc/local_event.c
> +++ b/net/rxrpc/local_event.c
> @@ -16,7 +16,16 @@
>  #include <generated/utsrelease.h>
>  #include "ar-internal.h"
>  
> -static const char rxrpc_version_string[65] = "linux-" UTS_RELEASE " AF_RXRPC";
> +static char rxrpc_version_string[65]; // "linux-" UTS_RELEASE " AF_RXRPC";
> +
> +/*
> + * Generate the VERSION packet string.
> + */
> +void rxrpc_gen_version_string(void)
> +{
> +	snprintf(rxrpc_version_string, sizeof(rxrpc_version_string),
> +		 "linux-%.49s AF_RXRPC", UTS_RELEASE);
> +}
>  
>  /*
>   * Reply to a version request
> 
> 


From dhowells at redhat.com  Fri May 26 04:34:54 2023
From: dhowells at redhat.com (David Howells)
Date: Fri, 26 May 2023 12:34:54 +0100
Subject: [PATCH net] rxrpc: Truncate UTS_RELEASE for rxrpc version 
Message-ID: <654974.1685100894@warthog.procyon.org.uk>

    
UTS_RELEASE has a maximum length of 64 which can cause rxrpc_version to
exceed the 65 byte message limit.

Per the rx spec[1]: "If a server receives a packet with a type value of 13,
and the client-initiated flag set, it should respond with a 65-byte payload
containing a string that identifies the version of AFS software it is
running."

The current implementation causes a compile error when WERROR is turned on
and/or UTS_RELEASE exceeds the length of 49 (making the version string more
than 64 characters).

Fix this by generating the string during module initialisation and limiting
the UTS_RELEASE segment of the string does not exceed 49 chars.  We need to
make sure that the 64 bytes includes "linux-" at the front and " AF_RXRPC"
at the back as this may be used in pattern matching.

Fixes: 44ba06987c0b ("RxRPC: Handle VERSION Rx protocol packets")
Reported-by: Kenny Ho <Kenny.Ho at amd.com>
Link: https://lore.kernel.org/r/20230523223944.691076-1-Kenny.Ho at amd.com/
Signed-off-by: David Howells <dhowells at redhat.com>
Acked-by: Kenny Ho <Kenny.Ho at amd.com>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: Andrew Lunn <andrew at lunn.ch>
cc: David Laight <David.Laight at ACULAB.COM>
cc: "David S. Miller" <davem at davemloft.net>
cc: Eric Dumazet <edumazet at google.com>
cc: Jakub Kicinski <kuba at kernel.org>
cc: Paolo Abeni <pabeni at redhat.com>
cc: linux-afs at lists.infradead.org
cc: netdev at vger.kernel.org
Link: https://web.mit.edu/kolya/afs/rx/rx-spec [1]
---
 net/rxrpc/af_rxrpc.c    |    1 +
 net/rxrpc/ar-internal.h |    1 +
 net/rxrpc/local_event.c |   11 ++++++++++-
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index 31f738d65f1c..da0b3b5157d5 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -980,6 +980,7 @@ static int __init af_rxrpc_init(void)
 	BUILD_BUG_ON(sizeof(struct rxrpc_skb_priv) > sizeof_field(struct sk_buff, cb));
 
 	ret = -ENOMEM;
+	rxrpc_gen_version_string();
 	rxrpc_call_jar = kmem_cache_create(
 		"rxrpc_call_jar", sizeof(struct rxrpc_call), 0,
 		SLAB_HWCACHE_ALIGN, NULL);
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 5d44dc08f66d..e8e14c6f904d 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -1068,6 +1068,7 @@ int rxrpc_get_server_data_key(struct rxrpc_connection *, const void *, time64_t,
 /*
  * local_event.c
  */
+void rxrpc_gen_version_string(void);
 void rxrpc_send_version_request(struct rxrpc_local *local,
 				struct rxrpc_host_header *hdr,
 				struct sk_buff *skb);
diff --git a/net/rxrpc/local_event.c b/net/rxrpc/local_event.c
index 5e69ea6b233d..993c69f97488 100644
--- a/net/rxrpc/local_event.c
+++ b/net/rxrpc/local_event.c
@@ -16,7 +16,16 @@
 #include <generated/utsrelease.h>
 #include "ar-internal.h"
 
-static const char rxrpc_version_string[65] = "linux-" UTS_RELEASE " AF_RXRPC";
+static char rxrpc_version_string[65]; // "linux-" UTS_RELEASE " AF_RXRPC";
+
+/*
+ * Generate the VERSION packet string.
+ */
+void rxrpc_gen_version_string(void)
+{
+	snprintf(rxrpc_version_string, sizeof(rxrpc_version_string),
+		 "linux-%.49s AF_RXRPC", UTS_RELEASE);
+}
 
 /*
  * Reply to a version request



From simon.horman at corigine.com  Sat May 27 04:59:51 2023
From: simon.horman at corigine.com (Simon Horman)
Date: Sat, 27 May 2023 13:59:51 +0200
Subject: [PATCH net] rxrpc: Truncate UTS_RELEASE for rxrpc version
In-Reply-To: <654974.1685100894@warthog.procyon.org.uk>
References: <654974.1685100894@warthog.procyon.org.uk>
Message-ID: <ZHHwt5hnna64Vpn4@corigine.com>

On Fri, May 26, 2023 at 12:34:54PM +0100, David Howells wrote:
>     
> UTS_RELEASE has a maximum length of 64 which can cause rxrpc_version to
> exceed the 65 byte message limit.
> 
> Per the rx spec[1]: "If a server receives a packet with a type value of 13,
> and the client-initiated flag set, it should respond with a 65-byte payload
> containing a string that identifies the version of AFS software it is
> running."
> 
> The current implementation causes a compile error when WERROR is turned on
> and/or UTS_RELEASE exceeds the length of 49 (making the version string more
> than 64 characters).
> 
> Fix this by generating the string during module initialisation and limiting
> the UTS_RELEASE segment of the string does not exceed 49 chars.  We need to
> make sure that the 64 bytes includes "linux-" at the front and " AF_RXRPC"
> at the back as this may be used in pattern matching.
> 
> Fixes: 44ba06987c0b ("RxRPC: Handle VERSION Rx protocol packets")
> Reported-by: Kenny Ho <Kenny.Ho at amd.com>
> Link: https://lore.kernel.org/r/20230523223944.691076-1-Kenny.Ho at amd.com/
> Signed-off-by: David Howells <dhowells at redhat.com>
> Acked-by: Kenny Ho <Kenny.Ho at amd.com>
> cc: Marc Dionne <marc.dionne at auristor.com>
> cc: Andrew Lunn <andrew at lunn.ch>
> cc: David Laight <David.Laight at ACULAB.COM>
> cc: "David S. Miller" <davem at davemloft.net>
> cc: Eric Dumazet <edumazet at google.com>
> cc: Jakub Kicinski <kuba at kernel.org>
> cc: Paolo Abeni <pabeni at redhat.com>
> cc: linux-afs at lists.infradead.org
> cc: netdev at vger.kernel.org
> Link: https://web.mit.edu/kolya/afs/rx/rx-spec [1]

Reviewed-by: Simon Horman <simon.horman at corigine.com>



From jaltman at auristor.com  Sat May 27 07:20:33 2023
From: jaltman at auristor.com (Jeffrey E Altman)
Date: Sat, 27 May 2023 10:20:33 -0400
Subject: [PATCH net] rxrpc: Truncate UTS_RELEASE for rxrpc version
In-Reply-To: <654974.1685100894@warthog.procyon.org.uk>
References: <654974.1685100894@warthog.procyon.org.uk>
Message-ID: <2a3bc88a-d851-b3c4-89d4-fdcc4378c2f5@auristor.com>

On 5/26/2023 7:34 AM, David Howells wrote:
>      
> UTS_RELEASE has a maximum length of 64 which can cause rxrpc_version to
> exceed the 65 byte message limit.
>
> Per the rx spec[1]: "If a server receives a packet with a type value of 13,
> and the client-initiated flag set, it should respond with a 65-byte payload
> containing a string that identifies the version of AFS software it is
> running."
>
> The current implementation causes a compile error when WERROR is turned on
> and/or UTS_RELEASE exceeds the length of 49 (making the version string more
> than 64 characters).
>
> Fix this by generating the string during module initialisation and limiting
> the UTS_RELEASE segment of the string does not exceed 49 chars.  We need to
> make sure that the 64 bytes includes "linux-" at the front and " AF_RXRPC"
> at the back as this may be used in pattern matching.
>
> Fixes: 44ba06987c0b ("RxRPC: Handle VERSION Rx protocol packets")
> Reported-by: Kenny Ho <Kenny.Ho at amd.com>
> Link: https://lore.kernel.org/r/20230523223944.691076-1-Kenny.Ho at amd.com/
> Signed-off-by: David Howells <dhowells at redhat.com>
> Acked-by: Kenny Ho <Kenny.Ho at amd.com>
> cc: Marc Dionne <marc.dionne at auristor.com>
> cc: Andrew Lunn <andrew at lunn.ch>
> cc: David Laight <David.Laight at ACULAB.COM>
> cc: "David S. Miller" <davem at davemloft.net>
> cc: Eric Dumazet <edumazet at google.com>
> cc: Jakub Kicinski <kuba at kernel.org>
> cc: Paolo Abeni <pabeni at redhat.com>
> cc: linux-afs at lists.infradead.org
> cc: netdev at vger.kernel.org
> Link: https://web.mit.edu/kolya/afs/rx/rx-spec [1]
> ---
>   net/rxrpc/af_rxrpc.c    |    1 +
>   net/rxrpc/ar-internal.h |    1 +
>   net/rxrpc/local_event.c |   11 ++++++++++-
>   3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
> index 31f738d65f1c..da0b3b5157d5 100644
> --- a/net/rxrpc/af_rxrpc.c
> +++ b/net/rxrpc/af_rxrpc.c
> @@ -980,6 +980,7 @@ static int __init af_rxrpc_init(void)
>   	BUILD_BUG_ON(sizeof(struct rxrpc_skb_priv) > sizeof_field(struct sk_buff, cb));
>   
>   	ret = -ENOMEM;
> +	rxrpc_gen_version_string();
>   	rxrpc_call_jar = kmem_cache_create(
>   		"rxrpc_call_jar", sizeof(struct rxrpc_call), 0,
>   		SLAB_HWCACHE_ALIGN, NULL);
> diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
> index 5d44dc08f66d..e8e14c6f904d 100644
> --- a/net/rxrpc/ar-internal.h
> +++ b/net/rxrpc/ar-internal.h
> @@ -1068,6 +1068,7 @@ int rxrpc_get_server_data_key(struct rxrpc_connection *, const void *, time64_t,
>   /*
>    * local_event.c
>    */
> +void rxrpc_gen_version_string(void);
>   void rxrpc_send_version_request(struct rxrpc_local *local,
>   				struct rxrpc_host_header *hdr,
>   				struct sk_buff *skb);
> diff --git a/net/rxrpc/local_event.c b/net/rxrpc/local_event.c
> index 5e69ea6b233d..993c69f97488 100644
> --- a/net/rxrpc/local_event.c
> +++ b/net/rxrpc/local_event.c
> @@ -16,7 +16,16 @@
>   #include <generated/utsrelease.h>
>   #include "ar-internal.h"
>   
> -static const char rxrpc_version_string[65] = "linux-" UTS_RELEASE " AF_RXRPC";
> +static char rxrpc_version_string[65]; // "linux-" UTS_RELEASE " AF_RXRPC";
> +
> +/*
> + * Generate the VERSION packet string.
> + */
> +void rxrpc_gen_version_string(void)
> +{
> +	snprintf(rxrpc_version_string, sizeof(rxrpc_version_string),
> +		 "linux-%.49s AF_RXRPC", UTS_RELEASE);
> +}
>   
>   /*
>    * Reply to a version request
>
Reviewed-by: Jeffrey Altman <jaltman at auristor.com>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4039 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20230527/5e57c06f/attachment-0001.p7s>

From jaltman at auristor.com  Sat May 27 07:45:10 2023
From: jaltman at auristor.com (Jeffrey E Altman)
Date: Sat, 27 May 2023 10:45:10 -0400
Subject: [PATCH] Remove hardcoded static string length
In-Reply-To: <5b1355b8-17f7-49c8-b7b5-3d9ecdb146ce@lunn.ch>
References: <20230523223944.691076-1-Kenny.Ho@amd.com>
 <01936d68-85d3-4d20-9beb-27ff9f62d826@lunn.ch>
 <CAB9dFdt4-cBFhEqsTXk9suE+Bw-xcpM0n3Q6rFmBaa+8A5uMWQ@mail.gmail.com>
 <c0fda91b-1e98-420f-a18a-16bbed25e98d@lunn.ch>
 <CAOWid-erNGD24Ouf4fAJJBqm69QVoHOpNt0E-G+Wt=nq1W4oBQ@mail.gmail.com>
 <5b1355b8-17f7-49c8-b7b5-3d9ecdb146ce@lunn.ch>
Message-ID: <51ea1522-edc2-bd15-2873-0712e7eb49c3@auristor.com>

On 5/24/2023 1:43 PM, Andrew Lunn wrote:
> On Wed, May 24, 2023 at 01:02:36PM -0400, Kenny Ho wrote:
>> On Wed, May 24, 2023 at 12:02?PM Andrew Lunn <andrew at lunn.ch> wrote:
>>> So the compiler warning/error needs to be fixed a different want.
>> Understood.  Would caping the length at iov_len with a ternary be sufficient?
> The quoted text said 'string'. It is not clear if that means c-string,
> with a trailing \0. If you just cap iov_len you could end up with a
> string which is not terminated.
The expected buffer is a NUL terminated c-string.
> The other end of the socket should not blow up, because that would be
> an obvious DOS or buffer overwrite attack vector.

This is a valid concern because all versions of IBM AFS 3.6 Rx and 
OpenAFS Rx prior to 1.6.23 are susceptible to read beyond the end of 
buffer if either the received data is longer than 65 octets or the 
received data is 65 octets but not NUL terminated.

Jeffrey Altman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4039 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20230527/525fdb7a/attachment-0001.p7s>

From jaltman at auristor.com  Sat May 27 08:08:10 2023
From: jaltman at auristor.com (Jeffrey E Altman)
Date: Sat, 27 May 2023 11:08:10 -0400
Subject: [PATCH net] rxrpc: Truncate UTS_RELEASE for rxrpc version
In-Reply-To: <654974.1685100894@warthog.procyon.org.uk>
References: <654974.1685100894@warthog.procyon.org.uk>
Message-ID: <f1d7630f-f6e2-5748-9b75-579babed0953@auristor.com>

On 5/26/2023 7:34 AM, David Howells wrote:
> UTS_RELEASE has a maximum length of 64 which can cause rxrpc_version to
> exceed the 65 byte message limit.
>
> Per the rx spec[1]: "If a server receives a packet with a type value 
> of 13,
> and the client-initiated flag set, it should respond with a 65-byte 
> payload
> containing a string that identifies the version of AFS software it is
> running."
>
> The current implementation causes a compile error when WERROR is turned on
> and/or UTS_RELEASE exceeds the length of 49 (making the version string 
> more
> than 64 characters).
>
> Fix this by generating the string during module initialisation and 
> limiting
> the UTS_RELEASE segment of the string does not exceed 49 chars. We need to
> make sure that the 64 bytes includes "linux-" at the front and " AF_RXRPC"
> at the back as this may be used in pattern matching.
>
> Fixes: 44ba06987c0b ("RxRPC: Handle VERSION Rx protocol packets")
> Reported-by: Kenny Ho <Kenny.Ho at amd.com>
> Link: https://lore.kernel.org/r/20230523223944.691076-1-Kenny.Ho at amd.com/
> Signed-off-by: David Howells <dhowells at redhat.com>
> Acked-by: Kenny Ho <Kenny.Ho at amd.com>
> cc: Marc Dionne <marc.dionne at auristor.com>
> cc: Andrew Lunn <andrew at lunn.ch>
> cc: David Laight <David.Laight at ACULAB.COM>
> cc: "David S. Miller" <davem at davemloft.net>
> cc: Eric Dumazet <edumazet at google.com>
> cc: Jakub Kicinski <kuba at kernel.org>
> cc: Paolo Abeni <pabeni at redhat.com>
> cc: linux-afs at lists.infradead.org
> cc: netdev at vger.kernel.org
> Link: https://web.mit.edu/kolya/afs/rx/rx-spec [1]
> ---
> net/rxrpc/af_rxrpc.c | 1 +
> net/rxrpc/ar-internal.h | 1 +
> net/rxrpc/local_event.c | 11 ++++++++++-
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
> index 31f738d65f1c..da0b3b5157d5 100644
> --- a/net/rxrpc/af_rxrpc.c
> +++ b/net/rxrpc/af_rxrpc.c
> @@ -980,6 +980,7 @@ static int __init af_rxrpc_init(void)
> BUILD_BUG_ON(sizeof(struct rxrpc_skb_priv) > sizeof_field(struct 
> sk_buff, cb));
> ret = -ENOMEM;
> + rxrpc_gen_version_string();
> rxrpc_call_jar = kmem_cache_create(
> "rxrpc_call_jar", sizeof(struct rxrpc_call), 0,
> SLAB_HWCACHE_ALIGN, NULL);
> diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
> index 5d44dc08f66d..e8e14c6f904d 100644
> --- a/net/rxrpc/ar-internal.h
> +++ b/net/rxrpc/ar-internal.h
> @@ -1068,6 +1068,7 @@ int rxrpc_get_server_data_key(struct 
> rxrpc_connection *, const void *, time64_t,
> /*
> * local_event.c
> */
> +void rxrpc_gen_version_string(void);
> void rxrpc_send_version_request(struct rxrpc_local *local,
> struct rxrpc_host_header *hdr,
> struct sk_buff *skb);
> diff --git a/net/rxrpc/local_event.c b/net/rxrpc/local_event.c
> index 5e69ea6b233d..993c69f97488 100644
> --- a/net/rxrpc/local_event.c
> +++ b/net/rxrpc/local_event.c
> @@ -16,7 +16,16 @@
> #include <generated/utsrelease.h>
> #include "ar-internal.h"
> -static const char rxrpc_version_string[65] = "linux-" UTS_RELEASE " 
> AF_RXRPC";
> +static char rxrpc_version_string[65]; // "linux-" UTS_RELEASE " 
> AF_RXRPC";
> +
> +/*
> + * Generate the VERSION packet string.
> + */
> +void rxrpc_gen_version_string(void)
> +{
> + snprintf(rxrpc_version_string, sizeof(rxrpc_version_string),
> + "linux-%.49s AF_RXRPC", UTS_RELEASE);
> +}
> /*
> * Reply to a version request
>
Reviewed-by: Jeffrey Altman <jaltman at auristor.com>




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4039 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20230527/fe41c130/attachment-0001.p7s>

From jaltman at auristor.com  Sat May 27 08:08:33 2023
From: jaltman at auristor.com (Jeffrey E Altman)
Date: Sat, 27 May 2023 11:08:33 -0400
Subject: [PATCH] Remove hardcoded static string length
In-Reply-To: <5b1355b8-17f7-49c8-b7b5-3d9ecdb146ce@lunn.ch>
References: <20230523223944.691076-1-Kenny.Ho@amd.com>
 <01936d68-85d3-4d20-9beb-27ff9f62d826@lunn.ch>
 <CAB9dFdt4-cBFhEqsTXk9suE+Bw-xcpM0n3Q6rFmBaa+8A5uMWQ@mail.gmail.com>
 <c0fda91b-1e98-420f-a18a-16bbed25e98d@lunn.ch>
 <CAOWid-erNGD24Ouf4fAJJBqm69QVoHOpNt0E-G+Wt=nq1W4oBQ@mail.gmail.com>
 <5b1355b8-17f7-49c8-b7b5-3d9ecdb146ce@lunn.ch>
Message-ID: <76cb5084-a2aa-6ccd-b531-6338f6673f51@auristor.com>

On 5/24/2023 1:43 PM, Andrew Lunn wrote:
> On Wed, May 24, 2023 at 01:02:36PM -0400, Kenny Ho wrote:
>> On Wed, May 24, 2023 at 12:02?PM Andrew Lunn <andrew at lunn.ch> wrote:
>>> So the compiler warning/error needs to be fixed a different want.
>> Understood. Would caping the length at iov_len with a ternary be 
>> sufficient?
> The quoted text said 'string'. It is not clear if that means c-string,
> with a trailing \0. If you just cap iov_len you could end up with a
> string which is not terminated.
The expected buffer is a NUL terminated c-string.
> The other end of the socket should not blow up, because that would be
> an obvious DOS or buffer overwrite attack vector.

This is a valid concern because all versions of IBM AFS 3.6 Rx and 
OpenAFS Rx prior to 1.6.23 are susceptible to read beyond the end of 
buffer if either the received data is longer than 65 octets or the 
received data is 65 octets but not NUL terminated.

Jeffrey Altman



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4039 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20230527/f8377cc9/attachment-0001.p7s>

From jaltman at auristor.com  Sat May 27 08:08:58 2023
From: jaltman at auristor.com (Jeffrey E Altman)
Date: Sat, 27 May 2023 11:08:58 -0400
Subject: [PATCH] Remove hardcoded static string length
In-Reply-To: <CAOWid-d=OFn7JS5JvsK9qc7X6HeZgOm5OAd1_g2=_GZgpKRZnA@mail.gmail.com>
References: <20230523223944.691076-1-Kenny.Ho@amd.com>
 <01936d68-85d3-4d20-9beb-27ff9f62d826@lunn.ch>
 <CAB9dFdt4-cBFhEqsTXk9suE+Bw-xcpM0n3Q6rFmBaa+8A5uMWQ@mail.gmail.com>
 <c0fda91b-1e98-420f-a18a-16bbed25e98d@lunn.ch>
 <CAOWid-erNGD24Ouf4fAJJBqm69QVoHOpNt0E-G+Wt=nq1W4oBQ@mail.gmail.com>
 <5b1355b8-17f7-49c8-b7b5-3d9ecdb146ce@lunn.ch>
 <CAOWid-dYtkcKuNxoOyf3yqSJ7OtcNjaqJLVX1QhRUhYSOO6vHA@mail.gmail.com>
 <30d65ea9170d4f60bd76ed516541cb46@AcuMS.aculab.com>
 <CAOWid-eEbeeU9mOpwgOatt5rHQhRt+xPrsQ1fsMemVZDdeN=MQ@mail.gmail.com>
 <81d01562a59a4fb49cd4681ebcf2e74a@AcuMS.aculab.com>
 <CAOWid-d=OFn7JS5JvsK9qc7X6HeZgOm5OAd1_g2=_GZgpKRZnA@mail.gmail.com>
Message-ID: <c22f76b1-0559-410f-38f2-266e1a9fcca5@auristor.com>

On 5/25/2023 11:37 AM, Kenny Ho wrote:
> On Thu, May 25, 2023 at 11:04?AM David Laight<David.Laight at aculab.com>  wrote:
>>> "The standard formulation seems to be: <project> <version> built
>>> <yyyy>-<mm>-<dd>"
>> Which I don't recall the string actually matching?
>> Also the people who like reproducible builds don't like __DATE__.
> That's correct, it was not matching even when it was introduced.  I am
> simply taking that as people caring about the content and not simply
> making rxrpc_version_string == UTS_RELEASE.  The current format is:
>
> "linux-" UTS_RELEASE " AF_RXRPC"
>
> Kenny

The RX_PACKET_TYPE_VERSION query is issued by the "rxdebug <host> <port> 
-version" command which prints the received string to stdout.?? It has 
also been used some implementations to record the version of the peer.?? 
Although it is required that a response to the RX_PACKET_TYPE_VERSION 
query be issued, there is no requirement that the returned string 
contain anything beyond a single NUL octet.

Although it is convenient to be able to remotely identify the version of 
an Rx implementation, there are good reasons why this information should 
not be exposed to an anonymous requester:

 1. Linux AF_RXRPC is part of the kernel.? As such, returning
    UTS_RELEASE identifies to potential attackers the explicit kernel
    version, architecture and perhaps distro.? As this query can be
    issued anonymously, this provides an information disclosure that can
    be used to target known vulnerabilities in the kernel.
 2. The RX_PACKET_TYPE_VERSION reply is larger than the query by the
    number of octets in the version data.? As the query is received via
    udp with no reachability test, it means that the
    RX_PACKET_TYPE_VERSION query/response can be used to perform an 3.3x
    amplification attack: 28 octets in and potentially 93 octets out.

With my security hat on I would suggest that either AF_RXRPC return a 
single NUL octet or the c-string "AF_RXRPC" and nothing more.

Jeffrey Altman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4039 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20230527/41585db7/attachment-0001.p7s>

From dhowells at redhat.com  Wed May 31 07:40:16 2023
From: dhowells at redhat.com (David Howells)
Date: Wed, 31 May 2023 15:40:16 +0100
Subject: [PATCH strace] Implement decoding of RXRPC_* control messages
In-Reply-To: <20230509080042.GA22326@altlinux.org>
References: <20230509080042.GA22326@altlinux.org> <2044497.1683295035@warthog.procyon.org.uk>
Message-ID: <716266.1685544016@warthog.procyon.org.uk>

Dmitry V. Levin <ldv at strace.io> wrote:

> I suppose a switch statement would be more concise in this case.

It would be 13 lines rather than 8, but it looks neater.

> Looks like this table would benefit from #value_indexed.

Done.

> By the way, would it make sense to list RXRPC_ACCEPT here as well, even
> though it was removed from the kernel by commit v4.9-rc1~127^2~247^2?

I can add it.

> And the last but not least, do you have any ideas how this new decoder
> could be tested?

Something like this:

	https://people.redhat.com/dhowells/rxrpc/rxrpc.c
	https://people.redhat.com/dhowells/rxrpc/listen.c

but it needs cleaning up.  It shouldn't need any external infrastructure, but
it does require a client and a server and a UDP port to listen on.

Do you want something that lives in the tests/ directory?

David



From dhowells at redhat.com  Wed May 31 07:42:39 2023
From: dhowells at redhat.com (David Howells)
Date: Wed, 31 May 2023 15:42:39 +0100
Subject: [PATCH strace v2] Implement decoding of RXRPC_* control messages
In-Reply-To: <2044497.1683295035@warthog.procyon.org.uk>
References: <2044497.1683295035@warthog.procyon.org.uk>
Message-ID: <716374.1685544159@warthog.procyon.org.uk>

* src/xlat/rxrpc_cmsg_types.in: New file
* src/msghdr.c (print_cmsg_rxrpc_user_call_id, print_cmsg_ullong):
  New functions.
* NEWS: Mention this change.

Signed-off-by: David Howells <dhowells at redhat.com>
---
 NEWS                         |    1 
 src/msghdr.c                 |   68 +++++++++++++++++++++++++++++++++++++++++++
 src/xlat/rxrpc_cmsg_types.in |   15 +++++++++
 3 files changed, 84 insertions(+)

diff --git a/NEWS b/NEWS
index 6cdeb64a5..5c237a6ce 100644
--- a/NEWS
+++ b/NEWS
@@ -14,6 +14,7 @@ Noteworthy changes in release ?.? (????-??-??)
   * Implemented decoding of IFLA_BRPORT_MCAST_N_GROUPS,
     IFLA_BRPORT_MCAST_MAX_GROUPS, IFLA_GSO_IPV4_MAX_SIZE,
     IFLA_GRO_IPV4_MAX_SIZE, and TCA_EXT_WARN_MSG netlink attributes.
+  * Implemented decoding of RXRPC_* control messages.
   * Updated lists of F_SEAL_*, IFLA_*, IORING_*, MFD_*, NFT_*, TCA_*,
     and V4L2_PIX_FMT_* constants.
   * Updated lists of ioctl commands from Linux 6.3.
diff --git a/src/msghdr.c b/src/msghdr.c
index cbcb8b9a4..882875242 100644
--- a/src/msghdr.c
+++ b/src/msghdr.c
@@ -22,6 +22,7 @@
 #include "xlat/msg_flags.h"
 #include "xlat/scmvals.h"
 #include "xlat/ip_cmsg_types.h"
+#include "xlat/rxrpc_cmsg_types.h"
 
 #ifndef current_wordsize
 struct cmsghdr32 {
@@ -159,6 +160,16 @@ print_cmsg_uint(struct tcb *tcp, const void *cmsg_data,
 			     print_uint_array_member, NULL, 0, NULL, NULL);
 }
 
+static void
+print_cmsg_xint(struct tcb *tcp, const void *cmsg_data,
+		const unsigned int data_len)
+{
+	const unsigned int *p = cmsg_data;
+
+	print_local_array_ex(tcp, p, data_len / sizeof(*p), sizeof(*p),
+			     print_xint_array_member, NULL, 0, NULL, NULL);
+}
+
 static void
 print_cmsg_xint8_t(struct tcb *tcp, const void *cmsg_data,
 		   const unsigned int data_len)
@@ -167,6 +178,16 @@ print_cmsg_xint8_t(struct tcb *tcp, const void *cmsg_data,
 			     print_xint_array_member, NULL, 0, NULL, NULL);
 }
 
+static void
+print_cmsg_ullong(struct tcb *tcp, const void *cmsg_data,
+		  const unsigned int data_len)
+{
+	const unsigned long long *p = cmsg_data;
+
+	print_local_array_ex(tcp, p, data_len / sizeof(*p), sizeof(*p),
+			     print_uint_array_member, NULL, 0, NULL, NULL);
+}
+
 struct sock_ee {
 	uint32_t ee_errno;
 	uint8_t  ee_origin;
@@ -212,6 +233,30 @@ print_cmsg_ip_origdstaddr(struct tcb *tcp, const void *cmsg_data,
 	print_sockaddr(tcp, cmsg_data, addr_len);
 }
 
+static void
+print_cmsg_rxrpc_user_call_id(struct tcb *tcp, const void *cmsg_data,
+			      const unsigned int data_len)
+{
+	const unsigned int *p = cmsg_data;
+
+	/* Size is "unsigned long" but we might be stracing a 32-bit program
+	 * from a 64-bit strace or vice versa.
+	 */
+	switch (data_len) {
+	case 4:
+		print_local_array_ex(tcp, p, 1, 4,
+				     print_xint_array_member, NULL, 0, NULL, NULL);
+		break;
+	case 8:
+		print_local_array_ex(tcp, p, 1, 8,
+				     print_xint_array_member, NULL, 0, NULL, NULL);
+		break;
+	default:
+		print_cmsg_xint(tcp, cmsg_data, data_len);
+		break;
+	}
+}
+
 typedef void (* const cmsg_printer)(struct tcb *, const void *, unsigned int);
 
 static const struct {
@@ -237,6 +282,19 @@ static const struct {
 	[IP_ORIGDSTADDR] = { print_cmsg_ip_origdstaddr, sizeof(struct sockaddr_in) },
 	[IP_CHECKSUM] = { print_cmsg_uint, sizeof(unsigned int) },
 	[SCM_SECURITY] = { print_scm_security, 1 }
+}, cmsg_rxrpc_printers[] = {
+	[RXRPC_USER_CALL_ID]	= { print_cmsg_rxrpc_user_call_id, sizeof(unsigned int) },
+	[RXRPC_ABORT]		= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_ACK]		= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_NET_ERROR]	= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_BUSY]		= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_LOCAL_ERROR]	= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_NEW_CALL]	= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_EXCLUSIVE_CALL]	= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_UPGRADE_SERVICE]	= { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_TX_LENGTH]	= { print_cmsg_ullong, sizeof(unsigned long long) },
+	[RXRPC_SET_CALL_TIMEOUT] = { print_cmsg_uint, sizeof(unsigned int) },
+	[RXRPC_CHARGE_ACCEPT]	= { print_cmsg_uint, sizeof(unsigned int) },
 };
 
 static void
@@ -265,6 +323,16 @@ print_cmsg_type_data(struct tcb *tcp, const int cmsg_level, const int cmsg_type,
 			cmsg_ip_printers[utype].printer(tcp, cmsg_data, data_len);
 		}
 		break;
+	case SOL_RXRPC:
+		printxval(rxrpc_cmsg_types, cmsg_type, "RXRPC_???");
+		if (utype < ARRAY_SIZE(cmsg_rxrpc_printers)
+		    && cmsg_rxrpc_printers[utype].printer
+		    && data_len >= cmsg_rxrpc_printers[utype].min_len) {
+			tprint_struct_next();
+			tprints_field_name("cmsg_data");
+			cmsg_rxrpc_printers[utype].printer(tcp, cmsg_data, data_len);
+		}
+		break;
 	default:
 		PRINT_VAL_X(cmsg_type);
 	}
diff --git a/src/xlat/rxrpc_cmsg_types.in b/src/xlat/rxrpc_cmsg_types.in
new file mode 100644
index 000000000..474034e69
--- /dev/null
+++ b/src/xlat/rxrpc_cmsg_types.in
@@ -0,0 +1,15 @@
+#value_indexed
+RXRPC_USER_CALL_ID	1
+RXRPC_ABORT		2
+RXRPC_ACK		3
+RXRPC_RESPONSE		4
+RXRPC_NET_ERROR		5
+RXRPC_BUSY		6
+RXRPC_LOCAL_ERROR	7
+RXRPC_NEW_CALL		8
+RXRPC_ACCEPT		9
+RXRPC_EXCLUSIVE_CALL	10
+RXRPC_UPGRADE_SERVICE	11
+RXRPC_TX_LENGTH		12
+RXRPC_SET_CALL_TIMEOUT	13
+RXRPC_CHARGE_ACCEPT	14



From dhowells at redhat.com  Wed May 31 10:02:05 2023
From: dhowells at redhat.com (David Howells)
Date: Wed, 31 May 2023 18:02:05 +0100
Subject: How to get my krb5 crypto lib upstream?
Message-ID: <723506.1685552525@warthog.procyon.org.uk>

Hi Herbert, Chuck,

I'm wondering how to make progress on getting my krb5 crypto lib upstream.

Can I push it as it stands and then we try and build it into the crypto API
for it later?  That would allow me to push my rxgk implementation for AF_RXRPC
and at least allow userspace to use that.

As far as building a crypto API around it goes, we need four interfaces:

 (1) Key generation.  We may need to generate a {cipher,hash} key pair {Ke,Ki}
     or just a hash key Kc.  We might conceivably want both.

     At the moment, I return a prepared cipher or a prepared hash.  I don't
     deal with the key pairing here as it makes testing a bit more awkward.

	int crypto_krb5_get_Kc(const struct krb5_enctype *krb5,
			       const struct krb5_buffer *TK,
			       u32 usage,
			       struct krb5_buffer *key,
			       struct crypto_shash **_shash,
			       gfp_t gfp);
	int crypto_krb5_get_Ke(const struct krb5_enctype *krb5,
			       const struct krb5_buffer *TK,
			       u32 usage,
			       struct krb5_buffer *key,
			       struct crypto_sync_skcipher **_ci,
			       gfp_t gfp);
	int crypto_krb5_get_Ki(const struct krb5_enctype *krb5,
			       const struct krb5_buffer *TK,
			       u32 usage,
			       struct krb5_buffer *key,
			       struct crypto_shash **_shash,
			       gfp_t gfp);

 (2) PRF+ generation.  This takes some a key and a metadata blob and generates
     a new blob that then gets used as a key.

	int crypto_krb5_calc_PRFplus(const struct krb5_enctype *krb5,
				     const struct krb5_buffer *K,
				     unsigned int L,
				     const struct krb5_buffer *S,
				     struct krb5_buffer *result,
				     gfp_t gfp);

 (3) Encrypt and Decrypt.

     Encrypt has to be parameterised to take a specific confounder for testing
     and generate a random one for normal operation.  The IV is fixed all
     zeroes in the cases I've implemented.  When testing, decrypt should
     perhaps be passed the confounder to check it.

     When encrypting, the output buffer will be larger than the input buffer
     (or, at least, room must be set aside) so that a confounder, padding and
     a checksum can be inserted.

     When decrypting, we either want to provide a separate output buffer so
     that the confounder and checksum can be stripped off, or we need to be
     able to find out where the decrypted payload plus the padding will be (we
     can't work out how much padding there is - that's left to the caller).

     At the moment, I pass a single buffer descriptor, providing encrypt with
     extra space front and back and providing decrypt with somewhere to save
     offset and length:

	ssize_t crypto_krb5_encrypt(const struct krb5_enctype *krb5,
				    struct krb5_enc_keys *keys,
				    struct scatterlist *sg, unsigned int nr_sg,
				    size_t sg_len,
				    size_t data_offset, size_t data_len,
				    bool preconfounded);
	int crypto_krb5_decrypt(const struct krb5_enctype *krb5,
				struct krb5_enc_keys *keys,
				struct scatterlist *sg, unsigned int nr_sg,
				size_t *_offset, size_t *_len,
				int *_error_code);

     I also allow a krb5/gssapi error code to be returned so that it can be
     used in the generation of abort messages.  This needs sorting out
     better.  It may be that only one code is actually relevant to this and
     that the caller generates all the rest as it checks the metadata.

     The AEAD interface might suffice as it stands if we pass in the keys
     already generated and passed in as a single key blob.  We don't want an
     IV generator as the protocol defines the IV to use.

 (4) GetMIC and VerifyMIC.

     Both of these need parameterising with extra metadata that will get
     inserted into the hash before the data is hashed.  GetMIC will insert the
     checksum into the buffer and VerifyMIC will check it and strip it off.

     I'm not sure that the hash API is suitable for this.  AEAD might suit for
     GetMIC at least, but using AEAD for VerifyMIC would lead to an extraneous
     copy I'd prefer to avoid.


	ssize_t crypto_krb5_get_mic(const struct krb5_enctype *krb5,
				    struct crypto_shash *shash,
				    const struct krb5_buffer *metadata,
				    struct scatterlist *sg, unsigned int nr_sg,
				    size_t sg_len,
				    size_t data_offset, size_t data_len);
	int crypto_krb5_verify_mic(const struct krb5_enctype *krb5,
				   struct crypto_shash *shash,
				   const struct krb5_buffer *metadata,
				   struct scatterlist *sg, unsigned int nr_sg,
				   size_t *_offset, size_t *_len,
				   int *_error_code);

There's a lot to be said in using an asynchronous overrideable interface for
encrypt and decrypt.  The problem is that we want to do simultaneous hash and
crypt if we can.  I think the Intel AES/SHA instructions permit this to be
done and there is sufficient register space to do it - and I *think* that it
may be possible to offload this to the Intel QAT or the Intel IAA on the
latest 4th Gen Xeons - and maybe NICs that can handle NFS/SMB offload.

I think we'll perhaps need a "krb5 encoding type" API that can provide key
derivation, PRF+ and information - something along the following lines:

	struct krb5_enctype {
		int		etype;		// Encryption (key) type
		int		ctype;		// Checksum type
		const char	*name;		// "Friendly" name
		const char	*encrypt_name;	// Crypto encrypt name
		const char	*cksum_name;	// Crypto checksum name
		const char	*hash_name;	// Crypto hash name
		u16		block_len;	// Length of encryption block
		u16		conf_len;	// Length of confounder
		u16		cksum_len;	// Length of checksum
		u16		key_bytes;	// Length of raw key
		u16		key_len;	// Length of final key
		u16		hash_len;	// Length of hash
		u16		prf_len;	// Length of PRF() result
		u16		Kc_len;		// Length of Kc
		u16		Ke_len;		// Length of Ke
		u16		Ki_len;		// Length of Ki
		bool		keyed_cksum;	// T if a keyed cksum
		bool		pad;		// T if should pad
	};

We need to be able to look the encoding up by ID, not by name.

David



From chuck.lever at oracle.com  Wed May 31 12:08:28 2023
From: chuck.lever at oracle.com (Chuck Lever III)
Date: Wed, 31 May 2023 19:08:28 +0000
Subject: How to get my krb5 crypto lib upstream?
In-Reply-To: <723506.1685552525@warthog.procyon.org.uk>
References: <723506.1685552525@warthog.procyon.org.uk>
Message-ID: <8C32DD7C-719D-4CC5-A1E3-33BCE0A7FEFF@oracle.com>



> On May 31, 2023, at 1:02 PM, David Howells <dhowells at redhat.com> wrote:
> 
> Hi Herbert, Chuck,
> 
> I'm wondering how to make progress on getting my krb5 crypto lib upstream.
> 
> Can I push it as it stands and then we try and build it into the crypto API
> for it later?  That would allow me to push my rxgk implementation for AF_RXRPC
> and at least allow userspace to use that.

Sharing our private conversation during LSF here:

My feeling is crypto/krb5 needs at least one consumer, and
it makes sense for the first one to be AFS.

Once crypto/krb5 is in the tree, I'll be glad to look at
starting to replace the internals of the SunRPC GSS Kerberos
mechanism with what is provided in crypto/krb5.

However, if there is going to be significant API churn after
crypto/krb5 lands, I'd like to wait until that stabilizes
before adopting major pieces of crypto/krb5 in SunRPC.


> As far as building a crypto API around it goes, we need four interfaces:
> 
> (1) Key generation.  We may need to generate a {cipher,hash} key pair {Ke,Ki}
>     or just a hash key Kc.  We might conceivably want both.
> 
>     At the moment, I return a prepared cipher or a prepared hash.  I don't
>     deal with the key pairing here as it makes testing a bit more awkward.
> 
> int crypto_krb5_get_Kc(const struct krb5_enctype *krb5,
>       const struct krb5_buffer *TK,
>       u32 usage,
>       struct krb5_buffer *key,
>       struct crypto_shash **_shash,
>       gfp_t gfp);
> int crypto_krb5_get_Ke(const struct krb5_enctype *krb5,
>       const struct krb5_buffer *TK,
>       u32 usage,
>       struct krb5_buffer *key,
>       struct crypto_sync_skcipher **_ci,
>       gfp_t gfp);
> int crypto_krb5_get_Ki(const struct krb5_enctype *krb5,
>       const struct krb5_buffer *TK,
>       u32 usage,
>       struct krb5_buffer *key,
>       struct crypto_shash **_shash,
>       gfp_t gfp);
> 
> (2) PRF+ generation.  This takes some a key and a metadata blob and generates
>     a new blob that then gets used as a key.
> 
> int crypto_krb5_calc_PRFplus(const struct krb5_enctype *krb5,
>     const struct krb5_buffer *K,
>     unsigned int L,
>     const struct krb5_buffer *S,
>     struct krb5_buffer *result,
>     gfp_t gfp);
> 
> (3) Encrypt and Decrypt.
> 
>     Encrypt has to be parameterised to take a specific confounder for testing
>     and generate a random one for normal operation.  The IV is fixed all
>     zeroes in the cases I've implemented.  When testing, decrypt should
>     perhaps be passed the confounder to check it.
> 
>     When encrypting, the output buffer will be larger than the input buffer
>     (or, at least, room must be set aside) so that a confounder, padding and
>     a checksum can be inserted.
> 
>     When decrypting, we either want to provide a separate output buffer so
>     that the confounder and checksum can be stripped off, or we need to be
>     able to find out where the decrypted payload plus the padding will be (we
>     can't work out how much padding there is - that's left to the caller).
> 
>     At the moment, I pass a single buffer descriptor, providing encrypt with
>     extra space front and back and providing decrypt with somewhere to save
>     offset and length:
> 
> ssize_t crypto_krb5_encrypt(const struct krb5_enctype *krb5,
>    struct krb5_enc_keys *keys,
>    struct scatterlist *sg, unsigned int nr_sg,
>    size_t sg_len,
>    size_t data_offset, size_t data_len,
>    bool preconfounded);
> int crypto_krb5_decrypt(const struct krb5_enctype *krb5,
> struct krb5_enc_keys *keys,
> struct scatterlist *sg, unsigned int nr_sg,

So are we going to stick with struct scatterlist here,
or should it be rather an iterator of some kind?


> size_t *_offset, size_t *_len,
> int *_error_code);
> 
>     I also allow a krb5/gssapi error code to be returned so that it can be
>     used in the generation of abort messages.  This needs sorting out
>     better.  It may be that only one code is actually relevant to this and
>     that the caller generates all the rest as it checks the metadata.
> 
>     The AEAD interface might suffice as it stands if we pass in the keys
>     already generated and passed in as a single key blob.  We don't want an
>     IV generator as the protocol defines the IV to use.
> 
> (4) GetMIC and VerifyMIC.
> 
>     Both of these need parameterising with extra metadata that will get
>     inserted into the hash before the data is hashed.  GetMIC will insert the
>     checksum into the buffer and VerifyMIC will check it and strip it off.
> 
>     I'm not sure that the hash API is suitable for this.  AEAD might suit for
>     GetMIC at least, but using AEAD for VerifyMIC would lead to an extraneous
>     copy I'd prefer to avoid.
> 
> 
> ssize_t crypto_krb5_get_mic(const struct krb5_enctype *krb5,
>    struct crypto_shash *shash,
>    const struct krb5_buffer *metadata,
>    struct scatterlist *sg, unsigned int nr_sg,
>    size_t sg_len,
>    size_t data_offset, size_t data_len);
> int crypto_krb5_verify_mic(const struct krb5_enctype *krb5,
>   struct crypto_shash *shash,
>   const struct krb5_buffer *metadata,
>   struct scatterlist *sg, unsigned int nr_sg,
>   size_t *_offset, size_t *_len,
>   int *_error_code);
> 
> There's a lot to be said in using an asynchronous overrideable interface for
> encrypt and decrypt.  The problem is that we want to do simultaneous hash and
> crypt if we can.  I think the Intel AES/SHA instructions permit this to be
> done and there is sufficient register space to do it - and I *think* that it
> may be possible to offload this to the Intel QAT or the Intel IAA on the
> latest 4th Gen Xeons - and maybe NICs that can handle NFS/SMB offload.

I agree that a hardware-based AES/SHA implementation of
encrypt/decrypt seems like a good step forward for storage
consumers like NFS and AFS. That could be a significant
benefit for switching SunRPC GSS to crypto/krb5.


> I think we'll perhaps need a "krb5 encoding type" API that can provide key
> derivation, PRF+ and information - something along the following lines:
> 
> struct krb5_enctype {
> int etype; // Encryption (key) type
> int ctype; // Checksum type
> const char *name; // "Friendly" name
> const char *encrypt_name; // Crypto encrypt name
> const char *cksum_name; // Crypto checksum name
> const char *hash_name; // Crypto hash name
> u16 block_len; // Length of encryption block
> u16 conf_len; // Length of confounder
> u16 cksum_len; // Length of checksum
> u16 key_bytes; // Length of raw key
> u16 key_len; // Length of final key
> u16 hash_len; // Length of hash
> u16 prf_len; // Length of PRF() result
> u16 Kc_len; // Length of Kc
> u16 Ke_len; // Length of Ke
> u16 Ki_len; // Length of Ki
> bool keyed_cksum; // T if a keyed cksum
> bool pad; // T if should pad
> };
> 
> We need to be able to look the encoding up by ID, not by name.

It's not clear why something like this would need to be
exposed to crypto/krb5 consumers. There are a few items
in here that XDR needs to know about (lengths and such)
but that kind of thing can be provided by a function
call rather than by having direct access to a structure.


--
Chuck Lever




From dhowells at redhat.com  Wed May 31 13:08:04 2023
From: dhowells at redhat.com (David Howells)
Date: Wed, 31 May 2023 21:08:04 +0100
Subject: How to get my krb5 crypto lib upstream?
In-Reply-To: <8C32DD7C-719D-4CC5-A1E3-33BCE0A7FEFF@oracle.com>
References: <8C32DD7C-719D-4CC5-A1E3-33BCE0A7FEFF@oracle.com> <723506.1685552525@warthog.procyon.org.uk>
Message-ID: <726863.1685563684@warthog.procyon.org.uk>

Chuck Lever III <chuck.lever at oracle.com> wrote:

> > int crypto_krb5_decrypt(const struct krb5_enctype *krb5,
> > struct krb5_enc_keys *keys,
> > struct scatterlist *sg, unsigned int nr_sg,
> 
> So are we going to stick with struct scatterlist here,
> or should it be rather an iterator of some kind?

For my purposes, a scatterlist is more useful as I have an skbuff to work
with - plus I have to pass a scatterlist into the crypto functions inside of
the krb5 lib.

> It's not clear why something like this would need to be
> exposed to crypto/krb5 consumers. There are a few items
> in here that XDR needs to know about (lengths and such)
> but that kind of thing can be provided by a function
> call rather than by having direct access to a structure.

Fair point.  In rxgk, I use key_len, key_bytes, block_len, cksum_len plus the
name for procfs purposes.  I also wonder if I need separate key_len and
key_bytes if I'm not supporting DES (DES keys gets expanded IIRC).  Also, some
of the checks I'm doing could perhaps be moved into the krb5 lib.

The krb5 selftest code makes use of more of the fields, but I guess that's
internal to krb5lib.

David



From dhowells at redhat.com  Wed May 31 15:50:12 2023
From: dhowells at redhat.com (David Howells)
Date: Wed, 31 May 2023 23:50:12 +0100
Subject: [PATCH] afs: Fix setting of mtime when creating a file/dir/symlink
Message-ID: <808140.1685573412@warthog.procyon.org.uk>

    
kafs incorrectly passes a zero mtime (ie. 1st Jan 1970) to the server when
creating a file, dir or symlink because commit 52af7105eceb caused the
mtime recorded in the afs_operation struct to be passed to the server, but
didn't modify the afs_mkdir(), afs_create() and afs_symlink() functions to
set it first.

Those functions were written with the assumption that the mtime would be
obtained from the server - but that fell foul of malsynchronised clocks, so
it was decided that the mtime should be set from the client instead.

Fix this by filling in op->mtime before calling the create op.

Fixes: 52af7105eceb ("afs: Set mtime from the client for yfs create operations")
Signed-off-by: David Howells <dhowells at redhat.com>
cc: Marc Dionne <marc.dionne at auristor.com>
cc: linux-afs at lists.infradead.org
cc: linux-fsdevel at vger.kernel.org
---
 fs/afs/dir.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/afs/dir.c b/fs/afs/dir.c
index 4dd97afa536c..5219182e52e1 100644
--- a/fs/afs/dir.c
+++ b/fs/afs/dir.c
@@ -1358,6 +1358,7 @@ static int afs_mkdir(struct mnt_idmap *idmap, struct inode *dir,
 	op->dentry	= dentry;
 	op->create.mode	= S_IFDIR | mode;
 	op->create.reason = afs_edit_dir_for_mkdir;
+	op->mtime	= current_time(dir);
 	op->ops		= &afs_mkdir_operation;
 	return afs_do_sync_operation(op);
 }
@@ -1661,6 +1662,7 @@ static int afs_create(struct mnt_idmap *idmap, struct inode *dir,
 	op->dentry	= dentry;
 	op->create.mode	= S_IFREG | mode;
 	op->create.reason = afs_edit_dir_for_create;
+	op->mtime	= current_time(dir);
 	op->ops		= &afs_create_operation;
 	return afs_do_sync_operation(op);
 
@@ -1796,6 +1798,7 @@ static int afs_symlink(struct mnt_idmap *idmap, struct inode *dir,
 	op->ops			= &afs_symlink_operation;
 	op->create.reason	= afs_edit_dir_for_symlink;
 	op->create.symlink	= content;
+	op->mtime		= current_time(dir);
 	return afs_do_sync_operation(op);
 
 error:



From jaltman at auristor.com  Wed May 31 17:14:02 2023
From: jaltman at auristor.com (Jeffrey E Altman)
Date: Wed, 31 May 2023 20:14:02 -0400
Subject: How to get my krb5 crypto lib upstream?
In-Reply-To: <726863.1685563684@warthog.procyon.org.uk>
References: <8C32DD7C-719D-4CC5-A1E3-33BCE0A7FEFF@oracle.com>
 <723506.1685552525@warthog.procyon.org.uk>
 <726863.1685563684@warthog.procyon.org.uk>
Message-ID: <83d7f550-7216-6ff4-bc8a-859e752e12a3@auristor.com>

On 5/31/2023 4:08 PM, David Howells wrote:
> Fair point.  In rxgk, I use key_len, key_bytes, block_len, cksum_len plus the
> name for procfs purposes.  I also wonder if I need separate key_len and
> key_bytes if I'm not supporting DES (DES keys gets expanded IIRC).  Also, some
> of the checks I'm doing could perhaps be moved into the krb5 lib.

The "K" in RXGK is RFC3961 without support for weak ciphers.? No DES, no 
3DES
and no RC4-HMAC.?? DES keys are never expanded.

The supported ciphers are

  * aes128-cts-hmac-sha1-96 (RFC3962)
  * aes256-cts-hmac-sha1-96 (RFC3962)
  * aes128-cts-hmac-sha256-128? (RFC8009)
  * aes256-cts-hmac-sha384-192? (RFC8009)

There are other Kerberos ciphers that could be used with RXGK but there 
are no RXGK server implementations that use them.?? None of the RFC3961 
ciphers or the RFC3961 interfaces support AEAD modes.

Luke Howard proposed "AEAD Encryption Types for Kerberos 5" 
https://datatracker.ietf.org/doc/draft-howard-krb-aead/ to IETF Kitten 
which would add AES128 and AES256 GCM, CCM, and OCB modes. However, 
there is some resistance to these additions because at the moment all 
RFC3961 ciphers are safe for use with long term keys and repeating 
cipher state; AEAD modes are not.

RXGK can be constrained such that it is safe for use with AEAD modes and 
I would like to see Luke's draft be adopted if only because CTS-HMAC is 
not supported by Intel QAT and GCM is. Adoption of Luke's draft would 
not only benefit AuriStorFS but NFSv4 gss-krb5 as well.

My suggestion is that the kernel should provide an RFC3961 API for use 
by gss_krb5 applications.?? AEAD modes can be added to that if and when 
Luke's draft is adopted.

Jeffrey Altman



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4039 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20230531/f2fd37d0/attachment.p7s>

From jaltman at auristor.com  Wed May 31 17:15:33 2023
From: jaltman at auristor.com (Jeffrey E Altman)
Date: Wed, 31 May 2023 20:15:33 -0400
Subject: [PATCH] afs: Fix setting of mtime when creating a
 file/dir/symlink
In-Reply-To: <808140.1685573412@warthog.procyon.org.uk>
References: <808140.1685573412@warthog.procyon.org.uk>
Message-ID: <7546a4b2-7421-990c-3165-bda80c637127@auristor.com>

On 5/31/2023 6:50 PM, David Howells wrote:
>      
> kafs incorrectly passes a zero mtime (ie. 1st Jan 1970) to the server when
> creating a file, dir or symlink because commit 52af7105eceb caused the
> mtime recorded in the afs_operation struct to be passed to the server, but
> didn't modify the afs_mkdir(), afs_create() and afs_symlink() functions to
> set it first.
>
> Those functions were written with the assumption that the mtime would be
> obtained from the server - but that fell foul of malsynchronised clocks, so
> it was decided that the mtime should be set from the client instead.
>
> Fix this by filling in op->mtime before calling the create op.
>
> Fixes: 52af7105eceb ("afs: Set mtime from the client for yfs create operations")
> Signed-off-by: David Howells <dhowells at redhat.com>
> cc: Marc Dionne <marc.dionne at auristor.com>
> cc: linux-afs at lists.infradead.org
> cc: linux-fsdevel at vger.kernel.org
> ---
>   fs/afs/dir.c |    3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/fs/afs/dir.c b/fs/afs/dir.c
> index 4dd97afa536c..5219182e52e1 100644
> --- a/fs/afs/dir.c
> +++ b/fs/afs/dir.c
> @@ -1358,6 +1358,7 @@ static int afs_mkdir(struct mnt_idmap *idmap, struct inode *dir,
>   	op->dentry	= dentry;
>   	op->create.mode	= S_IFDIR | mode;
>   	op->create.reason = afs_edit_dir_for_mkdir;
> +	op->mtime	= current_time(dir);
>   	op->ops		= &afs_mkdir_operation;
>   	return afs_do_sync_operation(op);
>   }
> @@ -1661,6 +1662,7 @@ static int afs_create(struct mnt_idmap *idmap, struct inode *dir,
>   	op->dentry	= dentry;
>   	op->create.mode	= S_IFREG | mode;
>   	op->create.reason = afs_edit_dir_for_create;
> +	op->mtime	= current_time(dir);
>   	op->ops		= &afs_create_operation;
>   	return afs_do_sync_operation(op);
>   
> @@ -1796,6 +1798,7 @@ static int afs_symlink(struct mnt_idmap *idmap, struct inode *dir,
>   	op->ops			= &afs_symlink_operation;
>   	op->create.reason	= afs_edit_dir_for_symlink;
>   	op->create.symlink	= content;
> +	op->mtime		= current_time(dir);
>   	return afs_do_sync_operation(op);
>   
>   error:
>
Reviewed-by: Jeffrey Altman <jaltman at auristor.com>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4039 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20230531/8143f712/attachment.p7s>

From David.Laight at ACULAB.COM  Mon May 29 06:32:02 2023
From: David.Laight at ACULAB.COM (David Laight)
Date: Mon, 29 May 2023 13:32:02 +0000
Subject: [PATCH] Remove hardcoded static string length
In-Reply-To: <c22f76b1-0559-410f-38f2-266e1a9fcca5@auristor.com>
References: <20230523223944.691076-1-Kenny.Ho@amd.com>
 <01936d68-85d3-4d20-9beb-27ff9f62d826@lunn.ch>
 <CAB9dFdt4-cBFhEqsTXk9suE+Bw-xcpM0n3Q6rFmBaa+8A5uMWQ@mail.gmail.com>
 <c0fda91b-1e98-420f-a18a-16bbed25e98d@lunn.ch>
 <CAOWid-erNGD24Ouf4fAJJBqm69QVoHOpNt0E-G+Wt=nq1W4oBQ@mail.gmail.com>
 <5b1355b8-17f7-49c8-b7b5-3d9ecdb146ce@lunn.ch>
 <CAOWid-dYtkcKuNxoOyf3yqSJ7OtcNjaqJLVX1QhRUhYSOO6vHA@mail.gmail.com>
 <30d65ea9170d4f60bd76ed516541cb46@AcuMS.aculab.com>
 <CAOWid-eEbeeU9mOpwgOatt5rHQhRt+xPrsQ1fsMemVZDdeN=MQ@mail.gmail.com>
 <81d01562a59a4fb49cd4681ebcf2e74a@AcuMS.aculab.com>
 <CAOWid-d=OFn7JS5JvsK9qc7X6HeZgOm5OAd1_g2=_GZgpKRZnA@mail.gmail.com>
 <c22f76b1-0559-410f-38f2-266e1a9fcca5@auristor.com>
Message-ID: <9ef0c93114814352877825321e9e2826@AcuMS.aculab.com>

From: Jeffrey E Altman
> Sent: 27 May 2023 16:09
> 
> On 5/25/2023 11:37 AM, Kenny Ho wrote:
> > On Thu, May 25, 2023 at 11:04?AM David Laight<David.Laight at aculab.com>  wrote:
> >>> "The standard formulation seems to be: <project> <version> built
> >>> <yyyy>-<mm>-<dd>"
> >> Which I don't recall the string actually matching?
> >> Also the people who like reproducible builds don't like __DATE__.
> > That's correct, it was not matching even when it was introduced.  I am
> > simply taking that as people caring about the content and not simply
> > making rxrpc_version_string == UTS_RELEASE.  The current format is:
> >
> > "linux-" UTS_RELEASE " AF_RXRPC"
> >
> > Kenny
> 
> The RX_PACKET_TYPE_VERSION query is issued by the "rxdebug <host> <port>
> -version" command which prints the received string to stdout.?? It has
> also been used some implementations to record the version of the peer.
> Although it is required that a response to the RX_PACKET_TYPE_VERSION
> query be issued, there is no requirement that the returned string
> contain anything beyond a single NUL octet.

Does that mean that the zero-padding/truncation to 65 bytes is bogus?
Additionally is the response supposed to the '\0' terminated?
The existing code doesn't guarantee that at all.

> Although it is convenient to be able to remotely identify the version of
> an Rx implementation, there are good reasons why this information should
> not be exposed to an anonymous requester:
> 
>  1. Linux AF_RXRPC is part of the kernel.? As such, returning
>     UTS_RELEASE identifies to potential attackers the explicit kernel
>     version, architecture and perhaps distro.? As this query can be
>     issued anonymously, this provides an information disclosure that can
>     be used to target known vulnerabilities in the kernel.

I guess it could even be used as a probe to find more/interesting
systems to attack once inside the firewall.

>  2. The RX_PACKET_TYPE_VERSION reply is larger than the query by the
>     number of octets in the version data.? As the query is received via
>     udp with no reachability test, it means that the
>     RX_PACKET_TYPE_VERSION query/response can be used to perform an 3.3x
>     amplification attack: 28 octets in and potentially 93 octets out.
> 
> With my security hat on I would suggest that either AF_RXRPC return a
> single NUL octet or the c-string "AF_RXRPC" and nothing more.

Is there any point including "AF_RXRPC"?
It is almost certainly implied by the message format.

Or the exact text from the standard - which might be:
  "version string - to be supplied by O.E.M."
(I've seen hardware versions with strings like the above that
exactly match the datasheet....)

Limiting the version to (eg) 6.2 would give a hint to the
capabilities/bugs without giving away all the relative addresses
in something like a RHEL kernel.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

From patchwork-bot+netdevbpf at kernel.org  Tue May 30 01:10:20 2023
From: patchwork-bot+netdevbpf at kernel.org (patchwork-bot+netdevbpf at kernel.org)
Date: Tue, 30 May 2023 08:10:20 +0000
Subject: [PATCH net] rxrpc: Truncate UTS_RELEASE for rxrpc version 
In-Reply-To: <654974.1685100894@warthog.procyon.org.uk>
References: <654974.1685100894@warthog.procyon.org.uk>
Message-ID: <168543422022.28448.2604307451072571667.git-patchwork-notify@kernel.org>

Hello:

This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni at redhat.com>:

On Fri, 26 May 2023 12:34:54 +0100 you wrote:
> UTS_RELEASE has a maximum length of 64 which can cause rxrpc_version to
> exceed the 65 byte message limit.
> 
> Per the rx spec[1]: "If a server receives a packet with a type value of 13,
> and the client-initiated flag set, it should respond with a 65-byte payload
> containing a string that identifies the version of AFS software it is
> running."
> 
> [...]

Here is the summary with links:
  - [net] rxrpc: Truncate UTS_RELEASE for rxrpc version
    https://git.kernel.org/netdev/net/c/020c69c1a793

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




From jaltman at auristor.com  Tue May 30 07:39:29 2023
From: jaltman at auristor.com (Jeffrey E Altman)
Date: Tue, 30 May 2023 10:39:29 -0400
Subject: [PATCH] Remove hardcoded static string length
In-Reply-To: <9ef0c93114814352877825321e9e2826@AcuMS.aculab.com>
References: <20230523223944.691076-1-Kenny.Ho@amd.com>
 <01936d68-85d3-4d20-9beb-27ff9f62d826@lunn.ch>
 <CAB9dFdt4-cBFhEqsTXk9suE+Bw-xcpM0n3Q6rFmBaa+8A5uMWQ@mail.gmail.com>
 <c0fda91b-1e98-420f-a18a-16bbed25e98d@lunn.ch>
 <CAOWid-erNGD24Ouf4fAJJBqm69QVoHOpNt0E-G+Wt=nq1W4oBQ@mail.gmail.com>
 <5b1355b8-17f7-49c8-b7b5-3d9ecdb146ce@lunn.ch>
 <CAOWid-dYtkcKuNxoOyf3yqSJ7OtcNjaqJLVX1QhRUhYSOO6vHA@mail.gmail.com>
 <30d65ea9170d4f60bd76ed516541cb46@AcuMS.aculab.com>
 <CAOWid-eEbeeU9mOpwgOatt5rHQhRt+xPrsQ1fsMemVZDdeN=MQ@mail.gmail.com>
 <81d01562a59a4fb49cd4681ebcf2e74a@AcuMS.aculab.com>
 <CAOWid-d=OFn7JS5JvsK9qc7X6HeZgOm5OAd1_g2=_GZgpKRZnA@mail.gmail.com>
 <c22f76b1-0559-410f-38f2-266e1a9fcca5@auristor.com>
 <9ef0c93114814352877825321e9e2826@AcuMS.aculab.com>
Message-ID: <8312d279-688b-4fe7-870e-8243a8f883fa@auristor.com>

On 5/29/2023 9:32 AM, David Laight wrote:
> From: Jeffrey E Altman
>> Sent: 27 May 2023 16:09
>>
>> On 5/25/2023 11:37 AM, Kenny Ho wrote:
>>> On Thu, May 25, 2023 at 11:04?AM David Laight<David.Laight at aculab.com>  wrote:
>>>>> "The standard formulation seems to be: <project> <version> built
>>>>> <yyyy>-<mm>-<dd>"
>>>> Which I don't recall the string actually matching?
>>>> Also the people who like reproducible builds don't like __DATE__.
>>> That's correct, it was not matching even when it was introduced.  I am
>>> simply taking that as people caring about the content and not simply
>>> making rxrpc_version_string == UTS_RELEASE.  The current format is:
>>>
>>> "linux-" UTS_RELEASE " AF_RXRPC"
>>>
>>> Kenny
>> The RX_PACKET_TYPE_VERSION query is issued by the "rxdebug <host> <port>
>> -version" command which prints the received string to stdout.?? It has
>> also been used some implementations to record the version of the peer.
>> Although it is required that a response to the RX_PACKET_TYPE_VERSION
>> query be issued, there is no requirement that the returned string
>> contain anything beyond a single NUL octet.
> Does that mean that the zero-padding/truncation to 65 bytes is bogus?

Its bogus.? The original code implemented in 1988 was very sloppy.? Over 
the years some of the sloppiness was misinterpreted as well thought out 
design decisions.

The CMU/Transarc/IBM rxdebug allocates a char[64] for the received 
version c-string.?? The original version wrote a 65 octets of a static 
productVersion c-string that was defined far away from the code that 
wrote it to the network.?? Over time, the productVersion c-string was 
changed from a fixed length c-string to a build time generated c-string 
that had variable length.? It could be shorter than 65-octets or longer 
(up to 2000 octets). However, the Rx code that wrote the version data to 
the wire continued to write 65-octets regardless of the size of the 
productVersion c-string.?? This was noticed after IBM AFS 3.6 was forked 
to form OpenAFS because the version strings became shorter.

OpenAFS 1.2 began the practice of constructing the responseData as follows:

1. Allocate a fixed size char[66] on the stack which I will call 
'responseData'

2. bzero responseData

3. copy the productVersion into responseData as follows
 ??? snprintf(responseData, sizeof(responseData), "%s", productVersion)

4. write 65 octets from responseData to the wire

This change (OpenAFS commit 902055cc97a8dd26a26af55778c0b3843de3cc70) 
addressed the problem of productVersion being shorter than 65-octets by 
writing a padded response but it did nothing to ensure that the response 
written to the network was NUL terminated if strlen(productVersion) >= 65.

The author of this commit also wrote the rx-spec.txt document that David 
Howells used as his source.

Its all bogus.? There is absolutely no requirement that a NUL padded 
buffer be sent.?? The response can be a valid c-string of any length 
with the only constraint being that the resulting udp packet should not 
be too large to deliver.

> Additionally is the response supposed to the '\0' terminated?
> The existing code doesn't guarantee that at all.

The IBM/Transarc/CMU derived RX stacks issue process the Get Version 
request as follows:

1. Allocate a versionBuffer on the stack to store the returned string.? 
In the original CMU/Transarc/IBM Rx stack this was char[64].

2. Issue RX_PACKET_TYPE_VERSION query which consists of a 28 octet Rx 
header with no data.

3. Read RX_PACKET_TYPE_VERSION response into a 1500 octet buffer and 
remember bytesRead

3a. If? bytesRead is less than 28 octets, its too small to be a Rx 
header, ignore it.

3b. If the Rx header contents do not match the query, discard it.

3c. The data response begins at &buffer[28] and will be (bytesRead - 28) 
octets.?? Copy MIN(sizeof(versionBuffer), (bytesRead - 28)) octets of 
the responseData to the versionBuffer.

4. NUL terminate the versionBuffer.? Note: prior to OpenAFS 1.6.23 this 
step was not performed which is why the sender should always NUL 
terminate the transmitted version data but this is a bug in the receiver 
and it is not required that the RX_PACKET_TYPE_VERSION response data be 
limited to a 64 octet c-string.

5. Do something with the contents of the versionBuffer such as
 ??? printf("AFS version: %s\n", versionBuffer);


>> Although it is convenient to be able to remotely identify the version of
>> an Rx implementation, there are good reasons why this information should
>> not be exposed to an anonymous requester:
>>
>>   1. Linux AF_RXRPC is part of the kernel.? As such, returning
>>      UTS_RELEASE identifies to potential attackers the explicit kernel
>>      version, architecture and perhaps distro.? As this query can be
>>      issued anonymously, this provides an information disclosure that can
>>      be used to target known vulnerabilities in the kernel.
> I guess it could even be used as a probe to find more/interesting
> systems to attack once inside the firewall.
Exactly.
>>   2. The RX_PACKET_TYPE_VERSION reply is larger than the query by the
>>      number of octets in the version data.? As the query is received via
>>      udp with no reachability test, it means that the
>>      RX_PACKET_TYPE_VERSION query/response can be used to perform an 3.3x
>>      amplification attack: 28 octets in and potentially 93 octets out.
>>
>> With my security hat on I would suggest that either AF_RXRPC return a
>> single NUL octet or the c-string "AF_RXRPC" and nothing more.
> Is there any point including "AF_RXRPC"?
> It is almost certainly implied by the message format.

There is no required message format.?? IBM AFS could be built such that 
the resulting version c-string was

 ? "@(#)CML not accessible: No version information"

which was shorter than 65 octets.

> Or the exact text from the standard - which might be:
>    "version string - to be supplied by O.E.M."
> (I've seen hardware versions with strings like the above that
> exactly match the datasheet....)

The rx-spec.txt was an attempt by an individual circa 2001 to document 
the RxRPC protocol from reading the OpenAFS source code. The document 
did not undergo peer review and the author did not have the benefit of 
access to the development history or experience 
developing/maintaining/extending an Rx implementation.?? It was an 
excellent first effort but it should not be considered gospel.

> Limiting the version to (eg) 6.2 would give a hint to the
> capabilities/bugs without giving away all the relative addresses
> in something like a RHEL kernel.

I would be fine with something like "Linux 6.2".

Jeffrey Altman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4039 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20230530/f4b849bb/attachment-0001.p7s>

