similar to: [PATCH v3 09/26] compat_ioctl: move drivers to compat_ptr_ioctl

On Tue, Apr 16, 2019 at 10:19:47PM +0200, Arnd Bergmann wrote: > Each of these drivers has a copy of the same trivial helper function to > convert the pointer argument and then call the native ioctl handler. > > We now have a generic implementation of that, so use it. > > Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org> > Reviewed-by: Jarkko Sakkinen

Each of these drivers has a copy of the same trivial helper function to convert the pointer argument and then call the native ioctl handler. We now have a generic implementation of that, so use it. Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org> Acked-by: Michael S. Tsirkin <mst at redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen at linux.intel.com>

Each of these drivers has a copy of the same trivial helper function to convert the pointer argument and then call the native ioctl handler. We now have a generic implementation of that, so use it. Signed-off-by: Arnd Bergmann <arnd at arndb.de> --- drivers/char/ppdev.c | 12 +--------- drivers/char/tpm/tpm_vtpm_proxy.c | 12 +--------- drivers/firewire/core-cdev.c | 12

Hi Jens, James and Martin, This series concludes the work I did for linux-5.5 on the compat_ioctl() cleanup, killing off fs/compat_ioctl.c and block/compat_ioctl.c by moving everything into drivers. Overall this would be a reduction both in complexity and line count, but as I'm also adding documentation the overall number of lines increases in the end. My plan was originally to keep the

Each driver calling scsi_ioctl() gets an equivalent compat_ioctl() handler that implements the same commands by calling scsi_compat_ioctl(). The scsi_cmd_ioctl() and scsi_cmd_blk_ioctl() functions are compatible at this point, so any driver that calls those can do so for both native and compat mode, with the argument passed through compat_ptr(). With this, we can remove the entries from

On Wed, Dec 11, 2019 at 09:42:49PM +0100, Arnd Bergmann wrote: > Each driver calling scsi_ioctl() gets an equivalent compat_ioctl() > handler that implements the same commands by calling scsi_compat_ioctl(). > > The scsi_cmd_ioctl() and scsi_cmd_blk_ioctl() functions are compatible > at this point, so any driver that calls those can do so for both native > and compat mode, with

On Wed, Dec 11, 2019 at 09:42:49PM +0100, Arnd Bergmann wrote: > Each driver calling scsi_ioctl() gets an equivalent compat_ioctl() > handler that implements the same commands by calling scsi_compat_ioctl(). > > The scsi_cmd_ioctl() and scsi_cmd_blk_ioctl() functions are compatible > at this point, so any driver that calls those can do so for both native > and compat mode, with

On S?nnavend 05 November 2005 00:51, Christoph Hellwig wrote: > On Sat, Nov 05, 2005 at 12:10:46AM +0100, Arnd Bergmann wrote: > > > > BTW, I now have a set of 25 patches that moves all handlers from > > fs/compat_ioctl.c over to the respective drivers and subsystems, > > but I'm not sure how to best test that. > > I intend to at least give it a test run on my

On S?nnavend 05 November 2005 00:51, Christoph Hellwig wrote: > On Sat, Nov 05, 2005 at 12:10:46AM +0100, Arnd Bergmann wrote: > > > > BTW, I now have a set of 25 patches that moves all handlers from > > fs/compat_ioctl.c over to the respective drivers and subsystems, > > but I'm not sure how to best test that. > > I intend to at least give it a test run on my

changeset: 30726:2a6fda4e7dde1a0a5d29a62303e85bcea868eb47 tag: tip user: Jimi Xenidis <jimix@watson.ibm.com> date: Thu Jul 13 11:51:38 2006 -0400 files: drivers/xen/privcmd/Makefile drivers/xen/privcmd/compat_privcmd.c fs/compat_ioctl.c include/xen/public/privcmd.h description: [ppc] ioctl32() compat plumbing for xen calls The following patch deals with xen

Each driver calling scsi_ioctl() gets an equivalent compat_ioctl() handler that implements the same commands by calling scsi_compat_ioctl(). The scsi_cmd_ioctl() and scsi_cmd_blk_ioctl() functions are compatible at this point, so any driver that calls those can do so for both native and compat mode, with the argument passed through compat_ptr(). With this, we can remove the entries from

Given the need for 4K doorbell such that QEMU can easily map, ect, and assuming that I have a HW device which exposes 2 VQ's, with a notification area off of BAR3, offset=whatever, notifier_multiplier=4, we don't need to have 2 x 4K pages mapped into the VM for both doorbells do we? The guest driver would ring DB0 at BAR4+offset, and DB1 at BAR4+offset+(4*1). The 4K per DB is useful how?

This implements a virtio simulator: - adds stubs for enough support functions to compile virtio ring in userspace. - Adds a stub vhost based module this can talk to. This should help us decide things like which ring layout works best. Communication is currently done using an eventfd descriptor. This means there's a shared spinlock there: what I would like to do in the future, is run

This implements a virtio simulator: - adds stubs for enough support functions to compile virtio ring in userspace. - Adds a stub vhost based module this can talk to. This should help us decide things like which ring layout works best. Communication is currently done using an eventfd descriptor. This means there's a shared spinlock there: what I would like to do in the future, is run

On Wed, Mar 14, 2018 at 10:26:05AM -0700, Sonny Rao wrote: > This will allow usage of vsock from 32-bit binaries on a 64-bit > kernel. > > Signed-off-by: Sonny Rao <sonnyrao at chromium.org> I think you need to convert the pointer argument though. Something along the lines of: #ifdef CONFIG_COMPAT static long vhost_vsock_dev_compat_ioctl(struct file *f, unsigned int ioctl,

Signed-off-by: Dave Kleikamp <dave.kleikamp at oracle.com> Acked-by: Joel Becker <jlbec at evilplan.org> Cc: Zach Brown <zab at zabbo.net> Cc: Mark Fasheh <mfasheh at suse.com> Cc: ocfs2-devel at oss.oracle.com --- fs/ocfs2/aops.h | 2 +- fs/ocfs2/file.c | 55 ++++++++++++++++++++++---------------------------- fs/ocfs2/ocfs2_trace.h | 6 +++--- 3 files

From: Zach Brown <zab@zabbo.net> ocfs2''s .aio_read and .aio_write methods are changed to take iov_iter and pass it to generic functions. Wrappers are made to pack the iovecs into iters and call these new functions. Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com> Cc: Zach Brown <zab@zabbo.net> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker

On 12/12/19 00:05, Michael S. Tsirkin wrote: >> @@ -405,6 +405,9 @@ static int virtblk_getgeo(struct block_device *bd, struct hd_geometry *geo) >> >> static const struct block_device_operations virtblk_fops = { >> .ioctl = virtblk_ioctl, >> +#ifdef CONFIG_COMPAT >> + .compat_ioctl = blkdev_compat_ptr_ioctl, >> +#endif >> .owner =

Currently the doorbell is relayed via eventfd which may have significant overhead because of the cost of vmexits or syscall. This patch introduces mmap() based doorbell mapping which can eliminate the overhead caused by vmexit or syscall. To ease the userspace modeling of the doorbell layout (usually virtio-pci), this patch starts from a doorbell per page model. Vhost-vdpa only support the

On 2020/5/29 ??5:16, Mika Penttil? wrote: > Hi, > > On 29.5.2020 11.03, Jason Wang wrote: >> Currently the doorbell is relayed via eventfd which may have >> significant overhead because of the cost of vmexits or syscall. This >> patch introduces mmap() based doorbell mapping which can eliminate the >> overhead caused by vmexit or syscall. > > Just wondering.