similar to: [PATCH] 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

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]()

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]()

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

Hi all, Did someone have met this problem before. When doing the tests, I hit the WARN_ON. Is this log make sense or someone had fixed the problem. If needed, I can supply the detail log and the testcase source file. Version: the latest codes at linus git tree. [ 2140.981293] use_block_rsv: 336 callbacks suppressed [ 2140.981295] ------------[ cut here ]------------ [ 2140.981308]

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

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

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:

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

We need an smb_mb() before waitqueue_active to avoid missing wakeups. Before Mitch was hitting a deadlock between the ordered flushers and the transaction commit because the ordered flushers were waiting for more refs and were never woken up, so those smp_mb()''s are the most important. Everything else I added for correctness sake and to avoid getting bitten by this again somewhere else.

Hello, I have been having some crashes like this. Since I upgraded to 3.6.4 they have become common. The crashes happen pretty randomly during normal system usage. After the syslog messages the system stays semi usable for a minute, but when I run any new program it hangs. I had to downgrade to 3.6.2 to get my system usable again. Is there any way I can help find the cause of those crashes?

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 "kick" it. This kick involves a PIO in the guest, and therefore an exit (and possibly

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 "kick" it. This kick involves a PIO in the guest, and therefore an exit (and possibly

I''ve been working on running down intermittent ENOSPC issues. I can only seem to replicate ENOSPC errors when running zlib compression. However, I have been seeing similar ENOSPC errors to a lesser extent when playing with the LZ4HC patches. I apologize for not following up on this sooner, but I had drifted away from using zlib, and didn''t notice there was still an issue. My

After running ceph on XFS for some time, I decided to try btrfs again. Performance with the current "for-linux-min" branch and big metadata is much better. The only problem (?) I''m still seeing is a warning that seems to occur from time to time: [87703.784552] ------------[ cut here ]------------ [87703.789759] WARNING: at fs/btrfs/inode.c:2103

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