search for: wake_up

...ads in order to find out where they are spending their time in the hopes that I can identify a place where they may be experiencing unexpected delays. This debugging lead me to look at the code in start_this_handle(), contained in file fs/jbd/transaction.c, and I have a question concerning the wake_up() logic for the thread which may go to sleep on <j_wait_transaction_locked>. The thread will sleep as long as <j_barrier_count> is non-zero: repeat: spin_lock(&journal->j_state_lock); ... if (journal->j_barrier_cou...

...100644 --- a/fs/btrfs/compression.c +++ b/fs/btrfs/compression.c @@ -818,6 +818,7 @@ static void free_workspace(int type, struct list_head *workspace) btrfs_compress_op[idx]->free_workspace(workspace); atomic_dec(alloc_workspace); wake: + smp_mb(); if (waitqueue_active(workspace_wait)) wake_up(workspace_wait); } diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c index 335605c..8cc9b19 100644 --- a/fs/btrfs/delayed-inode.c +++ b/fs/btrfs/delayed-inode.c @@ -513,9 +513,11 @@ static void __btrfs_remove_delayed_item(struct btrfs_delayed_item *delayed_item) rb_erase(&dela...

Sorry, please pause this patch review. When I was investigating fstest generic failed case 347 361, I found the wake_up() action should move out the 'if()' area. The correct way is calling wake_up() unconditionally. Thanks, Heming On 4/21/23 4:36 PM, Heming Zhao wrote: > fstest generic case 266 272 281 trigger hanging issue when umount. > > I use 266 to describe the root cause. > > ``` &gt...

Hi Chris, This is the extent of my current queue of Btrfs snapshot/subvol/commit stuff. Most of these were posted several months ago. Can be sent upstream during this merge window? Not having this functionality is becoming a bit of a roadblock for our efforts to keep the Ceph data in a consistent state. These patches are also available from

Dear xen-devel, There''s a race condition in xenfs (xenstore driver) that causes userspace utility xenstore-watch to crash. Normally, the userspace process gets an "OK" from xenfs and then the watch fires immediately after. Occasionally, this happens the other way around: the watch fires before the driver sends "OK", which confuses the xenstore-watch client. It seems

...929320bd967 100644 --- a/fs/ocfs2/super.c +++ b/fs/ocfs2/super.c @@ -408,6 +408,9 @@ static int ocfs2_sync_fs(struct super_block *sb, int wait) if (jbd2_journal_start_commit(osb->journal->j_journal, &target)) { + /* kick commit thread to reset journal->j_num_trans */ + wake_up(&osb->checkpoint_event); + if (wait) jbd2_log_wait_commit(osb->journal->j_journal, target); -- 2.39.2

...xt, struct btrfs_pending_snapshot, list); - + snapshot->error = -ECANCELED; list_del_init(&snapshot->list); - - kfree(snapshot); } } @@ -3840,6 +3838,8 @@ void btrfs_cleanup_one_transaction(struct btrfs_transaction *cur_trans, cur_trans->blocked = 1; wake_up(&root->fs_info->transaction_blocked_wait); + btrfs_evict_pending_snapshots(cur_trans); + cur_trans->blocked = 0; wake_up(&root->fs_info->transaction_wait); @@ -3849,8 +3849,6 @@ void btrfs_cleanup_one_transaction(struct btrfs_transaction *cur_trans, btrfs_destroy_de...

...rc5 and I am sporadically getting crashes shortly after startup in gk104_fifo_intr_runlist(). What I've found is that the 'mask' value read from offset 0x2a00 comes back as '0xbad0da00'. This causes the 'engn' variable to be assigned the value 9, which is invalid; then wake_up() is called on an uninitialized waitqueue which causes the crash. Reverting commit 1addc12648521d ("drm/nouveau/fifo/gk104: kick channels when deactivating them") seemed to make the problem go away, although I can't be 100% sure because the problem is sporadic. Attached an example o...

...p->assert_master == 0) + __dlm_put_mle(tmp); ret = DLM_MIGRATE_RESPONSE_MASTERY_REF; mlog(0, "%s:%.*s: master=%u, newmaster=%u, " "telling master to get ref for cleared out mle " @@ -3173,6 +3181,7 @@ static void dlm_clean_block_mle(struct dlm_ctxt *dlm, wake_up(&mle->wq); /* Do not need events any longer, so detach from heartbeat */ + __dlm_unlink_mle(dlm, mle); __dlm_mle_detach_hb_events(dlm, mle); __dlm_put_mle(mle); } -- 1.7.8.6

...+595,8 @@ static void vmbus_onopen_result(struct vmbus_channel_message_header *hdr) memcpy(&msginfo->response.open_result, result, sizeof(struct vmbus_channel_open_result)); - osd_waitevent_set(msginfo->waitevent); + msginfo->wait_condition = 1; + wake_up(&msginfo->waitevent); break; } } @@ -643,7 +646,8 @@ static void vmbus_ongpadl_created(struct vmbus_channel_message_header *hdr) memcpy(&msginfo->response.gpadl_created, gpadlcreated, sizeof(struct vmbus_channel_gpadl_created)); - osd_waitev...

...+595,8 @@ static void vmbus_onopen_result(struct vmbus_channel_message_header *hdr) memcpy(&msginfo->response.open_result, result, sizeof(struct vmbus_channel_open_result)); - osd_waitevent_set(msginfo->waitevent); + msginfo->wait_condition = 1; + wake_up(&msginfo->waitevent); break; } } @@ -643,7 +646,8 @@ static void vmbus_ongpadl_created(struct vmbus_channel_message_header *hdr) memcpy(&msginfo->response.gpadl_created, gpadlcreated, sizeof(struct vmbus_channel_gpadl_created)); - osd_waitev...

...oon.c b/drivers/virtio/virtio_balloon.c index 7efc329..ee29473 100644 --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -589,7 +589,7 @@ static int virtballoon_restore(struct virtio_device *vdev) virtio_device_ready(vdev); - fill_balloon(vb, towards_target(vb)); + wake_up(&vb->config_change); update_balloon_size(vb); return 0; } -- MST

...oon.c b/drivers/virtio/virtio_balloon.c index 7efc329..ee29473 100644 --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -589,7 +589,7 @@ static int virtballoon_restore(struct virtio_device *vdev) virtio_device_ready(vdev); - fill_balloon(vb, towards_target(vb)); + wake_up(&vb->config_change); update_balloon_size(vb); return 0; } -- MST

...; + unsigned long flags; > + struct virtio_pmem_request *req, *req_buf; > + struct virtio_pmem *vpmem = vq->vdev->priv; > + > + spin_lock_irqsave(&vpmem->pmem_lock, flags); > + while ((req = virtqueue_get_buf(vq, &len)) != NULL) { > + req->done = true; > + wake_up(&req->host_acked); > + > + if (!list_empty(&vpmem->req_list)) { > + req_buf = list_first_entry(&vpmem->req_list, > + struct virtio_pmem_request, list); > + list_del(&vpmem->req_list); Shouldn't it be rather `list_del(vpmem->req_list.next)`...

...; + unsigned long flags; > + struct virtio_pmem_request *req, *req_buf; > + struct virtio_pmem *vpmem = vq->vdev->priv; > + > + spin_lock_irqsave(&vpmem->pmem_lock, flags); > + while ((req = virtqueue_get_buf(vq, &len)) != NULL) { > + req->done = true; > + wake_up(&req->host_acked); > + > + if (!list_empty(&vpmem->req_list)) { > + req_buf = list_first_entry(&vpmem->req_list, > + struct virtio_pmem_request, list); > + list_del(&vpmem->req_list); Shouldn't it be rather `list_del(vpmem->req_list.next)`...

...nReceiveDeviceInfo(struct mousevsc_dev *InputDevice, struct synthhid_device_info *DeviceInfo) +static void mousevsc_on_receive_device_info(struct mousevsc_dev *InputDevice, + struct synthhid_device_info *DeviceInfo) { int ret = 0; struct hid_descriptor *desc; @@ -413,7 +415,8 @@ Cleanup: wake_up(&InputDevice->DeviceInfoWaitEvent); } -static void MousevscOnReceiveInputReport(struct mousevsc_dev *InputDevice, struct synthhid_input_report *InputReport) +static void mousevsc_on_receive_input_report(struct mousevsc_dev *InputDevice, + struct synthhid_input_report *InputReport) {...

...nReceiveDeviceInfo(struct mousevsc_dev *InputDevice, struct synthhid_device_info *DeviceInfo) +static void mousevsc_on_receive_device_info(struct mousevsc_dev *InputDevice, + struct synthhid_device_info *DeviceInfo) { int ret = 0; struct hid_descriptor *desc; @@ -413,7 +415,8 @@ Cleanup: wake_up(&InputDevice->DeviceInfoWaitEvent); } -static void MousevscOnReceiveInputReport(struct mousevsc_dev *InputDevice, struct synthhid_input_report *InputReport) +static void mousevsc_on_receive_input_report(struct mousevsc_dev *InputDevice, + struct synthhid_input_report *InputReport) {...

...virtqueue *vq; }; @@ -116,14 +121,6 @@ static void vhost_net_enable_zcopy(int vq) vhost_net_zcopy_mask |= 0x1 << vq; } -static void vhost_net_zerocopy_done_signal(struct kref *kref) -{ - struct vhost_net_ubuf_ref *ubufs; - - ubufs = container_of(kref, struct vhost_net_ubuf_ref, kref); - wake_up(&ubufs->wait); -} - static struct vhost_net_ubuf_ref * vhost_net_ubuf_alloc(struct vhost_virtqueue *vq, bool zcopy) { @@ -134,21 +131,24 @@ vhost_net_ubuf_alloc(struct vhost_virtqueue *vq, bool zcopy) ubufs = kmalloc(sizeof(*ubufs), GFP_KERNEL); if (!ubufs) return ERR_PTR(-ENOMEM);...

...virtqueue *vq; }; @@ -116,14 +121,6 @@ static void vhost_net_enable_zcopy(int vq) vhost_net_zcopy_mask |= 0x1 << vq; } -static void vhost_net_zerocopy_done_signal(struct kref *kref) -{ - struct vhost_net_ubuf_ref *ubufs; - - ubufs = container_of(kref, struct vhost_net_ubuf_ref, kref); - wake_up(&ubufs->wait); -} - static struct vhost_net_ubuf_ref * vhost_net_ubuf_alloc(struct vhost_virtqueue *vq, bool zcopy) { @@ -134,21 +131,24 @@ vhost_net_ubuf_alloc(struct vhost_virtqueue *vq, bool zcopy) ubufs = kmalloc(sizeof(*ubufs), GFP_KERNEL); if (!ubufs) return ERR_PTR(-ENOMEM);...

...> after >> startup in gk104_fifo_intr_runlist(). What I've found is that the 'mask' >> value >> read from offset 0x2a00 comes back as '0xbad0da00'. This causes the >> 'engn' >> variable to be assigned the value 9, which is invalid; then wake_up() is >> called >> on an uninitialized waitqueue which causes the crash. >> >> Reverting commit 1addc12648521d ("drm/nouveau/fifo/gk104: kick channels >> when >> deactivating them") seemed to make the problem go away, although I can't >> be 100...