[PATCH net-next v5 15/16] sock: Remove ->sendpage*() in favour of sendmsg(MSG_SPLICE_PAGES)

Remove ->sendpage() and ->sendpage_locked(). sendmsg() with MSG_SPLICE_PAGES should be used instead. This allows multiple pages and multipage folios to be passed through. Signed-off-by: David Howells Acked-by: Marc Kleine-Budde # for net/can cc: "David S. Miller" cc: Eric Du

[PATCH net-next v5 16/16] net: Kill MSG_SENDPAGE_NOTLAST

Now that ->sendpage() has been removed, MSG_SENDPAGE_NOTLAST can be cleaned up. Things were converted to use MSG_MORE instead, but the protocol sendpage stubs still convert MSG_SENDPAGE_NOTLAST to MSG_MORE, which is now unnecessary. Signed-off-by: David Howells cc: "David S. Miller&qu

[PATCH net-next v4 14/15] sock: Remove ->sendpage*() in favour of sendmsg(MSG_SPLICE_PAGES)

Remove ->sendpage() and ->sendpage_locked(). sendmsg() with MSG_SPLICE_PAGES should be used instead. This allows multiple pages and multipage folios to be passed through. Signed-off-by: David Howells Acked-by: Marc Kleine-Budde # for net/can cc: "David S. Miller" cc: Eric Du

[PATCH net-next v4 15/15] net: Kill MSG_SENDPAGE_NOTLAST

Now that ->sendpage() has been removed, MSG_SENDPAGE_NOTLAST can be cleaned up. Things were converted to use MSG_MORE instead, but the protocol sendpage stubs still convert MSG_SENDPAGE_NOTLAST to MSG_MORE, which is now unnecessary. Signed-off-by: David Howells cc: "David S. Miller&qu

[PATCH net-next v3 18/18] net: Kill MSG_SENDPAGE_NOTLAST

Now that ->sendpage() has been removed, MSG_SENDPAGE_NOTLAST can be cleaned up. Things were converted to use MSG_MORE instead, but the protocol sendpage stubs still convert MSG_SENDPAGE_NOTLAST to MSG_MORE, which is now unnecessary. Signed-off-by: David Howells cc: "David S. Miller&qu

[PATCH net-next v3 17/18] sock: Remove ->sendpage*() in favour of sendmsg(MSG_SPLICE_PAGES)

Remove ->sendpage() and ->sendpage_locked(). sendmsg() with MSG_SPLICE_PAGES should be used instead. This allows multiple pages and multipage folios to be passed through. Signed-off-by: David Howells Acked-by: Marc Kleine-Budde # for net/can cc: "David S. Miller" cc: Eric Du

Re: [PATCH net-next v2 17/17] net: Kill MSG_SENDPAGE_NOTLAST

Willem de Bruijn wrote: > Is it intentional to add MSG_MORE here in this patch? > > I do see that patch 3 removes this branch: Yeah. I think I may have tcp_bpf a bit wrong with regard to handling MSG_MORE. How about the attached version of tcp_bpf_push()? I wonder if it's save to move the

[PATCH net-next v2 16/17] sock: Remove ->sendpage*() in favour of sendmsg(MSG_SPLICE_PAGES)

Remove ->sendpage() and ->sendpage_locked(). sendmsg() with MSG_SPLICE_PAGES should be used instead. This allows multiple pages and multipage folios to be passed through. Signed-off-by: David Howells Acked-by: Marc Kleine-Budde # for net/can cc: "David S. Miller" cc: Eric Du

[PATCH net-next v2 17/17] net: Kill MSG_SENDPAGE_NOTLAST

Now that ->sendpage() has been removed, MSG_SENDPAGE_NOTLAST can be cleaned up. Things were converted to use MSG_MORE instead, but the protocol sendpage stubs still convert MSG_SENDPAGE_NOTLAST to MSG_MORE, which is now unnecessary. Signed-off-by: David Howells cc: "David S. Miller&qu

[PATCH net-next 16/17] sock: Remove ->sendpage*() in favour of sendmsg(MSG_SPLICE_PAGES)

Remove ->sendpage() and ->sendpage_locked(). sendmsg() with MSG_SPLICE_PAGES should be used instead. This allows multiple pages and multipage folios to be passed through. Signed-off-by: David Howells Acked-by: Marc Kleine-Budde # for net/can cc: "David S. Miller" cc: Eric Du

[PATCH v3 55/55] sock: Remove ->sendpage*() in favour of sendmsg(MSG_SPLICE_PAGES)

Remove ->sendpage() and ->sendpage_locked(). sendmsg() with MSG_SPLICE_PAGES should be used instead. This allows multiple pages and multipage folios to be passed through. Signed-off-by: David Howells Acked-by: Marc Kleine-Budde # for net/can cc: "David S. Miller" cc: Eric Du

Re: [RFC PATCH v2 48/48] sock: Remove ->sendpage*() in favour of sendmsg(MSG_SPLICE_PAGES)

Hannes Reinecke wrote: > > [!] Note: This is a work in progress. At the moment, some things won't > > build if this patch is applied. nvme, kcm, smc, tls. Actually, that needs updating. nvme and smc now build. > Weelll ... what happens to consumers of kernel_sendpage()? > (Let's call

[RFC PATCH v2 48/48] sock: Remove ->sendpage*() in favour of sendmsg(MSG_SPLICE_PAGES)

passed through. Signed-off-by: David Howells Acked-by: Marc Kleine-Budde # for net/can cc: "David S. Miller" cc: Eric Dumazet cc: Jakub Kicinski cc: Paolo Abeni cc: Jens Axboe cc: Matthew Wilcox cc: b...@vger.kernel.org cc: d...@vger.kernel.org cc: linux-...@lists.infradead.o

[RFC PATCH 1/3] net: Drop the size argument from ->sendmsg()

The size argument to ->sendmsg() ought to be redundant as the same information should be conveyed by msg->msg_iter.count as returned by msg_data_left(). Signed-off-by: David Howells cc: Eric Dumazet cc: "David S. Miller" cc: Jakub Kicinski cc: Paolo Abeni cc: net...@vger.kern

[RFC PATCH 28/28] sock: Remove ->sendpage*() in favour of sendmsg(MSG_SPLICE_PAGES)

passed through. Signed-off-by: David Howells cc: "David S. Miller" cc: Eric Dumazet cc: Jakub Kicinski cc: Paolo Abeni cc: Jens Axboe cc: Matthew Wilcox cc: b...@vger.kernel.org cc: d...@vger.kernel.org cc: linux-...@lists.infradead.org cc: linux-arm-...@vger.kernel.org cc: linux-...

[RFC][PATCH v2] splice: Prevent gifting of multipage folios

with a multipage folio. Try to avoid this by making add_to_pipe() remove the gift flag on multipage folios. Fixes: 7afa6fd037e5 ("[PATCH] vmsplice: allow user to pass in gift pages") Signed-off-by: David Howells cc: Matthew Wilcox cc: Jens Axboe cc: Miklos Szeredi cc: Amit Shah cc:

Re: [RFC][PATCH] splice: Prevent gifting of multipage folios

Matthew Wilcox wrote: > What should the Fixes: here be? This was already possible with THPs > (both anon and tmpfs backed) long before I introduced folios. Good question. How do I tell when THPs were introduced? It looks like they might predate git, looking at free_compound_page()'s comment.

[RFC][PATCH] splice: Prevent gifting of multipage folios

with a multipage folio. Try to avoid this by making add_to_pipe() remove the gift flag on multipage folios. Signed-off-by: David Howells cc: Matthew Wilcox cc: Miklos Szeredi cc: Amit Shah cc: linux-fsde...@vger.kernel.org cc: virtualization@lists.linux-foundation.org cc: linux...@kvack.org --- fs/splice.c

Re: [PATCH 11/23] afs: use bvec_set_folio to initialize a bvec

Christoph Hellwig wrote: > Use the bvec_set_folio helper to initialize a bvec. > > Signed-off-by: Christoph Hellwig Acked-by: David Howells ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfound

Re: [PATCH 20/23] rxrpc: use bvec_set_page to initialize a bvec

Christoph Hellwig wrote: > Use the bvec_set_page helper to initialize a bvec. > > Signed-off-by: Christoph Hellwig Acked-by: David Howells ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfound

Re: [PATCH 20/23] rxrpc: use bvec_set_page to initialize a bvec

Christoph Hellwig wrote: > On Mon, Jan 30, 2023 at 10:31:23AM +0000, David Howells wrote: > > Christoph Hellwig wrote: > > > > > + bvec_set_page(, ZERO_PAGE(0), len, 0); > > > > Maybe bvec_set_zero_page()? > > Why? Seems to be something pe

Re: [PATCH 01/23] block: factor out a bvec_set_page helper

Christoph Hellwig wrote: > +static inline void bvec_set_page(struct bio_vec *bv, struct page *page, > + unsigned int len, unsigned int offset) Could you swap len and offset around? It reads better offset first. You move offset into the page and then do something with len bytes.

Re: [PATCH 20/23] rxrpc: use bvec_set_page to initialize a bvec

Christoph Hellwig wrote: > + bvec_set_page(, ZERO_PAGE(0), len, 0); Maybe bvec_set_zero_page()? David ___ Virtualization mailing list Virtualization@lists.linux-foundation.org

Re: [PATCH v4 1/3] mm/slab: Use memzero_explicit() in kzfree()

Waiman Long wrote: > The kzfree() function is normally used to clear some sensitive > information, like encryption keys, in the buffer before freeing it back > to the pool. Memset() "memset()" is all lowercase. > is currently used for buffer clearing. However unlikely, there is still a >

Re: [PATCH 1/2] mm, treewide: Rename kzfree() to kfree_sensitive()

diting of the kfree_sensitive() kerneldoc and the > use of memzero_explicit() instead of memset(). > > Suggested-by: Joe Perches > Signed-off-by: Waiman Long Since this changes a lot of crypto stuff, does it make sense for it to go via the crypto tree? Acked-by: David

Re: kernel BUG at fs/pipe.c:LINE!

Eric Biggers wrote: > static __poll_t > pipe_poll(struct file *filp, poll_table *wait) > { > __poll_t mask; > struct pipe_inode_info *pipe = filp->private_data; > unsigned int head = READ_ONCE(pipe->head); > unsigned int tail = READ_ONCE(pipe->tail); > >

[RFC PATCH 18/68] vfs: Convert virtio_balloon to use the new mount API

. Signed-off-by: David Howells cc: "Michael S. Tsirkin" cc: Jason Wang cc: virtualization@lists.linux-foundation.org --- drivers/virtio/virtio_balloon.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/drivers/virtio/virtio_balloon.c b/driv

[RFC PATCH 00/68] VFS: Convert a bunch of filesystems to the new mount API

rts a slew of filesystems to use the mount API. (9) Fixes a bug in hypfs. The patches can be found here also: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git on branch: mount-api-viro David --- Andrew Price (1): gfs2: Convert gfs2 to fs_context Da

[PATCH 15/38] vfs: Convert virtio_balloon to fs_context

Signed-off-by: David Howells cc: "Michael S. Tsirkin" cc: Jason Wang cc: virtualization@lists.linux-foundation.org --- drivers/virtio/virtio_balloon.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/drivers/virtio/virtio_balloon.c b/driv

[PATCH 00/38] VFS: Convert trivial filesystems and more

ere also: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git on branch: mount-api-viro David --- David Howells (38): vfs: Provide sb->s_iflags settings in fs_context struct vfs: Provide a mount_pseudo-replacement for fs_context vfs: Conve

[RFC] UAPI: Check headers by compiling all together as C++

also be found here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=uapi-check Thanks, David --- David Howells (11): UAPI: drm: Fix use of C++ keywords as structural members UAPI: keys: Fix use of C++ keywords as structural members UAPI

[PATCH 03/11] UAPI: virtio_net: Fix use of C++ keywords as structural members [ver #2]

The virtio_net_ctrl_hdr struct uses a C++ keyword as structural members. Fix this by inserting an anonymous union that provides an alternative name and then hide the reserved name in C++. Signed-off-by: David Howells cc: "Michael S. Tsirkin" cc: Jason Wang cc: virtualization@l

Re: [PATCH 03/11] UAPI: virtio_net: Fix use of C++ keywords as structural members

Michael S. Tsirkin wrote: > As long as you do not intend to use any classes, how about > simply adding > > -Dclass=_class > > to your command line? That kind of misses the point;-). It's not reasonable to expect all userspace C++ users to do this. David

Re: [RFC] UAPI: Check headers by compiling all together as C++

Greg KH wrote: > > Here's a set of patches that inserts a step into the build process to make > > sure that the UAPI headers can all be built together with C++ (if the > > compiler being used supports C++). All but the final patch perform fixups, > > including: > > Wait, why do we care? What

Re: [PATCH 03/11] UAPI: virtio_net: Fix use of C++ keywords as structural members

Greg KH wrote: > Come on now, either put the whole C namespace stuff around the file, You mean wrap it with 'extern "C" { ... }'? That doesn't fix it. That only affects the symbols generated by the compiler. > "class" is a fine variable name for C code, there's no reason this has > to change

[PATCH 03/11] UAPI: virtio_net: Fix use of C++ keywords as structural members

The virtio_net_ctrl_hdr struct uses a C++ keyword as structural members. Fix this by inserting an anonymous union that provides an alternative name and then hide the reserved name in C++. Signed-off-by: David Howells cc: "Michael S. Tsirkin" cc: Jason Wang cc: virtualization@l

[RFC] UAPI: Check headers by compiling all together as C++

of the UAPI headers (with a few exceptions) together as C++ to catch new errors occurring as part of the regular build process. The patches can also be found here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=uapi-check Thanks, David --- David Howells

Re: [PATCH] documentation: Add disclaimer

Paul E. McKenney wrote: > Good point! Would you be willing to add a Signed-off-by so I > can take the combined change, assuming Peter and Will are good > with it? Sure! David ___ Virtualization mailing list

Re: [PATCH] documentation: Add disclaimer

Peter Zijlstra wrote: > +== > +DISCLAIMER > +== > + > +This document is not a specification; it is intentionally (for the sake of > +brevity) and unintentionally (due to being human) incomplete. This document > is > +meant as a guide to using the various

Re: [PATCH trivial] include: uapi: standard all files' macro prefix and suffix, excluding linux/ sub-directory

Chen Gang gang.c...@asianux.com wrote: Userspace sometimes depends on the name in the guard macro:-/ the guard macro is only for prevent itself from being included by multiple times (an id used by itself -- like a handle), it is not an id to let other files know about it (it is not a

Re: [PATCH trivial] include: uapi: standard all files' macro prefix and suffix, excluding linux/ sub-directory

Chen Gang gang.c...@asianux.com wrote: For include/uapi/*, excluding linux/ sub-directory, let all files' macro prefix match the standard format, and give related stand comments for their macro suffix. The related standard format is: _SUBDIRNAME_SUBDIRNAME[_SUBDIRNAME]_FILENAME (1st

Re: [PATCH] virtio_pci: fix macro exported in uapi

Rusty Russell ru...@rustcorp.com.au wrote: The point of the patch is that it's unusable: #define VIRTIO_PCI_CONFIG(dev)((dev)-msix_enabled ? 24 : 20) ie. it's accessing a member of the kernel's virtio_pci_dev structure. Ah, okay. In that case, zap it and see if anyone

Re: [PATCH] virtio_pci: fix macro exported in uapi

Rusty Russell ru...@rustcorp.com.au wrote: Macro still isn't usable, because userspace can't know whether it's the new or old. We need to either remove it from UAPI, or rename it to VIRTIO_PCI_CONFIG_OFF. Surely, if userspace is using it as is, you can't remove it, rename it or alter it?

Re: [PATCH] VSOCK: Split vm_sockets.h into kernel/uapi

. Reported-by: David Howells dhowe...@redhat.com Acked-by: Dmitry Torokhov d...@vmware.com Signed-off-by: Andy King ack...@vmware.com Acked-by: David Howells dhowe...@redhat.com ___ Virtualization mailing list Virtualization@lists.linux