similar to: BUG: corrupted list in remove_wait_queue

> Can you give provide: > lspci -vvv Yes > full serial log console output? No. > and what were you doing when this happend? (starting X, playing games?) The previous dmesg was captured during about 10 hr day. Stack traces were cumulated at the end one by one ( about 6-9 similar entries). Now i rebooted the box. Started Virt-Manager and F13 guest . Then begun rotate cube ( desktop)

We tried to remove vq poll from wait queue, but do not check whether or not it was in a list before. This will lead double free. Fixing this by switching to use vhost_poll_stop() which zeros poll->wqh after removing poll from waitqueue to make sure it won't be freed twice. Cc: Darren Kenny <darren.kenny at oracle.com> Reported-by: syzbot+c0272972b01b872e604a at

We tried to remove vq poll from wait queue, but do not check whether or not it was in a list before. This will lead double free. Fixing this by switching to use vhost_poll_stop() which zeros poll->wqh after removing poll from waitqueue to make sure it won't be freed twice. Cc: Darren Kenny <darren.kenny at oracle.com> Reported-by: syzbot+c0272972b01b872e604a at

On 2018?03?27? 17:28, Darren Kenny wrote: > Hi Jason, > > On Tue, Mar 27, 2018 at 11:47:22AM +0800, Jason Wang wrote: >> We tried to remove vq poll from wait queue, but do not check whether >> or not it was in a list before. This will lead double free. Fixing >> this by checking poll->wqh to make sure it was in a list. > > This text seems at odds with the code

Just surfing Net for 2-3 hr concerning "dracut" on Fedora 13. Several "warnings"  at the end of dmesg log. Seems like reaction on some system events scheduled to run on regular basis, but not user''s activity. Boris. --- On Tue, 8/17/10, Boris Derzhavets <bderzhavets@yahoo.com> wrote: From: Boris Derzhavets <bderzhavets@yahoo.com> Subject: Re: [Xen-devel]

From: Alexander Potapenko <glider at google.com> KMSAN reported a use of uninit memory in vhost_net_buf_unproduce() while trying to access n->vqs[VHOST_NET_VQ_TX].rx_ring: ================================================================== BUG: KMSAN: use of uninitialized memory in vhost_net_buf_unproduce+0x7bb/0x9a0 drivers/vho et.c:170 CPU: 0 PID: 3021 Comm: syz-fuzzer Not tainted

We tried to remove vq poll from wait queue, but do not check whether or not it was in a list before. This will lead double free. Fixing this by checking poll->wqh to make sure it was in a list. Reported-by: syzbot+c0272972b01b872e604a at syzkaller.appspotmail.com Fixes: 2b8b328b61c79 ("vhost_net: handle polling errors when setting backend") Signed-off-by: Jason Wang <jasowang at

On Tue, Mar 27, 2018 at 08:50:52PM +0800, Jason Wang wrote: > We tried to remove vq poll from wait queue, but do not check whether > or not it was in a list before. This will lead double free. Fixing > this by switching to use vhost_poll_stop() which zeros poll->wqh after > removing poll from waitqueue to make sure it won't be freed twice. > > Cc: Darren Kenny

CentOS 6.4 x86_64 Kernel: 2.6.32-358.14.1.el6.x86_64 I have been noticing repeatedly that after a couple of weeks of uptime my NFS server starts to generate the following error: ------------[ cut here ]------------ WARNING: at lib/list_debug.c:26 __list_add+0x6d/0xa0() (Tainted: G W ---

Hi, I'm running CentOS 6.5 as NFS server (v3 and v4) and exporting Ext4 and XFS filesystem. After many months that all works fine today the server crash: Jan 30 09:46:13 qb-storage kernel: ------------[ cut here ]------------ Jan 30 09:46:13 qb-storage kernel: WARNING: at lib/list_debug.c:26 __list_add+0x6d/0xa0() (Not tainted) Jan 30 09:46:13 qb-storage kernel: Hardware name: PowerEdge

Howdy, I've got a CentOS 7 VM that occasionally becomes unresponsive. There's a "list_add corruption" entry in /var/log/messages, included below. This is on VMware. We have lots of other VMs which are running just fine. Only a few are CentOS 7 VMs, though, so I can't rule out some kind of environment issue. It's up-to-date on OS patches, and running kernel

I have tried sending this before, but it did not appear to get through. Hello, When using gfs2 with quotas on a SAN that is providing storage to two clustered systems running CentOS6.5, one of the systems can crash. This crash appears to be caused when a user tries to add something to a SAN disk when they have exceeded their quota on that disk. Sometimes a stack trace is produced in

On Mon, Jul 30, 2018 at 11:15:03AM -0700, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit: acb1872577b3 Linux 4.18-rc7 > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=14eb932c400000 > kernel config: https://syzkaller.appspot.com/x/.config?x=2dc0cd7c2eefb46f > dashboard link:

https://bugs.freedesktop.org/show_bug.cgi?id=84880 Bug ID: 84880 Summary: [NV94] X freeze on nouveau list_del corruption / unable to handle kernel paging request Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical

Hello every one Working under Windows Xp in French, and R version 2.4.0 (and : > localeToCharset() : "ISO8859-1" ) I am trying to source a file with basic commands. source("R files/InputFile Analysis (Calculs et mises à l'échelle - gestion des pb d'unités).r") and it works fine as long as I do not use command like these ones :

Hi, I am playing around with backgroundrb 1.0.3. I have the following backgroundrb.yml, --- :backgroundrb: :port: 11006 :ip: 0.0.0.0 :schedules: :task_worker: :run: :trigger_args: */10 * * * * * My task worker is just, class TaskWorker < BackgrounDRb:MetaWorker set_worker_name :task_worker def run logger.info "begin" sleep 60 logger.info

Hi: This small series try to fix several bugs of ptr_ring usage in vhost_net. Please review. Thanks Alexander Potapenko (1): vhost_net: initialize rx_ring in vhost_net_open() Jason Wang (2): vhost_net: keep private_data and rx_ring synced vhost_net: examine pointer types during un-producing drivers/net/tun.c | 3 ++- drivers/vhost/net.c | 8 +++++--- include/linux/if_tun.h | 4

Some architectures like arm64 and s390 require USER_DS to be set for kernel threads to access user address space, which is the whole purpose of kthread_use_mm, but other like x86 don't. That has lead to a huge mess where some callers are fixed up once they are tested on said architectures, while others linger around and yet other like io_uring try to do "clever" optimizations for

Some architectures like arm64 and s390 require USER_DS to be set for kernel threads to access user address space, which is the whole purpose of kthread_use_mm, but other like x86 don't. That has lead to a huge mess where some callers are fixed up once they are tested on said architectures, while others linger around and yet other like io_uring try to do "clever" optimizations for

It''s clearer to use struct ctl_table instead Joe Perches (33): arm: kernel: isa: Convert use of typedef ctl_table to struct ctl_table frv: Convert use of typedef ctl_table to struct ctl_table ia64: crash: Convert use of typedef ctl_table to struct ctl_table mips: lasat: sysctl: Convert use of typedef ctl_table to struct ctl_table powerpc: idle: Convert use of typedef ctl_table