xfs
[Top] [All Lists]

Re: [PATCH] kill BMAPI_DEVICE

To: "Christoph Hellwig" <hch@xxxxxx>
Subject: Re: [PATCH] kill BMAPI_DEVICE
From: "Bhagi rathi" <jahnu77@xxxxxxxxx>
Date: Mon, 10 Sep 2007 18:50:07 +0530
Cc: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=j/DAbcgEewlw9gnbFLnUKJXs4YNlvG3ykPswa1FjH8E=; b=lc9DYqbPLMPIlhjM44puDtys2pvMilLcq5/vN3FKqRkAVux7KFGiRP4YB+GmBq7X5Najt8qJNK27EZH1MCQzmgCCpHBDe6/i47TsvpgTi8zNMDfbqJibG8p8NQER4Mya5/jZvwFG4NnBhgm1Jufp+coQ8+pDh9hJjU6onwqFia4=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=A7psbJllhWqjiUe209bDesqSosjXjzqtw90aZaQEPO6yzN2UZ1r2HeYIlmRVyOfXPLm1RpgAgeUddWI0Re1Gry93CA4nxTFJC47gqM9Tl4rU/m/B8BIkkQTpvnSrAinPY5zjU/uq0rHYD00/HLBp3+7TCQtVX7rbaMHrj1GQSYA=
In-reply-to: <20070910120103.GA3666@lst.de>
References: <20070909153947.GA19986@lst.de> <cc7060690709091232w4185e788yf8a085e0e67e71e8@mail.gmail.com> <20070910120103.GA3666@lst.de>
Sender: xfs-bounce@xxxxxxxxxxx
On 9/10/07, Christoph Hellwig <hch@xxxxxx> wrote:
>
> 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.


Yes.  I believe the proposed change can succeed after the fix you mentioned.

> 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.


What is the goal of the bigger changes planned?

-Saradhi.


[[HTML alternate version deleted]]


<Prev in Thread] Current Thread [Next in Thread>