All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Liu Bo <bo.li.liu@oracle.com>
Cc: Nikolay Borisov <nborisov@suse.com>,
	Filipe Manana <fdmanana@gmail.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	Josef Bacik <josef@toxicpanda.com>
Subject: Re: [PATCH] btrfs: Fix locking during DIO read
Date: Fri, 23 Feb 2018 00:39:11 +0100	[thread overview]
Message-ID: <20180222233911.GJ1469@twin.jikos.cz> (raw)
In-Reply-To: <20180222192440.GB11675@dhcp-10-211-47-181.usdhcp.oraclecorp.com>

On Thu, Feb 22, 2018 at 12:24:40PM -0700, Liu Bo wrote:
> > > > Not even that far, isize is truncated before calling inode_dio_wait()
> > > > and a memory barrier is set to ensure the correct order, so dio read
> > > > would simply return if it's reading past isize.
> > > 
> > > Please, describe concretely which meory barriers pairs with chich in
> > > order to ensure proper visibility. Because I'm of the opinion there are
> > > insufficient memoru barriers to ensure setting READDIO_LOCK is properly
> > > visible in btrfs_direct_IO. Since the latter has no barriers whatsoever.
> > 
> > smp_mb() is supposed to be paired, so there is one missing, I agree.
> >
> 
> So the missing smp_mb() was there (commit
> 2e60a51e62185cce48758e596ae7cb2da673b58f), but was removed in some
> cleanup I guess.

Not a cleanup, and not a single commit:

38851cc19adbfa1def2b47106d8050a80e0a3673
Btrfs: serialize unlocked dio reads with truncate
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>

at this time the i_dio_counter was still used directly and the barrier
was moved before the if-else block, technically still in the right
before the test_bit.

dc59215d4f42084ee13654bafe3e5130b146aeb7
btrfs: remove unnecessary memory barrier in btrfs_direct_IO
Signed-off-by: Nikolay Borisov <nborisov@suse.com>

... simply removes the barrier.

  reply	other threads:[~2018-02-22 23:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-21 11:41 [PATCH] btrfs: Fix locking during DIO read Nikolay Borisov
2018-02-21 13:06 ` Filipe Manana
2018-02-21 13:10   ` Nikolay Borisov
2018-02-21 13:27     ` Filipe Manana
2018-02-21 13:51 ` Filipe Manana
2018-02-21 14:15   ` Nikolay Borisov
2018-02-21 14:42     ` Filipe Manana
2018-02-21 18:28       ` Liu Bo
2018-02-21 18:38         ` Nikolay Borisov
2018-02-21 19:05         ` Filipe Manana
2018-02-21 22:38           ` Liu Bo
2018-02-22  6:49             ` Nikolay Borisov
2018-02-22 19:09               ` Liu Bo
2018-02-22 19:24                 ` Liu Bo
2018-02-22 23:39                   ` David Sterba [this message]
2018-02-23  6:36                     ` Nikolay Borisov
2018-02-22 10:05             ` Filipe Manana
2018-02-21 18:14     ` Liu Bo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180222233911.GJ1469@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=bo.li.liu@oracle.com \
    --cc=fdmanana@gmail.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.