search for: is_readi

-- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -------------- next part -------------- >From 759de3f6289967a3c9978b4e947a38a4585f404c Mon Sep 17 00:00:00 2001 From: Richard Jones

On 6/5/19 6:15 AM, Richard W.M. Jones wrote: > For each nbd_(unlocked_)?aio_is_* function, split it into an internal > function that tests the state and a public visible API function. > > For calls within the library, use the internal function. > > This is simple refactoring. > > As a side effect this fixes a race condition identified by Eric Blake: > > Thread A

To avoid direct access to the driver_data pointer in struct device, the functions dev_get_drvdata() and dev_set_drvdata() should be used. Signed-off-by: Roel Kluin <roel.kluin at gmail.com> --- diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 8f90508..ff09809 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -755,12 +755,12 @@

To avoid direct access to the driver_data pointer in struct device, the functions dev_get_drvdata() and dev_set_drvdata() should be used. Signed-off-by: Roel Kluin <roel.kluin at gmail.com> --- diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 8f90508..ff09809 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -755,12 +755,12 @@

To avoid direct access to the driver_data pointer in struct device, the functions dev_get_drvdata() and dev_set_drvdata() should be used. Signed-off-by: Roel Kluin <roel.kluin at gmail.com> --- diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 8f90508..ff09809 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -755,12 +755,12 @@

In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: xen-devel at lists.xensource.com Cc: virtualization at lists.osdl.org Acked-by:

In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: xen-devel at lists.xensource.com Cc: virtualization at lists.osdl.org Acked-by:

In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: xen-devel at lists.xensource.com Cc: virtualization at lists.osdl.org Acked-by:

From: Greg Kroah-Hartman <gregkh at suse.de> In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: xen-devel at

From: Greg Kroah-Hartman <gregkh at suse.de> In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: xen-devel at

From: Greg Kroah-Hartman <gregkh at suse.de> In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: xen-devel at

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git config-endian head: d8ede9b5e734748613d3e3108a4026244aa8e41f commit: 392755e77e260e8a173b228e8ecc17917f97d5eb [38/39] fixup! virtio_net: correct tags for config space fields config: arm64-allyesconfig (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget

Dear list, This is the V4 of the trim support for xen-blkfront/blkback, Now we move BLKIF_OP_TRIM to BLKIF_OP_DISCARD, and dropped all "trim" stuffs in the patches, and use "discard" instead. Also we updated the helpers of blkif_x86_{32|64}_request or we will meet problems using a non-native protocol. And this patch has been tested with both SSD and raw file, with SSD we will

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git config-endian head: df43c8f58f42ec36e91740f91ea7360f63213004 commit: e1e22056bc3641f340ed27012cfd1b8b05f83a0a [38/39] fixup! virtio_net: correct tags for config space fields config: arm64-allyesconfig (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget

On 5/31/19 11:01 AM, Richard W.M. Jones wrote: > This is a continuation of a discussion we were having on IRC. The > problems with IRC are it's not recorded and it's hard to have deep > technical conversations. I hope this is a decent summary. > > Problem simply stated: Certain NBD servers (qemu-nbd in particular) Also nbdkit for a plugin with

This is a continuation of a discussion we were having on IRC. The problems with IRC are it's not recorded and it's hard to have deep technical conversations. I hope this is a decent summary. Problem simply stated: Certain NBD servers (qemu-nbd in particular) are able to simultaneously read and write on a socket. ie. They can be simultaneously reading a request and writing the reply to

Done with coccinelle: @@ expression e1, e2, e3; identifier rc; @@ ( rc = device_add_disk(e1, e2, e3); | + /* FIXME: handle error. */ device_add_disk(e1, e2, e3); ) Signed-off-by: Fam Zheng <famz at redhat.com> --- arch/m68k/emu/nfblock.c | 1 + arch/um/drivers/ubd_kern.c | 1 + arch/xtensa/platforms/iss/simdisk.c | 1 + drivers/block/DAC960.c

When processing a server reply within the REPLY subgroup, we will often hit a situation where recv() requires us to block until the next NotifyRead. But since NotifyRead is the only permitted external action while in this group, we are effectively blocking CmdIssue and NotifyWrite events from happening until the server finishes the in-progress reply, even though those events have no strict

This patch implements persistent grants for the xen-blk{front,back} mechanism. The effect of this change is to reduce the number of unmap operations performed, since they cause a (costly) TLB shootdown. This allows the I/O performance to scale better when a large number of VMs are performing I/O. Previously, the blkfront driver was supplied a bvec[] from the request queue. This was granted to

I need to think about this patch series a bit more, but it does at least pass the tests. Rich.