From: Christoph Hellwig <hch@lst.de>
To: Bhagi rathi <jahnu77@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>, xfs@oss.sgi.com
Subject: Re: [PATCH] kill BMAPI_DEVICE
Date: Mon, 10 Sep 2007 14:01:03 +0200 [thread overview]
Message-ID: <20070910120103.GA3666@lst.de> (raw)
In-Reply-To: <cc7060690709091232w4185e788yf8a085e0e67e71e8@mail.gmail.com>
On Mon, Sep 10, 2007 at 01:02:07AM +0530, Bhagi rathi wrote:
> XFS_IOCORE_RT | XFS_DIFLAG_REALTIME can be set from an ioctl (xfs_setattr).
> A directIO without holding ILOCK
> in shared in mode can read a wrong value of di_flag for real time decision.
> As a result, we may pass in-correct device
> during directIO as the proposed xfs_find_bdev_for_inode doesn't hold any
> lock in reading the flags. It is not based
> on iocore flags as well.
>
> On a secondary note, XFS_IOCORE_RT was set without holding iolock which
> seems to an issue. I tend to leave
> xfs_bmapi to decide BMAPI_DEVICE to xfs_iomap.
The previous locking doesn't help anything - if the value changes during
the direct I/O process we are in trouble anyway. Fortunately we always
hold the iolock in shared mode over any direct I/O, so taking this lock
in ->setattr will fix this pre-existing issue.
> What is the reason why this has to be seperated?
Because it does not belong into xfs_iomap. While there is at least some
common code between BMAPI_READ, BMAPI_WRITE and BMAPI_ALLOCATE calls so
sharing that makes some sense it does not at all for the other two which
this patch separates out in preparation of bigger changes in this area.
next prev parent reply other threads:[~2007-09-10 12:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-09 15:39 [PATCH] kill BMAPI_DEVICE Christoph Hellwig
2007-09-09 19:32 ` Bhagi rathi
2007-09-10 12:01 ` Christoph Hellwig [this message]
2007-09-10 13:20 ` Bhagi rathi
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=20070910120103.GA3666@lst.de \
--to=hch@lst.de \
--cc=jahnu77@gmail.com \
--cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox