[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151009142119.GC27761@twin.jikos.cz>
Date: Fri, 9 Oct 2015 16:21:19 +0200
From: David Sterba <dsterba@...e.cz>
To: Kosuke Tatsukawa <tatsu@...jp.nec.com>
Cc: Chris Mason <clm@...com>, Josef Bacik <jbacik@...com>,
David Sterba <dsterba@...e.com>,
"linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] btrfs: fix waitqueue_active without memory barrier in
btrfs
On Fri, Oct 09, 2015 at 12:35:48AM +0000, Kosuke Tatsukawa wrote:
> This patch removes the call to waitqueue_active() leaving just wake_up()
> behind. This fixes the problem because the call to spin_lock_irqsave()
> in wake_up() will be an ACQUIRE operation.
Either we can switch it to wake_up or put the barrier before the check.
Not all instances of waitqueue_active need the barrier though.
> I found this issue when I was looking through the linux source code
> for places calling waitqueue_active() before wake_up*(), but without
> preceding memory barriers, after sending a patch to fix a similar
> issue in drivers/tty/n_tty.c (Details about the original issue can be
> found here: https://lkml.org/lkml/2015/9/28/849).
There are more in btrfs:
https://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg41914.html
> @@ -918,9 +918,7 @@ void btrfs_bio_counter_inc_noblocked(struct btrfs_fs_info *fs_info)
> void btrfs_bio_counter_sub(struct btrfs_fs_info *fs_info, s64 amount)
> {
> percpu_counter_sub(&fs_info->bio_counter, amount);
> -
> - if (waitqueue_active(&fs_info->replace_wait))
> - wake_up(&fs_info->replace_wait);
> + wake_up(&fs_info->replace_wait);
Chris had a comment on that one in
https://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg42551.html
it's in performance critial context and the explicit wake_up is even
worse than the barrier.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists