lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 9 Jan 2024 18:19:17 -0500
From: "Michael S. Tsirkin" <mst@...hat.com>
To: David Stevens <stevensd@...omium.org>
Cc: Theodore Ts'o <tytso@....edu>, David Hildenbrand <david@...hat.com>,
	virtualization@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: REGRESSION: lockdep warning triggered by 15b9ce7ecd:
 virtio_balloon: stay awake while adjusting balloon

On Tue, Jan 09, 2024 at 02:50:20PM +0900, David Stevens wrote:
> On Tue, Jan 9, 2024 at 6:50 AM Theodore Ts'o <tytso@....edu> wrote:
> >
> > Hi, while doing final testing before sending a pull request, I merged
> > in linux-next, and commit 5b9ce7ecd7: virtio_balloon: stay awake while
> > adjusting balloon seems to be causing a lockdep warning (see attached)
> > when running gce-xfstests on a Google Compute Engine e2 VM.  I was not
> > able to trigger it using kvm-xfstests, but the following command:
> > "gce-xfstests -C 10 ext4/4k generic/476) was sufficient to triger the
> > problem.   For more information please see [1] and [2].
> >
> > [1] https://github.com/tytso/xfstests-bld/blob/master/Documentation/gce-xfstests.md
> > [2] https://thunk.org/gce-xfstests
> >
> > I found it by looking at the git logs, and this commit aroused my
> > suspicions, and I further testing showed that the lockdep warning was
> > reproducible with this commit, but not when testing with the
> > immediately preceeding commit (15b9ce7ecd^).
> >
> > Cheers,
> >
> >                                                 - Ted
> >
> >
> > root: ext4/4k run xfstest generic/476
> > systemd[1]: Started fstests-generic-476.scope - /usr/bin/bash -c test -w /proc/self/oom_score_adj && echo 250 > /proc/self/oom_score_adj; exec ./tests/generic/476.
> > kernel: [  399.361181] EXT4-fs (dm-1): mounted filesystem 840e25bd-f650-4819-8562-7eded85ef370 r/w with ordered data mode. Quota mode: none.
> > systemd[1]: fstests-generic-476.scope: Deactivated successfully.
> > systemd[1]: fstests-generic-476.scope: Consumed 3min 1.966s CPU time.
> > systemd[1]: xt\x2dvdb.mount: Deactivated successfully.
> > kernel: [  537.085404] EXT4-fs (dm-0): unmounting filesystem d3d7a675-f7b6-4384-abec-2e60d885b6da.
> > systemd[1]: xt\x2dvdc.mount: Deactivated successfully.
> > kernel: [  540.565870]
> > kernel: [  540.567523] ================================
> > kernel: [  540.572007] WARNING: inconsistent lock state
> > kernel: [  540.576407] 6.7.0-rc3-xfstests-lockdep-00012-g5b9ce7ecd715 #318 Not tainted
> > kernel: [  540.583532] --------------------------------
> > kernel: [  540.587928] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> > kernel: [  540.594326] kworker/0:3/329 [HC0[0]:SC0[0]:HE1:SE1] takes:
> > kernel: [  540.599955] ffff90b280a548c0 (&vb->adjustment_lock){?...}-{2:2}, at: update_balloon_size_func+0x33/0x190
> > kernel: [  540.609926] {IN-HARDIRQ-W} state was registered at:
> > kernel: [  540.614935]   __lock_acquire+0x3f2/0xb30
> > kernel: [  540.618992]   lock_acquire+0xbf/0x2b0
> > kernel: [  540.622786]   _raw_spin_lock_irqsave+0x43/0x90
> > kernel: [  540.627366]   virtballoon_changed+0x51/0xd0
> > kernel: [  540.631947]   virtio_config_changed+0x5a/0x70
> > kernel: [  540.636437]   vp_config_changed+0x11/0x20
> > kernel: [  540.640576]   __handle_irq_event_percpu+0x88/0x230
> > kernel: [  540.645500]   handle_irq_event+0x38/0x80
> > kernel: [  540.649558]   handle_edge_irq+0x8f/0x1f0
> > kernel: [  540.653791]   __common_interrupt+0x47/0xf0
> > kernel: [  540.658106]   common_interrupt+0x79/0xa0
> > kernel: [  540.661672] EXT4-fs (dm-1): unmounting filesystem 840e25bd-f650-4819-8562-7eded85ef370.
> > kernel: [  540.663183]   asm_common_interrupt+0x26/0x40
> > kernel: [  540.663190]   acpi_safe_halt+0x1b/0x30
> > kernel: [  540.663196]   acpi_idle_enter+0x7b/0xd0
> > kernel: [  540.663199]   cpuidle_enter_state+0x90/0x4f0
> > kernel: [  540.688723]   cpuidle_enter+0x2d/0x40
> > kernel: [  540.692516]   cpuidle_idle_call+0xe4/0x120
> > kernel: [  540.697036]   do_idle+0x84/0xd0
> > kernel: [  540.700393]   cpu_startup_entry+0x2a/0x30
> > kernel: [  540.704588]   rest_init+0xe9/0x180
> > kernel: [  540.708118]   arch_call_rest_init+0xe/0x30
> > kernel: [  540.712426]   start_kernel+0x41c/0x4b0
> > kernel: [  540.716310]   x86_64_start_reservations+0x18/0x30
> > kernel: [  540.721164]   x86_64_start_kernel+0x8c/0x90
> > kernel: [  540.725737]   secondary_startup_64_no_verify+0x178/0x17b
> > kernel: [  540.731432] irq event stamp: 22681
> > kernel: [  540.734956] hardirqs last  enabled at (22681): [<ffffffff8b4b5158>] _raw_spin_unlock_irq+0x28/0x50
> > kernel: [  540.744564] hardirqs last disabled at (22680): [<ffffffff8b4b4ded>] _raw_spin_lock_irq+0x5d/0x90
> > kernel: [  540.753475] softirqs last  enabled at (22076): [<ffffffff8a58cfa1>] srcu_invoke_callbacks+0x101/0x1c0
> > kernel: [  540.762904] softirqs last disabled at (22072): [<ffffffff8a58cfa1>] srcu_invoke_callbacks+0x101/0x1c0
> > kernel: [  540.773298]
> > kernel: [  540.773298] other info that might help us debug this:
> > kernel: [  540.780207]  Possible unsafe locking scenario:
> > kernel: [  540.780207]
> > kernel: [  540.786438]        CPU0
> > kernel: [  540.789007]        ----
> > kernel: [  540.791766]   lock(&vb->adjustment_lock);
> > kernel: [  540.796014]   <Interrupt>
> > kernel: [  540.798778]     lock(&vb->adjustment_lock);
> > kernel: [  540.803605]
> 
> Oh, that's embarrassing, I completely whiffed on interactions with
> interrupts. The following patch fixes it, and I've locally repro'ed
> the issue and verified the fix. What's the process for getting this
> fix merged? Does it get merged as a seperatch patch, or squashed into
> the original commit?
> 
> >From a99a1efa6a2b470a98ea2c87e58bebe90ce329a1 Mon Sep 17 00:00:00 2001
> From: David Stevens <stevensd@...omium.org>
> Date: Tue, 9 Jan 2024 14:41:21 +0900
> Subject: [PATCH] virtio_balloon: Fix interrupt context deadlock
> 
> Use _irq spinlock functions with the adjustment_lock, since
> start_update_balloon_size needs to acquire it in an interrupt context.
> 
> Fixes: 5b9ce7ecd715 ("virtio_balloon: stay awake while adjusting balloon")
> Reported-by: Theodore Ts'o <tytso@....edu>
> Signed-off-by: David Stevens <stevensd@...omium.org>
> ---
>  drivers/virtio/virtio_balloon.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index aa6a1a649ad6..1f5b3dd31fcf 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -459,12 +459,12 @@ static void start_update_balloon_size(struct
> virtio_balloon *vb)
> 
>  static void end_update_balloon_size(struct virtio_balloon *vb)
>  {
> -       spin_lock(&vb->adjustment_lock);
> +       spin_lock_irq(&vb->adjustment_lock);
>         if (!vb->adjustment_signal_pending && vb->adjustment_in_progress) {
>                 vb->adjustment_in_progress = false;
>                 pm_relax(vb->vdev->dev.parent);
>         }
> -       spin_unlock(&vb->adjustment_lock);
> +       spin_unlock_irq(&vb->adjustment_lock);
>  }
> 
>  static void virtballoon_changed(struct virtio_device *vdev)
> @@ -506,9 +506,9 @@ static void update_balloon_size_func(struct
> work_struct *work)
>         vb = container_of(work, struct virtio_balloon,
>                           update_balloon_size_work);
> 
> -       spin_lock(&vb->adjustment_lock);
> +       spin_lock_irq(&vb->adjustment_lock);
>         vb->adjustment_signal_pending = false;
> -       spin_unlock(&vb->adjustment_lock);
> +       spin_unlock_irq(&vb->adjustment_lock);
> 
>         diff = towards_target(vb);


Your patch is damaged (lines wrapped, sha info is wrong). Please post a
new version of the original one I will replace it with the new one.

-- 
MST


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ