search for: list_empty

The following 6 patches cleanup the jbd code and kill about 200 lines. First of 4 patches can apply to 2.6.13-git8 and 2.6.13-mm2. The rest of them can apply to 2.6.13-mm2. fs/jbd/checkpoint.c | 179 +++++++++++-------------------------------- fs/jbd/commit.c | 101 ++++++++++-------------- fs/jbd/journal.c | 11 +- fs/jbd/revoke.c | 158

On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > Hi, > > I can relatively easily reproduce this bug: > BUG: 'list_empty(&vgdev->free_vbufs)' is true! > ------------[ cut here ]------------ > kernel BUG at /home/latest/linux/drivers/gpu/drm/virtio/virtgpu_vq.c:130! > invalid opcode: 0000 [#1] PREEMPT SMP KASAN > Modules linked in: > CPU: 1 PID: 355 Comm: kworker/1:2 Not tainted 4.9.0-rc2-nex...

Hi, I can relatively easily reproduce this bug: BUG: 'list_empty(&vgdev->free_vbufs)' is true! ------------[ cut here ]------------ kernel BUG at /home/latest/linux/drivers/gpu/drm/virtio/virtgpu_vq.c:130! invalid opcode: 0000 [#1] PREEMPT SMP KASAN Modules linked in: CPU: 1 PID: 355 Comm: kworker/1:2 Not tainted 4.9.0-rc2-next-20161028+ #32 Hardware...

Hi, I can relatively easily reproduce this bug: BUG: 'list_empty(&vgdev->free_vbufs)' is true! ------------[ cut here ]------------ kernel BUG at /home/latest/linux/drivers/gpu/drm/virtio/virtgpu_vq.c:130! invalid opcode: 0000 [#1] PREEMPT SMP KASAN Modules linked in: CPU: 1 PID: 355 Comm: kworker/1:2 Not tainted 4.9.0-rc2-next-20161028+ #32 Hardware...

Author: Nitin U. Yewale <nyewale at redhat.com> Date: Mon Jun 4 23:28:41 2018 +0530 Changing comment for the list_empty routine. --- Signed-off-by: Nitin U. Yewale <nyewale at redhat.com> diff --git a/drivers/gpu/drm/nouveau/include/nvif/list.h b/drivers/gpu/drm/nouveau/include/nvif/list.h index 8af5d144ecb0..12bf7e3333e4 100644 --- a/drivers/gpu/drm/nouveau/include/nvif/list.h +++ b/drivers/gpu/drm/nouveau/i...

On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: > On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > > Hi, > > > > I can relatively easily reproduce this bug: How? > > BUG: 'list_empty(&vgdev->free_vbufs)' is true! > The following might be helpful for debugging - if kernel still will > not stop panicing, we are looking at some kind > of memory corruption. Looking carefully through the code I think it isn't impossible to trigger this, but you need for tha...

On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: > On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > > Hi, > > > > I can relatively easily reproduce this bug: How? > > BUG: 'list_empty(&vgdev->free_vbufs)' is true! > The following might be helpful for debugging - if kernel still will > not stop panicing, we are looking at some kind > of memory corruption. Looking carefully through the code I think it isn't impossible to trigger this, but you need for tha...

...t *entry, *nentry; - struct list_head *list, *next; - int ret; + struct ttm_buffer_object *entry; + int ret = 0; spin_lock(&glob->lru_lock); - list_for_each_safe(list, next, &bdev->ddestroy) { - entry = list_entry(list, struct ttm_buffer_object, ddestroy); - nentry = NULL; + if (list_empty(&bdev->ddestroy)) { + spin_unlock(&glob->lru_lock); + return 0; + } - /* - * Protect the next list entry from destruction while we - * unlock the lru_lock. - */ + entry = list_first_entry(&bdev->ddestroy, + struct ttm_buffer_object, ddestroy); + kref_get(&entry-...

...reproduce this bug: > > How? Run dmesg -w in the qemu window (virtio_gpu) to see a lot of output. Run pps [1] without exit(0); on e.g. serial console. Wait a bit. The lot of output causes the BUG. [1] https://github.com/jirislaby/collected_sources/blob/master/pps.c >>> BUG: 'list_empty(&vgdev->free_vbufs)' is true! > >> The following might be helpful for debugging - if kernel still will >> not stop panicing, we are looking at some kind >> of memory corruption. > > Looking carefully through the code I think it isn't impossible to > tr...

...io_gpu) to see a lot of output. fbcon? Or xorg/wayland with terminal app? > Run pps [1] without exit(0); on e.g. serial console. > Wait a bit. The lot of output causes the BUG. > > [1] https://github.com/jirislaby/collected_sources/blob/master/pps.c > > >>> BUG: 'list_empty(&vgdev->free_vbufs)' is true! > > > >> The following might be helpful for debugging - if kernel still will > >> not stop panicing, we are looking at some kind > >> of memory corruption. > > > > Looking carefully through the code I think it i...

...io_gpu) to see a lot of output. fbcon? Or xorg/wayland with terminal app? > Run pps [1] without exit(0); on e.g. serial console. > Wait a bit. The lot of output causes the BUG. > > [1] https://github.com/jirislaby/collected_sources/blob/master/pps.c > > >>> BUG: 'list_empty(&vgdev->free_vbufs)' is true! > > > >> The following might be helpful for debugging - if kernel still will > >> not stop panicing, we are looking at some kind > >> of memory corruption. > > > > Looking carefully through the code I think it i...

...ec1409..54eb070 100644 --- a/fs/btrfs/async-thread.c +++ b/fs/btrfs/async-thread.c @@ -362,7 +362,7 @@ again: * worker->working is still 1, so nobody * is going to try and wake us up */ - schedule_timeout(1); + schedule_timeout_uninterruptible(1); smp_mb(); if (!list_empty(&worker->pending) || !list_empty(&worker->prio_pending)) -- 1.7.0.4

On 11/15/2016, 09:46 AM, Gerd Hoffmann wrote: > On Fr, 2016-11-11 at 17:28 +0100, Jiri Slaby wrote: >> On 11/09/2016, 09:01 AM, Gerd Hoffmann wrote: >>> On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: >>>> On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: >>>>> Hi, >>>>> >>>>> I can relatively easily

...shing < 0); + vhost_work_queue(dev, &flush.work); + wait_for_completion(&flush.wait_event); + } } EXPORT_SYMBOL_GPL(vhost_work_flush); @@ -254,7 +251,6 @@ void vhost_work_queue(struct vhost_dev *dev, struct vhost_work *work) spin_lock_irqsave(&dev->work_lock, flags); if (list_empty(&work->node)) { list_add_tail(&work->node, &dev->work_list); - work->queue_seq++; spin_unlock_irqrestore(&dev->work_lock, flags); wake_up_process(dev->worker); } else { @@ -310,7 +306,6 @@ static int vhost_worker(void *data) { struct vhost_dev *dev =...

...shing < 0); + vhost_work_queue(dev, &flush.work); + wait_for_completion(&flush.wait_event); + } } EXPORT_SYMBOL_GPL(vhost_work_flush); @@ -254,7 +251,6 @@ void vhost_work_queue(struct vhost_dev *dev, struct vhost_work *work) spin_lock_irqsave(&dev->work_lock, flags); if (list_empty(&work->node)) { list_add_tail(&work->node, &dev->work_list); - work->queue_seq++; spin_unlock_irqrestore(&dev->work_lock, flags); wake_up_process(dev->worker); } else { @@ -310,7 +306,6 @@ static int vhost_worker(void *data) { struct vhost_dev *dev =...

....c b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c index 795f3a649b12..6388234c352c 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/base.c @@ -224,7 +224,7 @@ nvkm_acr_oneinit(struct nvkm_subdev *subdev) u64 falcons; int ret, i; - if (list_empty(&acr->hsfw)) { + if (list_empty(&acr->hsfw) || !acr->func->wpr_layout) { nvkm_debug(subdev, "No HSFW(s)\n"); nvkm_acr_cleanup(acr); return 0; -- 2.40.1

...t *entry, *nentry; - struct list_head *list, *next; - int ret; + struct ttm_buffer_object *entry; + int ret = 0; spin_lock(&glob->lru_lock); - list_for_each_safe(list, next, &bdev->ddestroy) { - entry = list_entry(list, struct ttm_buffer_object, ddestroy); - nentry = NULL; + if (list_empty(&bdev->ddestroy)) { + spin_unlock(&glob->lru_lock); + return 0; + } - /* - * Protect the next list entry from destruction while we - * unlock the lru_lock. - */ + entry = list_first_entry(&bdev->ddestroy, + struct ttm_buffer_object, ddestroy); + kref_get(&entry-...

On Fr, 2016-11-11 at 17:28 +0100, Jiri Slaby wrote: > On 11/09/2016, 09:01 AM, Gerd Hoffmann wrote: > > On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: > >> On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > >>> Hi, > >>> > >>> I can relatively easily reproduce this bug: > > > > How? > > Run dmesg -w

On Fr, 2016-11-11 at 17:28 +0100, Jiri Slaby wrote: > On 11/09/2016, 09:01 AM, Gerd Hoffmann wrote: > > On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: > >> On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > >>> Hi, > >>> > >>> I can relatively easily reproduce this bug: > > > > How? > > Run dmesg -w

...y, *nentry; - struct list_head *list, *next; - int ret; + struct ttm_buffer_object *entry = NULL; + int ret = 0; spin_lock(&glob->lru_lock); - list_for_each_safe(list, next, &bdev->ddestroy) { - entry = list_entry(list, struct ttm_buffer_object, ddestroy); - nentry = NULL; + if (list_empty(&bdev->ddestroy)) + goto out_unlock; - /* - * Protect the next list entry from destruction while we - * unlock the lru_lock. - */ + entry = list_first_entry(&bdev->ddestroy, + struct ttm_buffer_object, ddestroy); + kref_get(&entry->list_kref); + + for (;;) { + struc...