similar to: [PATCH V2] vhost_net: clear msg.control for non-zerocopy case during tx

On 06/05/2013 09:44 PM, Sergei Shtylyov wrote: > Hello. > > On 05-06-2013 11:40, Jason Wang wrote: > >> When we decide not use zero-copy, msg.control should be set to NULL >> otherwise >> macvtap/tap may set zerocopy callbacks which may decrease the kref of >> ubufs >> wrongly. > >> Bug were introduced by commit

On 06/05/2013 09:44 PM, Sergei Shtylyov wrote: > Hello. > > On 05-06-2013 11:40, Jason Wang wrote: > >> When we decide not use zero-copy, msg.control should be set to NULL >> otherwise >> macvtap/tap may set zerocopy callbacks which may decrease the kref of >> ubufs >> wrongly. > >> Bug were introduced by commit

Hello. On 05-06-2013 11:40, Jason Wang wrote: > When we decide not use zero-copy, msg.control should be set to NULL otherwise > macvtap/tap may set zerocopy callbacks which may decrease the kref of ubufs > wrongly. > Bug were introduced by commit cedb9bdce099206290a2bdd02ce47a7b253b6a84 > (vhost-net: skip head management if no outstanding). > This solves the following

On Wed, Jun 05, 2013 at 03:40:46PM +0800, Jason Wang wrote: > When we decide not use zero-copy, msg.control should be set to NULL otherwise > macvtap/tap may set zerocopy callbacks which may decrease the kref of ubufs > wrongly. > > Bug were introduced by commit cedb9bdce099206290a2bdd02ce47a7b253b6a84 > (vhost-net: skip head management if no outstanding). > > This solves

When we decide not use zero-copy, msg.control should be set to NULL otherwise macvtap/tap may set zerocopy callbacks which may decrease the kref of ubufs wrongly. Bug were introduced by commit cedb9bdce099206290a2bdd02ce47a7b253b6a84 (vhost-net: skip head management if no outstanding). This solves the following warnings: WARNING: at include/linux/kref.h:47 handle_tx+0x477/0x4b0 [vhost_net]()

When we decide not use zero-copy, msg.control should be set to NULL otherwise macvtap/tap may set zerocopy callbacks which may decrease the kref of ubufs wrongly. Bug were introduced by commit cedb9bdce099206290a2bdd02ce47a7b253b6a84 (vhost-net: skip head management if no outstanding). This solves the following warnings: WARNING: at include/linux/kref.h:47 handle_tx+0x477/0x4b0 [vhost_net]()

Hello, I''m running into some trouble with what appear on the surface to be OOM issues in Dom0, but I''m not seeing any other evidence. This typically happens during periods of high I/O, and has occurred during RAID initial sync, and mkfs.ext4ing (as a test, no intention to keep ext4 on this array). I''ve found some older posts citing very similar circumstances, however

I''ve upgraded to linux 3.10 and enabled extended inode refs and skinny metadata extent refs with these commands: btrfstune -r /dev/sdc1 btrfstune -x /dev/sdc1 Since then, I have "WARNING: at fs/btrfs/backref.c:903 find_parent_nodes+0x616/0x815 [btrfs]()" showing up like crazy: # grep -c "WARNING: at fs/btrfs/backref.c:903" syslog 181819 That''s after just

Since 2.6.36-rc1, non-root users of vhost-net fail to attach if they are in any cgroups. This is a regression, and libvirt actually uses this functionality, as it runs qemu with reduced priveledges. The bug is that when qemu uses vhost, vhost wants to attach its thread to all cgroups that qemu has. But we got the API backwards, so a non-priveledged process (qemu) tried to control the priveledged

Since 2.6.36-rc1, non-root users of vhost-net fail to attach if they are in any cgroups. This is a regression, and libvirt actually uses this functionality, as it runs qemu with reduced priveledges. The bug is that when qemu uses vhost, vhost wants to attach its thread to all cgroups that qemu has. But we got the API backwards, so a non-priveledged process (qemu) tried to control the priveledged

vscsi->num_queues counts the number of request virtqueue which does not include the control and event virtqueue. It is wrong to subtract VIRTIO_SCSI_VQ_BASE from vscsi->num_queues. This patch fixes the following panic. (qemu) device_del scsi0 BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: [<ffffffff8179b29f>] __virtscsi_set_affinity+0x6f/0x120 PGD 0

vscsi->num_queues counts the number of request virtqueue which does not include the control and event virtqueue. It is wrong to subtract VIRTIO_SCSI_VQ_BASE from vscsi->num_queues. This patch fixes the following panic. (qemu) device_del scsi0 BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: [<ffffffff8179b29f>] __virtscsi_set_affinity+0x6f/0x120 PGD 0

Is this useful to anyone? Got this after a crash/reboot: if (block_rsv) { WARN_ON(block_rsv->size > 0); <<<<<<<<<<<<<<<<<<<<<< btrfs_free_block_rsv(root, block_rsv); } ------------[ cut here ]------------ WARNING: at fs/btrfs/inode.c:2165 btrfs_orphan_commit_root+0xcb/0xdf() Hardware name: 2429A78 Modules linked in:

I''m running into a problem with the btrfs-cleaner thread becoming blocked on xfstests 068. The test locks up indefinitely without completing (normally it finished in about 45 seconds on my test box). I''ve replicated the issue on 3.10.0_rc5 and the for-linus branch of 3.9.0. I ran a git bisect on the 3.9.0 for-linus branch, and tracked my issue to the following commit: commit

Hi, while doing work, my luks encrypted btrfs home got a nice stacktrace i run a Debian testing and a kernel 3.4 vanilla % uname -a Linux Klappe2 3.4.0 #2 SMP Thu Jun 14 03:02:37 CEST 2012 x86_64 GNU/Linux the box is a dell xps m 1330 with about 4gb ram % btrfs fi show Label: ''home'' uuid: 9c1a77c9-3767-43aa-908d-0bae1ef4e534 Total devices 1 FS bytes used 198.25GB devid

Not sure if it''s anything interesting - I had the following entry in dmesg a few days ago, on a server with 32 GB RAM. The system is still working fine. [1878432.675210] btrfs-qgroup-re: page allocation failure: order:5, mode:0x104050 [1878432.675319] CPU: 5 PID: 22251 Comm: btrfs-qgroup-re Not tainted 3.11.0-rc7 #2 [1878432.675417] Hardware name: System manufacturer System Product

On 2020/9/22 ??2:23, Mike Christie wrote: > vhost_work_flush doesn't do anything with the work arg. This patch drops > it and then renames vhost_work_flush to vhost_work_dev_flush to reflect > that the function flushes all the works in the dev and not just a > specific queue or work item. > > Signed-off-by: Mike Christie <michael.christie at oracle.com> Acked-by:

Hi all, I''m running btrfs in a 3-disk RAID1 configuration. After a hard power-off, I''m seeing a lot of hung I/O tasks on this volume, apparently due to a corrupt leaf. I first noticed the problem on kernel 3.4.7, and it''s persisted with 3.4.8. Relevant parts of the kernel log follow. [ 85.179621] block group 38684065792 has an wrong amount of free space [

We''ve been hitting the following issue on a variety of hosts and recent Xen/dom0 version combinations. Here''s an excerpt from our latest: Xen: 4.1.4 (xenbits @ 23432) Dom0: 3.7.1-x86_64 BUG: unable to handle kernel NULL pointer dereference at 000000000000001c IP: [<ffffffff8141a301>] evtchn_from_irq+0x11/0x40 PGD 0 Oops: 0000 [#1] SMP Modules linked in: ebt_comment

On Sun, Aug 10, 2014 at 11:30:35AM +0300, Razya Ladelsky wrote: > From: Razya Ladelsky <razya at il.ibm.com> > Date: Thu, 31 Jul 2014 09:47:20 +0300 > Subject: [PATCH] vhost: Add polling mode > > When vhost is waiting for buffers from the guest driver (e.g., more packets to > send in vhost-net's transmit queue), it normally goes to sleep and waits for the > guest to